Bitwarden Code Review

Skill 13 of 83

Posting Bitwarden Review Comments

Use this skill when emitting inline review comments, whether posted to a GitHub pull request or written to a local file under caller-declared local-file output.

2 minutes · 546 words · 6 sections

Install

$ npx skills add bitwarden/ai-plugins --skill posting-bitwarden-review-comments

$ npx skills add bitwarden/ai-plugins

» /plugin marketplace add bitwarden/ai-plugins

The first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.

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.

Comment Posting Protocol

MUST Analyze all changes before emitting anything
MUST Use inline comments for code-specific findings
MUST Use the Bitwarden finding format
FORBIDDEN: Do NOT add “Strengths”, “Highlights”, or positive observations sections.
FORBIDDEN Do NOT post praise-only inline comments
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.

Writing “#1” creates a clickable link to issue/PR #1 (not your finding)
“Issue” is also wrong terminology (use “Finding”)
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:

Reference specific line(s)
State the problem - what breaks or what’s the risk?
Provide actionable fix (for ❌ and ⚠️)
Be brief yet clear
Use collapsed sections for comments over 5 lines
Include both opening <details> AND closing </details> tags
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.

About this skill

Trigger

Use this skill when emitting inline review comments, whether posted to a GitHub pull request or written to a local file under caller-declared local-file output. Apply when formatting comments following Bitwarden engineering standards with severity emojis, clear explanations, and actionable suggestions. Use after findings are classified and ready to emit. DO NOT USE when posting summary comments.

The verbatim description from this skill’s front matter — the string an agent matches on to decide whether to load it.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/bitwarden/ai-plugins, branch main, last pushed 6 November 2026.

Licence

Other — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

83 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. 20 distinct layouts observed: plugins/bitwarden-abacus-tools/skills/*/SKILL.md, plugins/bitwarden-adr-tools/skills/*/SKILL.md, plugins/bitwarden-atlassian-tools/skills/*/SKILL.md, plugins/bitwarden-code-review/skills/*/SKILL.md, plugins/bitwarden-delivery-tools/skills/*/SKILL.md, plugins/bitwarden-design-tools/skills/*/SKILL.md, plugins/bitwarden-designer/skills/*/SKILL.md, plugins/bitwarden-devops-engineer/skills/*/SKILL.md, plugins/bitwarden-doc-parity/skills/*/SKILL.md, plugins/bitwarden-mailcatcher-tools/skills/*/SKILL.md, plugins/bitwarden-product-analyst/skills/*/SKILL.md, plugins/bitwarden-retrospective-tools/skills/*/SKILL.md, plugins/bitwarden-security-engineer/skills/*/SKILL.md, plugins/bitwarden-shepherd/skills/*/SKILL.md, plugins/bitwarden-stripe-tools/skills/*/SKILL.md, plugins/bitwarden-tech-lead/skills/*/SKILL.md, plugins/bitwarden-testing-tools/skills/*/SKILL.md, plugins/bitwarden-testmo-tools/skills/*/SKILL.md, plugins/claude-config-validator/skills/*/SKILL.md, plugins/claude-retrospective/skills/*/SKILL.md.

Issue colours

Resolved from a deterministic hash of the owner name. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

1 repair applied to this skill so the document has one h1 and no skipped levels:

Removed “Posting Bitwarden Review Comments”, a leading h1 that duplicated the skill title.

Spec compliance

10 editorial notes across 6 of 83 skills. They are printed in the margin of each skill rather than as errors here.

Requirements Elicitation — 2 notes
Work Breakdown — 2 notes
Auditing Hackerone Vulns — 2 notes
Assessing Requirement Readiness — 1 note
Assessing Test Coverage — 2 notes
Designing Test Plans — 1 note

Images

Images inside a skill come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Marketplace

A plugin manifest is published at .claude-plugin/marketplace.json by Bitwarden, declaring 23 plugins. It is read for editorial metadata only — never as the skill index, which is always the repository tree.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /bitwarden/ai-plugins.md, and each skill at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

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`

Comment Posting Protocol

MUST Analyze all changes before emitting anything
MUST Use inline comments for code-specific findings
MUST Use the Bitwarden finding format
FORBIDDEN: Do NOT add “Strengths”, “Highlights”, or positive observations sections.
FORBIDDEN Do NOT post praise-only inline comments
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.

Writing “#1” creates a clickable link to issue/PR #1 (not your finding)
“Issue” is also wrong terminology (use “Finding”)
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:

Reference specific line(s)
State the problem - what breaks or what’s the risk?
Provide actionable fix (for ❌ and ⚠️)
Be brief yet clear
Use collapsed sections for comments over 5 lines
Include both opening <details> AND closing </details> tags
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.