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 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>

Summary Output

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