Skill

posting-bitwarden-review-comments

Use this skill when posting inline comments to GitHub pull requests. Apply when formatting comments following Bitwarden engineering standards with severity emojis, clear explanations, and actionable suggestions. Use after findings are classified and ready to post. DO NOT USE when posting summary comments.

npx claudepluginhub bitwarden/ai-plugins --plugin bitwarden-code-review

Tool Access

This skill uses the workspace's default tool permissions.

Preview

1. **MUST** Analyze all changes before posting anything

SKILL.md

Similar Skills

caveman-review

57.4k

Generates ultra-compressed code review comments for PRs and diffs: one line per finding with location, problem, fix. Supports severity prefixes like bug, risk, nit.

1 file

caveman

review-comment

Generates well-structured code review comments in Conventional Comments format for clear, actionable PR feedback. Classifies as praise/nitpick/suggestion/issue/question/thought with blocking/non-blocking decorations.

2 tools

soft-skills

genshijin-review

154

Generates ultra-concise PR review comments: one issue per line (L<line>: problem.fix) with severity prefixes (bug, risk, nit, question). Japanese supported. For pull request reviews.

genshijin

Stats

Parent Repo Stars100

Parent Repo Forks11

Last CommitJan 20, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Posting Bitwarden Review Comments

GitHub Comment Posting Protocol

MUST Analyze all changes before posting 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

Visibility Rule: Only severity + one-line description 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>

Summary Output

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