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 review-inline-comments.md in working directory
Local target, no GitHub destination	The review target is local changes and no caller declared a GitHub destination	Write to review-inline-comments.md in working directory
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 — 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.

Comment Posting Protocol

1. MUST Analyze all changes before emitting anything
2. MUST Use inline comments for code-specific findings
3. MUST Use the Bitwarden finding format
4. FORBIDDEN: Do NOT add "Strengths", "Highlights", or positive observations sections.
5. FORBIDDEN Do NOT post praise-only inline comments
6. FORBIDDEN: Do NOT post PR metadata issues (title, description, test plan) as inline comments. These go in the summary only.

Finding Format

CRITICAL: Never use # followed by numbers - GitHub will autolink it to unrelated issues/PRs.

1. Writing "#1" creates a clickable link to issue/PR #1 (not your finding)
2. "Issue" is also wrong terminology (use "Finding")
3. Use "Finding" + space + number (no # symbol); aim for under 30 words in sentence

CORRECT FORMAT:

• Finding 1: Memory leak detected
• Finding 2: Missing error handling

WRONG (DO NOT USE):

• ❌ Issue #1 (wrong term + autolink)
• ❌ #1 (autolink only)
• ❌ Issue 1 (wrong term only)

Inline Comments

Every inline comment MUST:

1. Reference specific line(s)
2. State the problem - what breaks or what's the risk?
3. Provide actionable fix (for ❌ and ⚠️)
4. Be brief yet clear
5. Use collapsed sections for comments over 5 lines
6. Include both opening <details> AND closing </details> tags
7. On a GitHub pull request, end with the source line <sub>code-review</sub>, short comments and thread replies included

Visibility Rule: Only severity + one-line description and, on a GitHub pull request, the source line visible; everything else inside <details> tags.

Template for long comments

[emoji] **[SEVERITY]**: [One-line issue description]

<details>
<summary>Details and fix</summary>

[Code example or specific fix]

[Rationale explaining why]

Reference: [docs link if applicable]
</details>

<sub>code-review</sub>

Summary Output

Invoke Skill(posting-review-summary) for all summary formatting and posting.