posting-bitwarden-review-comments

发布 Bitwarden 审查评论

目标位置检测

按以下顺序检查目标位置——使用第一个匹配项：

目标位置	检测方法	操作
当前生效的本地输出	提示词开头的指令块中有一行 OUTPUT: local files，或调用方将本地文件指定为当前生效的目标位置。请先检查此项，绝不能根据恰好可用的工具来判断	写入工作目录中的 review-inline-comments.md
本地目标位置，无 GitHub 目标位置	审查目标是本地更改，且调用方未声明 GitHub 目标位置	写入工作目录中的 review-inline-comments.md
GitHub 拉取请求	以上情况均不符合	通过 mcp__github_inline_comment__create_inline_comment 发布

对于任何本地目标位置，都必须严格按照下方格式整理每条发现，不包含源代码行，并将所有内容写入同一个文件——无论有哪些评论工具可用，都不得发布评论。

在 GitHub 拉取请求中，如果某条发现已在现有讨论串中再次提出，则应在该讨论串中回复，以便将历史记录保存在同一处。调用 mcp__github_replies__add_reply_to_pull_request_comment，并将讨论串第一条评论的 database_id 作为 commentId，将讨论串数据顶层 repository 中的所有者和仓库作为参数，并将拉取请求编号作为 pullNumber；只要回复包含正文，该工具就要求提供此参数。回复采用与行内评论相同的发现格式。如果该工具不可用、讨论串第一条评论没有 database_id，或回复调用失败，则改为发布新的行内评论。

评论发布流程

1. 必须在发布任何内容前分析所有更改
2. 必须对特定代码的发现使用行内评论
3. 必须使用 Bitwarden 发现格式
4. 禁止添加“优点”“亮点”或正面评价部分。
5. 禁止发布仅包含赞扬的行内评论
6. 禁止将拉取请求元数据问题（标题、描述、测试计划）作为行内评论发布。这些内容只应出现在摘要中。

发现格式

重要：绝不要使用 # 后接数字——GitHub 会将其自动链接到无关的问题或拉取请求。

1. 写入“#1”会创建指向问题或拉取请求 #1 的可点击链接（而不是你的发现）
2. “Issue”也是错误术语（请使用“Finding”）
3. 使用“Finding”+ 空格 + 数字（不加 # 符号）；句子尽量少于 30 个词

正确格式：

• Finding 1: 检测到内存泄漏
• Finding 2: 缺少错误处理

错误格式（请勿使用）：

• ❌ Issue #1（术语错误 + 自动链接）
• ❌ #1（仅自动链接）
• ❌ Issue 1（仅术语错误）

行内评论

每条行内评论都必须：

1. 引用具体行
2. 说明问题——会导致什么故障，或存在什么风险？
3. 提供可执行的修复方案（针对 ❌ 和 ⚠️）
4. 简洁明了
5. 超过 5 行的评论使用折叠区块
6. 同时包含开始标签 <details> 和结束标签 </details>
7. 在 GitHub 拉取请求中，以源代码行 <sub>code-review</sub> 结尾，简短评论和讨论回复也包括在内

可见性规则： 仅显示严重程度、单行描述，以及在 GitHub 拉取请求中显示的源代码行；其他内容全部放在 <details> 标签内。

长评论模板

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

摘要输出

所有摘要的格式与发布均调用 Skill(posting-review-summary)。