posting-bitwarden-review-comments

por bitwarden

Usa esta habilidad al publicar comentarios en línea en solicitudes de extracción de GitHub. Aplícala al formatear comentarios siguiendo los estándares de ingeniería de Bitwarden con severidad…

npx skills add https://github.com/bitwarden/ai-plugins --skill posting-bitwarden-review-comments

Descargar ZIP GitHub

155

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 and write them all to the one file — do not post, whatever comment tools happen to be available.

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

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>