@routerhub/agent-rules 1.5.87 → 1.5.89

package/AGENTS.base.md

@@ -56,7 +56,9 @@
 
 ## 部署规则
 
-- 发版统一执行 `./release.sh`。部署测试环境使用 `/deploy-test` skill。
+- 发版统一执行 `./release.sh`。
+- ⚠️ 部署测试环境必须使用 `/deploy-test` skill。任何包含「部署测试」「发布测试」「上线测试」「部署test」「推到test」「部署到测试环境」等表述的需求，必须先调用 `Skill` 工具加载 `deploy-test`，严禁跳过 skill 直接执行部署操作。
+- ⚠️ 部署测试环境的正确流程是：当前分支 → 合并到 test 分支 → 推送 test → 触发部署 → 切回原分支。禁止直接在 test 分支上提交代码，禁止跳过合并步骤直接部署功能分支。
 
 ## 文档规则
 
@@ -94,3 +96,9 @@
 ## 部署规则
 
 <!-- 部署特有规则在此添加 -->
+
+### 🚨 测试环境部署铁律（不可跳过）
+
+- ⚠️ **部署到测试环境唯一入口：`/deploy-test` skill。** 不论用户怎么表述（「部署测试」「帮我部署」「推到test」「发布测试环境」等），必须通过 `Skill` 工具调用 `deploy-test`，禁止凭记忆手动执行 git 命令。
+- ⚠️ **必须先合并再部署**：流程必须是 `当前功能分支 → merge 到 test → push test → 触发部署 → 切回原分支`。严禁跳过 merge 步骤直接部署功能分支。
+- ⚠️ **部署完成后必须切回原分支**，不得停留在 test 分支。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@routerhub/agent-rules",
-  "version": "1.5.87",
+  "version": "1.5.89",
   "description": "Shared Copilot agent rules and guidelines for RouterHub projects",
   "main": "AGENTS.base.md",
   "bin": {

package/rules/devops.md

@@ -7,3 +7,9 @@ outputName: "devops"
 ## 部署规则
 
 <!-- 部署特有规则在此添加 -->
+
+### 🚨 测试环境部署铁律（不可跳过）
+
+- ⚠️ **部署到测试环境唯一入口：`/deploy-test` skill。** 不论用户怎么表述（「部署测试」「帮我部署」「推到test」「发布测试环境」等），必须通过 `Skill` 工具调用 `deploy-test`，禁止凭记忆手动执行 git 命令。
+- ⚠️ **必须先合并再部署**：流程必须是 `当前功能分支 → merge 到 test → push test → 触发部署 → 切回原分支`。严禁跳过 merge 步骤直接部署功能分支。
+- ⚠️ **部署完成后必须切回原分支**，不得停留在 test 分支。

package/rules/global.md

@@ -56,7 +56,9 @@ name: "通用规则"
 
 ## 部署规则
 
-- 发版统一执行 `./release.sh`。部署测试环境使用 `/deploy-test` skill。
+- 发版统一执行 `./release.sh`。
+- ⚠️ 部署测试环境必须使用 `/deploy-test` skill。任何包含「部署测试」「发布测试」「上线测试」「部署test」「推到test」「部署到测试环境」等表述的需求，必须先调用 `Skill` 工具加载 `deploy-test`，严禁跳过 skill 直接执行部署操作。
+- ⚠️ 部署测试环境的正确流程是：当前分支 → 合并到 test 分支 → 推送 test → 触发部署 → 切回原分支。禁止直接在 test 分支上提交代码，禁止跳过合并步骤直接部署功能分支。
 
 ## 文档规则
 

package/skills/create-doc/SKILL.md

@@ -13,6 +13,8 @@ description: >-
 
 # 创建 HTML 文档
 
+⚠️ **本 Skill 已触发。第一句话必须输出：「🔧 已触发 `create-doc`，按规范生成 HTML 文档...」然后严格按照以下步骤执行，不得跳过。**
+
 生成符合项目规范的中文 HTML 文档/报告。
 
 ## 文档规范

package/skills/create-pr/SKILL.md

@@ -10,6 +10,8 @@ description: >-
 
 # 创建 Pull Request
 
+⚠️ **本 Skill 已触发。在用户回复中第一句话必须输出：「🔧 已触发 `create-pr`，按流程创建 PR...」然后严格按照以下步骤执行，不得跳过。**
+
 从当前分支创建 PR，自动完成：中文 Description、效果截图制作、GitHub CDN 上传。
 
 ## 核心流程

package/skills/deploy-test/SKILL.md

@@ -11,8 +11,16 @@ description: >-
 
 # 部署测试环境
 
+⚠️ **本 Skill 已触发。第一句话必须输出：「🔧 已触发 `deploy-test`，按流程部署测试环境...」然后严格按照以下步骤执行，不得跳过。**
+
 将当前功能分支部署到测试环境，完成后自动切回原分支。
 
+## 🚨 铁律（违反即错误）
+
+- ⚠️ 部署测试环境**唯一正确流程**：当前功能分支 → 合并到 test → 推送 test → 触发部署 → 切回原分支。
+- ⚠️ **绝对禁止**跳过合并步骤、直接在功能分支上部署、或往 test 分支直接提交代码。
+- ⚠️ 每一步必须执行完毕并确认成功后才能进入下一步，不可并行或跳过。
+
 ## 核心流程
 
 ### 1. 记录当前分支

package/skills/figma-to-code/SKILL.md

@@ -13,6 +13,8 @@ description: >-
 
 # Figma 设计还原
 
+⚠️ **本 Skill 已触发。第一句话必须输出：「🔧 已触发 `figma-to-code`，按 MCP 三步验证法还原设计...」然后严格按照以下步骤执行，不得跳过。**
+
 将 Figma 设计稿还原为代码，以 Figma 文件为唯一事实源。
 
 ## MCP 三步验证法

package/skills/github-pr-review/SKILL.md

@@ -0,0 +1,233 @@
+---
+name: github-pr-review
+description: >-
+  PR Code Review 评论处理 / 解决 Review 反馈 / 处理 Reviewer 意见。触发场景包括但不限于：
+  「处理review」「处理review评论」「处理review意见」「处理review反馈」「处理PR评论」「处理PR review」。
+  「解决review」「解决PR评论」「解决PR review」「解决review评论」「解决review意见」「解决review反馈」。
+  「修复review」「修复PR评论」「修复review评论」「修复review意见」「修复review反馈」「修复review问题」。
+  「回复review」「回复review评论」「回复review意见」「回复PR评论」「回复reviewer」「回复审阅」「回复审阅意见」。
+  「看review」「看下review」「看一下review」「看看review」「查看review」「查看review评论」「查看PR review」「查看PR评论」。
+  「review一下」「review下」「看一下PR」「看看PR」「审阅一下」「审一下」「Code Review」「code review」。
+  「处理审查」「解决审查」「修复审查」「回复审查」「查看审查」「审查一下」。
+  「评审」「评审一下」「处理评审」「看一下评审」「看看评审」「回复评审」。
+  「有人review了」「有人审阅了」「有人评论了」「有review了」「有review评论」「有新的review」「有新review」「来review了」。
+  「review怎么改」「review要我改」「review让我改」「review说了」「review提到」「review指出的」「review提到的问题」。
+  「reviwer说了」「reviwer让我改」「reviwer要我改」「reviwer提到」。
+  「re-request」「重新请求review」「重新请求审阅」「发起re-review」。
+  「PR反馈」「PR审阅」「PR审查」「PR评审」。
+  通过 GitHub CLI 拉取评论 → 按严重程度分类 → 逐条提出修复 → 用户确认后提交 → 回复对应 thread。
+---
+
+# GitHub PR review
+
+⚠️ **本 Skill 已触发。第一句话必须输出：「🔧 已触发 `github-pr-review`，按流程拉取 Review 评论并逐条处理...」然后严格按照以下步骤执行，不得跳过。**
+
+Resolves Pull Request review comments with severity-based prioritization, fix application, and thread replies.
+
+## Current PR
+
+!`gh pr view --json number,title,state,milestone -q '"PR #\(.number): \(.title) (\(.state)) | Milestone: \(.milestone.title // "none")"' 2>/dev/null`
+
+## Core workflow
+
+### 1. Fetch, filter, and classify comments
+
+```bash
+REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
+PR=$(gh pr view --json number -q '.number')
+LAST_PUSH=$(git log -1 --format=%cI HEAD)
+
+# Inline review comments - filter out replies (keep only originals)
+gh api repos/$REPO/pulls/$PR/comments?per_page=100 --jq '
+  [.[] | select(.in_reply_to_id == null) |
+   {id, path, user: .user.login, created_at, body: .body[0:200]}]
+'
+
+# PR-level reviews with non-empty body (CodeRabbit sections, Gemini, etc.)
+gh api repos/$REPO/pulls/$PR/reviews?per_page=100 --jq '
+  [.[] | select(.body | length > 0) |
+   {id, user: .user.login, state, submitted_at, body: .body[0:500]}]
+'
+```
+
+**Cross-check review-attached comments**: CodeRabbit's review body states "Actionable comments posted: N". If the general `pulls/$PR/comments` endpoint returns fewer than N new originals from that reviewer, some comments are only available via the review-specific endpoint. Fetch them and merge by comment ID:
+
+```bash
+# $REVIEW_ID from the reviews fetch above; $EXPECTED from parsing "Actionable comments posted: N"
+gh api repos/$REPO/pulls/$PR/reviews/$REVIEW_ID/comments?per_page=100 --jq '
+  [.[] | select(.in_reply_to_id == null) |
+   {id, path, user: .user.login, created_at, body: .body[0:200]}]
+'
+```
+
+Deduplicate by `id` before continuing. Comments found only via the review-specific endpoint are valid inline comments and should be treated identically (same classification, same `in_reply_to` reply mechanism).
+
+**Filter new vs already-seen**: compare `created_at`/`submitted_at` with `$LAST_PUSH`. Comments posted after the last push are new. Mark older comments as "previous round" in the summary table.
+
+**Parse CodeRabbit review bodies**: the initial fetch truncates bodies for classification. For reviews from CodeRabbit (`user.login` starts with `coderabbitai`), fetch the full body separately:
+
+```bash
+gh api repos/$REPO/pulls/$PR/reviews?per_page=100 --jq '
+  [.[] | select(.user.login | startswith("coderabbitai")) |
+   {id, submitted_at, body}]
+'
+```
+
+CodeRabbit posts structured `<details>` blocks containing outside-diff, duplicate, and nitpick comments. Each block includes file path, line range, severity, and optionally a "Prompt for AI Agents" with pre-built context. See `references/coderabbit_parsing.md` for full parsing guide.
+
+**Use CodeRabbit AI prompts when available**: if a comment (or the review body) contains a "Prompt for AI Agents" `<details>` block, use it to understand the issue and suggested approach. Always read the actual code before proposing a fix. If the review body contains a "Prompt for all review comments with AI agents" block, read it first for cross-comment context before processing individual comments.
+
+Classify all comments by severity and process in order: CRITICAL > HIGH > MEDIUM > LOW.
+
+| Severity | Indicators | Action |
+|----------|------------|--------|
+| CRITICAL | `critical.svg`, `_🔒 Security_`, `_🚨 Critical_`, `_🔴 Critical_`, "security", "vulnerability" | Must fix |
+| HIGH | `high-priority.svg`, `_⚠️ Potential issue_`, `_🐛 Bug_`, `_⚡ Performance_`, `_🟠 Major_`, "High Severity" | Should fix |
+| MEDIUM | `medium-priority.svg`, `_🛠️ Refactor suggestion_`, `_💡 Suggestion_`, "Medium Severity" | Recommended |
+| LOW | `low-priority.svg`, `_🧹 Nitpick_`, `_🔧 Optional_`, `_🟡 Minor_`, `_🔵 Trivial_`, `_⚪ Info_`, "style", "nit" | Optional |
+
+When a comment has both a type label and a secondary color badge (e.g., `_💡 Suggestion_ | _🟠 Major_`), the color badge is the **binding** severity and overrides the type-based default.
+
+See `references/severity_guide.md` for full detection patterns (Gemini badges, CodeRabbit emoji, Cursor comments, keyword fallback, related comments heuristics).
+
+### 2. Show review summary table
+
+Before processing, display a structured overview of all comments:
+
+```
+| # | ID         | Severity | File:Line          | Type     | Status   | Summary            |
+|---|------------|----------|--------------------|----------|----------|--------------------|
+| 1 | 123456789  | CRITICAL | src/auth.py:45     | inline   | new      | SQL injection risk |
+| 2 | 987654321  | HIGH     | src/db.py:346-350  | outside  | new      | Missing join cond  |
+| 3 | 555555555  | HIGH     | src/chunk.py:188   | duplicate| previous | Stale metadata     |
+| 4 | 444444444  | LOW      | tests/test_q.py:12 | nitpick  | previous | Naming convention  |
+```
+
+- **Type**: `inline`, `outside` (outside diff), `duplicate`, `minor`, `nitpick` (from CodeRabbit sections), or `review` (generic PR-level)
+- **Status**: `new` (posted after last push) or `previous` (from earlier rounds)
+- Group related comments (same file, same root cause, "also applies to" ranges) and note clusters
+- Deduplicate: if the same issue appears both as an inline comment and in a CodeRabbit review body section (e.g., duplicate), keep one entry and note both sources
+
+If there are **more than 10 comments**, suggest saving a review summary to Claude's memory for tracking across sessions. The summary should include: PR number, comment IDs, severity, status (new/addressed/deferred/won't fix), and brief description. This helps maintain continuity when new comments arrive after subsequent pushes.
+
+### 3. Process each comment
+
+For each comment, in severity order:
+
+1. **Show context**: comment ID, severity, file:line, quote
+2. **Check for AI prompt**: if CodeRabbit "Prompt for AI Agents" is available for this comment, use it to understand the issue and suggested approach
+3. **Check for proposed fix**: if CodeRabbit includes a "Proposed fix" or "Suggested fix" code block, use it as a starting point (but verify correctness)
+4. **Read affected code** and propose fix (always read the actual code, even when an AI prompt or proposed fix provides context)
+5. **Handle "also applies to"**: if the comment references additional line ranges, include all locations in the fix
+6. **Confirm with user** before applying
+7. **Apply fix** if approved
+8. **Verify ALL issues** in the comment are addressed (multi-issue comments are common)
+
+### 4. Commit changes
+
+Use git-commit skill format. Functional fixes get separate commits, cosmetic fixes are batched:
+
+| Change type | Strategy |
+|-------------|----------|
+| Functional (CRITICAL/HIGH) | Separate commit per fix |
+| Cosmetic (MEDIUM/LOW) | Single batch `style:` commit |
+
+Reference the comment ID in the commit body.
+
+### 5. Reply to threads
+
+#### Inline comments
+
+**Important**: use `--input -` with JSON. The `-f in_reply_to=...` syntax does NOT work.
+
+```bash
+COMMIT=$(git rev-parse --short HEAD)
+gh api repos/$REPO/pulls/$PR/comments \
+  --input - <<< '{"body": "Fixed in '"$COMMIT"'. Brief explanation.", "in_reply_to": 123456789}'
+```
+
+#### Non-inline comments (CodeRabbit review body)
+
+Comments embedded in the review body (outside diff, duplicate, nitpick) do not have inline threads. The GitHub API does not support replying to a review body directly. Post a general PR comment referencing the specific issue:
+
+```bash
+gh pr comment $PR --body "Fixed in $COMMIT. Addresses outside-diff comment on file/path.py:346-350."
+```
+
+**Reply templates** (no emojis, minimal and professional):
+
+| Situation | Template |
+|-----------|----------|
+| Fixed | `Fixed in [hash]. [brief description of fix]` |
+| Won't fix | `Won't fix: [reason]` |
+| By design | `By design: [explanation]` |
+| Deferred | `Deferred to [issue/task]. Will address in future iteration.` |
+| Acknowledged | `Acknowledged. [brief note]` |
+
+### 6. Run tests and push
+
+Run the project test suite. All tests must pass before pushing. Push all fixes together to minimize review loops.
+
+### 7. Submit review (optional)
+
+After addressing all comments, formally submit a review:
+
+- `gh pr review $PR --approve --body "..."` - all comments addressed, PR is ready
+- `gh pr review $PR --request-changes --body "..."` - critical issues remain
+- `gh pr review $PR --comment --body "..."` - progress update, no decision yet
+
+### 8. Verify milestone
+
+```bash
+gh pr view $PR --json milestone -q '.milestone.title // "none"'
+```
+
+If the PR has no milestone, check for open milestones:
+
+```bash
+REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
+gh api repos/$REPO/milestones --jq '[.[] | select(.state=="open")] | .[] | "\(.number): \(.title)"'
+```
+
+If open milestones exist, inform the user and suggest assigning:
+
+```bash
+gh pr edit $PR --milestone "[milestone-title]"
+```
+
+Do **not** assign automatically. This is a reminder only.
+
+## Avoiding review loops
+
+When bots (Gemini, Codex, etc.) review every push:
+
+1. **Batch fixes**: accumulate all fixes, push once
+2. **Draft PR**: convert to draft during fixes
+3. **Commit keywords**: some bots respect `[skip ci]` or `[skip review]`
+
+## Important rules
+
+- **ALWAYS** fetch both inline comments (`pulls/$PR/comments`) and review bodies (`pulls/$PR/reviews`)
+- **ALWAYS** cross-check "Actionable comments posted: N" against found originals; fetch `pulls/$PR/reviews/$REVIEW_ID/comments` when count mismatches
+- **ALWAYS** parse CodeRabbit review bodies for all section types (outside diff, duplicate, minor, nitpick)
+- **ALWAYS** use CodeRabbit "Prompt for AI Agents" as primary context when available
+- **ALWAYS** show the review summary table before processing
+- **ALWAYS** confirm before modifying files
+- **ALWAYS** verify ALL issues in multi-issue comments are fixed, including "also applies to" ranges
+- **ALWAYS** run tests before pushing
+- **ALWAYS** reply to resolved threads using standard templates
+- **ALWAYS** submit formal review (`gh pr review`) after addressing all comments
+- **ALWAYS** check milestone at the end and remind if missing
+- **ALWAYS** suggest saving a review summary to memory when there are more than 10 comments
+- **NEVER** use emojis in commit messages or thread replies
+- **NEVER** skip HIGH/CRITICAL comments without explicit user approval
+- **NEVER** assign milestone automatically - suggest only
+- **Functional fixes** -> separate commits (one per fix)
+- **Cosmetic fixes** -> batch into single `style:` commit
+- **Duplicate comments** -> treat as higher priority than their label (issue was already flagged before)
+- **Related comments** -> group and fix together when they share root cause or file context
+
+## References
+
+- `references/severity_guide.md` - Severity detection patterns (Gemini badges, CodeRabbit emoji, Cursor comments, keyword fallback, related comments heuristics)
+- `references/coderabbit_parsing.md` - CodeRabbit review body structure, section parsing, "Prompt for AI Agents" usage, duplicate and "also applies to" handling

package/skills/github-pr-review/references/coderabbit_parsing.md

@@ -0,0 +1,206 @@
+# CodeRabbit review parsing
+
+Guide for extracting and processing all comment types from CodeRabbit PR reviews.
+
+## Review body structure
+
+CodeRabbit posts a single PR-level review (via `pulls/$PR/reviews` API) containing multiple sections as collapsible `<details>` blocks. The body follows this structure:
+
+```
+Actionable comments posted: N
+
+> [!CAUTION]
+> Some comments are outside the diff and can't be posted inline...
+
+<details>
+<summary>⚠️ Outside diff range comments (N)</summary>
+  (actionable comments on code outside the PR diff)
+</details>
+
+<details>
+<summary>♻️ Duplicate comments (N)</summary>
+  (issues already flagged in a previous review)
+</details>
+
+<details>
+<summary>🟡 Minor comments (N)</summary>
+  (lower severity comments grouped to reduce inline noise)
+</details>
+
+<details>
+<summary>🧹 Nitpick comments (N)</summary>
+  (style/convention issues, lowest priority)
+</details>
+
+<details>
+<summary>🤖 Prompt for all review comments with AI agents</summary>
+  (global prompt covering all comments in this review)
+</details>
+
+<!-- Informational sections (not actionable, ignore): -->
+<details><summary>ℹ️ Review info</summary></details>
+<details><summary>⚙️ Run configuration</summary></details>
+<details><summary>📥 Commits</summary></details>
+<details><summary>⛔ Files ignored due to path filters (N)</summary></details>
+<details><summary>📒 Files selected for processing (N)</summary></details>
+<details><summary>🚧 Files skipped from review as they are similar to previous changes (N)</summary></details>
+```
+
+Not all sections are always present. CodeRabbit only includes sections that have comments. Other severity-based sections (e.g., "🔴 Critical comments", "🟠 Major comments") may also appear.
+
+## Fetching CodeRabbit reviews
+
+```bash
+REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
+PR=$(gh pr view --json number -q '.number')
+
+# Get all CodeRabbit review bodies (may be multiple reviews across pushes)
+gh api repos/$REPO/pulls/$PR/reviews?per_page=100 --jq '
+  [.[] | select(.user.login | startswith("coderabbitai")) |
+   {id, submitted_at, body}]
+'
+```
+
+The `id` field is the review ID (visible in the GitHub URL as `#pullrequestreview-<id>`). Use this as the stable identifier for tracking.
+
+## Parsing sections from the body
+
+Each section is a `<details>` block. Extract them by matching the summary text:
+
+| Summary pattern | Comment type | Default severity |
+|----------------|--------------|-----------------|
+| `⚠️ Outside diff range comments` | Code outside the PR diff | Use per-comment severity |
+| `♻️ Duplicate comments` | Already flagged in previous reviews | Use per-comment severity |
+| `🟡 Minor comments` | Lower severity, grouped to reduce noise | MEDIUM/LOW (use per-comment) |
+| `🧹 Nitpick comments` | Style/convention issues | LOW |
+| `🤖 Prompt for all review comments with AI agents` | Global AI context prompt | N/A (not a comment) |
+
+Other severity-based sections like "🔴 Critical comments" or "🟠 Major comments" may appear. Treat any unrecognized `<details>` section with comments as actionable and classify by per-comment severity.
+
+Informational sections (`ℹ️ Review info`, `⚙️ Run configuration`, `📥 Commits`, `⛔ Files ignored due to path filters`, `📒 Files selected for processing`, `🚧 Files skipped from review as they are similar to previous changes`) are not actionable. Ignore them.
+
+### Per-comment structure inside sections
+
+Each file group is wrapped in a `<details>` block. The summary format varies:
+
+```
+<!-- Outside diff / Duplicate sections: file path + count -->
+<details>
+<summary>file/path.ext (N)</summary>
+
+<!-- Minor / Nitpick sections: file path + line range + count -->
+<details>
+<summary>file/path.ext-X-Y (N)</summary>
+```
+
+Inside each file group, individual comments follow this pattern:
+
+```
+`X-Y`: _<emoji> <type>_ | _<color> <severity>_
+
+**Title text**
+
+Description paragraph(s)...
+
+As per coding guidelines, `path/**`: "quote..."    (optional, references project rules)
+
+Also applies to: X-Y, X-Y    (optional, other line ranges with same issue)
+
+<details><summary>Proposed fix</summary>
+```lang
+code suggestion
+```
+</details>
+
+<details><summary>Prompt for AI Agents</summary>
+prompt text...
+</details>
+```
+
+Key fields to extract:
+- **File path**: from the `<details><summary>` wrapping the file group
+- **Line range**: backtick-formatted `` `X-Y` `` at the start of each comment (may also appear in the file summary as `path.ext-X-Y`)
+- **Severity**: emoji + type label and optional color severity (see severity_guide.md)
+- **Title**: bold text after the severity line
+- **"Also applies to"**: additional line ranges in the same file with the same issue
+- **Proposed fix / Suggested fix**: code suggestion inside `<details>`. Summary text varies widely, with optional emoji prefix and description. Examples: `Proposed fix`, `Suggested fix`, `🔧 Proposed fix (...)`, `💡 Proposed fix`, `🔒 Suggested direction`, `✨ Optional: ...`, `♻️ Suggested cleanup`, `🔎 Suggested assertion hardening`, `♻️ Suggested diff`. Match any `<details>` block whose summary contains "fix", "suggest", "proposed", or "optional"
+- **Prompt for AI Agents**: per-comment context prompt inside `<details>`
+
+## Using the "Prompt for AI Agents"
+
+CodeRabbit provides two levels of AI prompts:
+
+### Per-comment prompt
+Inside each comment's `<details><summary>Prompt for AI Agents</summary>` block. Contains:
+- The specific file and line range
+- The issue description with context
+- References to coding guidelines or project conventions
+- The suggested fix approach
+
+### Global prompt
+At the bottom of the review body, inside `<details><summary>Prompt for all review comments with AI agents</summary>`. Contains:
+- Aggregated context for all comments in the review
+- File paths, line ranges, and descriptions for every comment
+- Useful for batch processing multiple comments at once
+
+**How to use these prompts**:
+1. When processing a comment, check if it has a per-comment prompt
+2. If present, use it to understand the issue and suggested approach
+3. Always read the actual code before proposing a fix, even when the prompt provides context
+4. For batch processing, use the global prompt to understand all issues at once before diving into individual fixes
+
+## Inline comments vs review body comments
+
+CodeRabbit posts comments in two ways:
+
+| Type | API endpoint | When used |
+|------|-------------|-----------|
+| Inline review comments | `pulls/$PR/comments` | Comments on lines within the PR diff |
+| Review body sections | `pulls/$PR/reviews` | Outside diff, duplicate, nitpick comments |
+| Review-attached inline comments | `pulls/$PR/reviews/$REVIEW_ID/comments` | Fallback for inline comments not yet surfaced by the general endpoint |
+
+**ALWAYS** fetch both endpoints to get the complete picture. Inline comments may reference issues also mentioned in the review body (especially duplicates).
+
+### Review-attached comment gap
+
+CodeRabbit's "actionable comments" are posted as part of a review object. The general `pulls/$PR/comments` endpoint may not surface these comments, or may surface them with a delay. When the review body states "Actionable comments posted: N" but the general endpoint returns fewer than N new originals from CodeRabbit, fetch the missing comments via the review-specific endpoint:
+
+```bash
+gh api repos/$REPO/pulls/$PR/reviews/$REVIEW_ID/comments?per_page=100 --jq '
+  [.[] | select(.in_reply_to_id == null) |
+   {id, path, user: .user.login, created_at, body: .body[0:200]}]
+'
+```
+
+Deduplicate by `id` against the general endpoint results. Comments found only via this endpoint are standard inline comments and support the same `in_reply_to` reply mechanism.
+
+## "Also applies to" handling
+
+Some comments include `Also applies to: 258-266, 291-296`. These indicate the same issue exists at multiple locations in the same file. When fixing:
+
+1. Fix the primary location (the one with the full description)
+2. Apply the same fix pattern to all "also applies to" ranges
+3. Verify each location, as the exact code may differ slightly
+
+## Duplicate comments
+
+Comments in the "Duplicate comments" section were already flagged in a previous review. They reappear because the underlying issue was not fixed. Treat them as:
+
+- Same severity as indicated in their label
+- Higher actual priority than their label suggests (reviewer is repeating themselves)
+- Check if they were previously deferred or missed
+
+## Configuration reference
+
+CodeRabbit behavior is controlled via `.coderabbit.yaml` in the repo root:
+
+```yaml
+reviews:
+  profile: "chill"                      # chill (default) or assertive (includes nitpicks)
+  enable_prompt_for_ai_agents: true     # includes "Prompt for AI Agents" in comments
+```
+
+- `chill`: lighter feedback, nitpick sections are hidden
+- `assertive`: full feedback, includes nitpick and minor comments
+
+Official docs: https://docs.coderabbit.ai/guides/code-review-overview

package/skills/github-pr-review/references/severity_guide.md

@@ -0,0 +1,222 @@
+# Severity guide
+
+Reference guide for interpreting severity levels from automated review comments (Gemini, CodeRabbit, Cursor, and others).
+
+## Severity Badges
+
+Gemini uses visual badges in review comments to indicate severity:
+
+### CRITICAL
+**Badge**: `![critical](https://www.gstatic.com/codereviewagent/critical.svg)`
+
+**Visual**: Red badge with "critical" text
+
+**Meaning**: Must be fixed before merge. Indicates:
+- Security vulnerabilities
+- Data loss risks
+- Logic errors causing incorrect behavior
+- Infinite loops or deadlocks
+- Memory leaks or resource exhaustion
+
+**Action**: Stop and fix immediately. These block merge.
+
+---
+
+### HIGH
+**Badge**: `![high](https://www.gstatic.com/codereviewagent/high-priority.svg)`
+
+**Visual**: Orange badge
+
+**Meaning**: Should be fixed. Indicates:
+- Performance issues
+- Error handling gaps
+- Potential race conditions
+- Missing validation on important paths
+
+**Action**: Address before merge unless there's a strong reason not to.
+
+---
+
+### MEDIUM
+**Badge**: `![medium](https://www.gstatic.com/codereviewagent/medium-priority.svg)`
+
+**Visual**: Yellow badge
+
+**Meaning**: Recommended fix. Indicates:
+- Code style issues
+- Minor refactoring opportunities
+- Unreachable code (dead code)
+- Duplicate logic
+- Missing edge case handling
+
+**Action**: Address if time permits, or create follow-up issue.
+
+---
+
+### LOW
+**Badge**: `![low](https://www.gstatic.com/codereviewagent/low-priority.svg)`
+
+**Visual**: Blue/gray badge
+
+**Meaning**: Optional improvement. Indicates:
+- Import ordering
+- Naming conventions
+- Documentation suggestions
+- Minor style preferences
+
+**Action**: Optional. Can be skipped with justification.
+
+---
+
+## Detection Patterns
+
+### Gemini Badge Detection (Primary for Gemini)
+```python
+# In comment body, look for:
+"critical.svg" → CRITICAL
+"high-priority.svg" → HIGH
+"medium-priority.svg" → MEDIUM
+"low-priority.svg" → LOW
+```
+
+### CodeRabbit Detection
+
+CodeRabbit does **not** use SVG badges. It uses emoji + italic text in the comment body.
+The pattern is: `_<emoji> <label>_` or `_<emoji> <label>_ | _<color> <severity>_`
+
+CodeRabbit classifies comments along two axes: **type** (what kind of issue) and **severity** (how impactful).
+
+#### Comment types (primary label)
+
+| Comment pattern | Severity |
+|----------------|----------|
+| `_🔒 Security_` or `_🚨 Critical_` | CRITICAL |
+| `_⚠️ Potential issue_` | HIGH |
+| `_🐛 Bug_` | HIGH |
+| `_⚡ Performance_` | HIGH |
+| `_🛠️ Refactor suggestion_` | MEDIUM |
+| `_💡 Suggestion_` | MEDIUM |
+| `_🧹 Nitpick_` | LOW (only in assertive mode) |
+| `_🔧 Optional_` | LOW (skip by default) |
+
+#### Severity levels (secondary color badge)
+
+When a secondary color badge is present, use it as the **binding** severity indicator
+(it overrides the type-based default above):
+
+| Secondary badge | Official name | Maps to |
+|----------------|---------------|---------|
+| `_🔴 Critical_` | Critical | CRITICAL |
+| `_🟠 Major_` | Major | HIGH |
+| `_🟡 Minor_` | Minor | LOW |
+| `_🔵 Trivial_` | Trivial | LOW (skip by default) |
+| `_⚪ Info_` | Info | LOW (informational, no action needed) |
+
+Note: some older reviews may use `_🔵 Info_` instead of `_🔵 Trivial_`. Treat both as LOW.
+
+#### Assertive vs chill mode
+
+CodeRabbit has two profiles configured via `.coderabbit.yaml`:
+- `profile: chill` (default) - lighter feedback, nitpicks are hidden
+- `profile: assertive` - full feedback, includes nitpick comments
+
+When reviewing a repo in `chill` mode, nitpick sections will not appear in the review body.
+
+**CodeRabbit non-inline comments** (outside diff, duplicate, nitpick) are not posted
+as inline review comments. They are embedded in the PR-level review body
+(`pulls/$PR/reviews`) inside structured `<details>` blocks. Each section type
+has its own block with file paths, line ranges, severity, and optional AI prompts.
+
+See `coderabbit_parsing.md` for the full body structure and parsing guide.
+
+**Duplicate comments** from CodeRabbit indicate an issue was already flagged in a
+previous review and not fixed. Treat these as higher actual priority than their
+severity label suggests.
+
+### Cursor Comments
+```
+<!-- **High Severity** --> → HIGH
+<!-- **Medium Severity** --> → MEDIUM
+```
+
+### Keyword Detection (Fallback)
+When badges or HTML comments aren't present, infer from keywords:
+
+| Keywords | Severity |
+|----------|----------|
+| security, vulnerability, injection, XSS, SQL | CRITICAL/HIGH |
+| dangerous, unsafe, exploit | CRITICAL |
+| performance, slow, O(n²) | HIGH |
+| error handling, exception, catch | HIGH |
+| unreachable, dead code, unused | MEDIUM |
+| refactor, simplify, consolidate | MEDIUM |
+| style, formatting, PEP, naming | LOW |
+| import order, whitespace | LOW |
+
+---
+
+## Related Comments Detection
+
+Comments are often related when:
+
+1. **Consequence relationship**: Comment B is a consequence of fixing Comment A
+   - Keywords: "consequence", "result of", "as mentioned above"
+
+2. **Same root cause**: Multiple comments about the same underlying issue
+   - Keywords: "root cause", "same issue", "related to"
+
+3. **Unreachable code**: After an exception handling fix, related `except` blocks may become unreachable
+   - Pattern: CRITICAL exception handling → MEDIUM unreachable code
+
+4. **Same function/method**: Comments within ~100 lines in the same file, where one is CRITICAL and others are MEDIUM/LOW
+
+---
+
+## Example: Exception Handling Pattern
+
+Common scenario from Gemini reviews:
+
+**Comment 1 (CRITICAL)**: Exception handling in `method_x()` needs refactoring:
+- FileNotFoundError should fail-fast, not retry
+- Generic exceptions need sleep to avoid busy-loop
+
+**Comment 2 (MEDIUM)**: `except FileNotFoundError` block at line 186 is unreachable
+→ This is a CONSEQUENCE of fixing Comment 1
+
+**Comment 3 (MEDIUM)**: `except FileNotFoundError` block at line 473 is unreachable
+→ Also a CONSEQUENCE of fixing Comment 1
+
+**Resolution**: Fix Comment 1 first. Comments 2 and 3 will be automatically resolved.
+
+---
+
+## Gemini Config Reference
+
+Gemini behavior is controlled by `.gemini/config.yaml`:
+
+```yaml
+code_review:
+  threshold: LOW          # Minimum severity to report
+  auto_fix: false         # Whether to suggest auto-fixes
+  blocking: false         # Whether reviews block merge
+```
+
+When `threshold: LOW`, all severities are reported.
+When `blocking: false`, reviews are advisory only.
+
+---
+
+## Workflow Integration
+
+1. **Fetch comments**: Parse severity from badge URLs in comment body
+2. **Sort by severity**: CRITICAL → HIGH → MEDIUM → LOW
+3. **Group related**: Use heuristics above
+4. **Process CRITICAL first**: These often resolve MEDIUM/LOW comments
+5. **Skip LOW if needed**: They're optional by definition
+
+---
+
+## References
+
+- [Gemini Code Assist Documentation](https://cloud.google.com/gemini/docs/discover/code-assist)
+- [GitHub PR Review API](https://docs.github.com/en/rest/pulls/comments)

package/skills/tdd-workflow/SKILL.md

@@ -14,6 +14,8 @@ description: >-
 
 # TDD 开发流程
 
+⚠️ **本 Skill 已触发。第一句话必须输出：「🔧 已触发 `tdd-workflow`，按 TDD 七步流程开发...」然后严格按照以下步骤执行，不得跳过。**
+
 测试驱动开发，每次接收新需求时强制遵循。
 
 ## 七步流程