posting-bitwarden-review-comments
Posting Bitwarden Review Comments
Destination Detection
Check destinations in this order — use the first match:
| Destination | How to Detect | Action |
|---|---|---|
| Local output in effect | An OUTPUT: local files line in the prompt's leading directive block, or a caller that passes local files as the destination in effect. Check this first, and never key it on which tools happen to be available |
Write to the inline-comments path the caller passed. With no path, pick none: return the formatted findings in your reply and say no destination was given. bitwarden-code-reviewer resolves the directory and file name in its Step 1 and passes it on every invocation; this skill never picks either |
| Local target, no GitHub destination | The review target is local changes and no caller declared a GitHub destination | Write to the inline-comments path the caller passed. With no path, pick none: return the formatted findings in your reply and say no destination was given |
| GitHub pull request | Neither of the above | Post via mcp__github_inline_comment__create_inline_comment |
Under either local destination, format every finding exactly as below, without the source line, and write them all to the one file, or return them in your reply when no path was passed — do not post, whatever comment tools happen to be available.
On a GitHub pull request, a finding raised again in an existing thread goes as a reply in that thread, so its history stays in one place. Call mcp__github_replies__add_reply_to_pull_request_comment with the database_id of the thread's first comment as commentId, the owner and repository from the threads data's top-level repository, and the pull request number as pullNumber, which the tool requires whenever a reply has a body. The reply uses the same finding format as an inline comment. When that tool is unavailable, the thread's first comment has no database_id, or the reply call fails, post a new inline comment instead.