PR/代码评审时用超压缩一行一指出：位置、问题、修正

适用于提交 Pull Request 或代码审查评论，把反馈压缩成一行一条、只保留可行动信号并标注严重度。

适用场景

解决思路

1. 评论保持简洁且可行动：1 行 1 条指摘，写清位置、问题、修正，禁止写前言。
2. 格式：`L<line>: <问题>。<修正>。`；多个文件时用 `<file>:L<line>: ...`。
3. 混用严重度前缀：🔴 `バグ:` 表示坏了、直接关联事故；🟡 `リスク:` 表示能跑但脆弱（如 race、null 未检查、吞掉 error）；🔵 `nit:` 表示风格/命名/微优化，作者可忽略；❓ `質問:` 表示纯疑问，不是建议。
4. 删除「〜に気づきました」「〜のように見えます」「〜を検討するとよいかもしれません」这类铺垫。
5. 遇到「あくまで提案ですが」时改用 `nit:`。
6. 「素晴らしい仕事です」「全体的には良さそうですが」只在开头写 1 次，不要逐条评论。
7. 删除对行行为的说明——看 diff 就能明白的内容不要写。
8. 删除模糊表达（「おそらく」「たぶん」「〜と思います」）；如果不确定，改用 `質問:`。
9. 保留准确行号。
10. 符号、函数名、变量名用反引号包住。
11. 保留具体修正；禁止写「リファクタリング検討」这类空泛建议。
12. 保留从问题描述中不能自明的「なぜ」。
13. 示例 1：把冗长评论压缩为 `L42: 🔴 バグ: .find() 後 user null 可。.email 前にガード追加。`
14. 示例 2：把「这个函数做了很多事，拆成小函数可能更好读」压缩为 `L88-140: 🔵 nit: 50行fn 4責務。validate/normalize/persist 抽出。`
15. 示例 3：把「API 返回 429 时是否考虑处理？最好对应」压缩为 `L23: 🟡 リスク: 429 リトライなし。withBackoff(3) で包む。`
16. 自动明瞭化：以下情况解除简洁模式，改用普通段落描述：安全指摘（CVE 级需附参考 URL 并充分说明）、架构异议（需要根据，一行不够）、新人 onboarding 上下文（需要「为什么」）。
17. 上述需要明瞭化的指摘写完后立即恢复简洁模式。
18. 边界：只做评审；禁止代码修正、approve/request-changes、运行 linter。
19. 输出必须是可直接粘贴到 PR 的格式。
20. 用户说「原始人レビューやめて」「通常モード」时解除本技能。

适用边界 · 注意事项

• 安全指摘（尤其 CVE 级）不适用超压缩一行格式；应解除简洁模式，用普通段落并附参考 URL 和充分说明。
• 架构异议、新人 onboarding 上下文不适用一行压缩；需要解释根据和「为什么」。
• 需要直接改代码、approve/request-changes 或运行 linter 时不适用；本技能只做评审评论。