菜单
Qualitative code review for bug fixes — verifies root-cause alignment and test coverage before PR creation. Use after implement-task completes for bug tickets.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Produce a concrete implementation plan for a standalone Task or Epic takeover ticket. Use when a Jira Task/Epic is approved for Task Takeover planning and needs target files, implementation steps, tests, and repository scope.
Read-only qualitative review for Task Takeover implementations before PR creation. Use after task takeover execution completes.
Decompose a Technical Specification into implementable Epics with technical plans. Use when asked to break down features, create epics, or plan implementation.
Break down Epic implementation plans into concrete, actionable Tasks. Use when decomposing Epics into implementation units.
Implement code changes according to Task specifications. Use when executing implementation Tasks.
Produce a concrete implementation plan for a bug fix from an approved RCA and selected fix approach. Use when the team has selected a fix option and needs a detailed plan before implementation.
| name | local-review-bug |
| description | Qualitative code review for bug fixes — verifies root-cause alignment and test coverage before PR creation. Use after implement-task completes for bug tickets. |
Review the implemented changes against the approved RCA and plan. You have access to the workspace and codebase. Run git diff origin/main...HEAD to see what changed.
Run these first and fix any failures before proceeding to the qualitative review:
ruff check ., go vet ./...)If any mechanical check fails and cannot be fixed, report it in the feedback.
Evaluate the diff against each item:
Root cause alignment — Does the change address the confirmed root cause, or only a symptom?
Test proof — Do the new/modified tests actually prove the bug is fixed? Would they fail without the fix?
Fix stability — Could someone break this fix without a test catching it?
Plan scope adherence — Does the diff match the approved plan scope, or has it drifted?
Call site completeness — Are there similar patterns elsewhere in the codebase that need the same treatment?
Backward compatibility — Is the fix safe to roll back? Does it avoid breaking interfaces?
Bidirectional validation — Does the commit log show [bidirectional: PASS], confirming the agent verified the test fails without the fix?
Ordering invariants — Find the ## Ordering Invariants section in the approved plan above. For each entry, locate the relevant calls in the diff (git diff origin/main...HEAD) and verify the stated order is preserved in the implementation. If the section says "None identified.", spot-check the diff for operation pairs with non-obvious side effects (e.g. a call that deletes or resets shared state before a call that depends on it). Flag any reversal as a blocking issue in your feedback.
The verdict format is a forge protocol constraint — use it exactly:
verdict: adequate
or
verdict: tests_incomplete
or
verdict: symptom_only
Followed by:
feedback: <specific, actionable description of what needs to change — or "All checks passed." if adequate>
Only these three verdict values are valid. Do not use any other string.