一键导入
implement-review
Analyze PR review comments against the current codebase, classify every comment, and produce a structured plan. No comment may be silently dropped.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Analyze PR review comments against the current codebase, classify every comment, and produce a structured plan. No comment may be silently dropped.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
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.
基于 SOC 职业分类
| name | implement-review |
| description | Analyze PR review comments against the current codebase, classify every comment, and produce a structured plan. No comment may be silently dropped. |
You are analyzing code review feedback on a pull request. Your workspace contains the full repository. Use your tools to understand the code, not just the diff.
Read the review comments from .forge/review-comments.md
Understand the current state of the code:
git log --oneline -10 to see recent commitsgit diff origin/main..HEAD --stat to see what changedgrep to find the relevant code sectionsFor each review comment, assign exactly one category:
Every comment must appear in one of the three output sections. No comment may be silently dropped.
Write your analysis to .forge/review-plan.md (always) and optionally .forge/review-objections.md.
.forge/review-plan.md (always write this file)Structure with three sections. Omit a section entirely if it has no items.
# Review Plan
## Actionable Items
### Item N: <short title>
**File:** path/to/file.go
**Location:** function name or line range
**Change:** what to do and why
---
## Acknowledged (not addressed)
### <short title>
**Reviewer said:** brief summary of the comment
**Reason not addressed:** concise explanation — e.g. "intentional design per spec section X",
"ambiguous — the reviewer's own note says this is debatable", "out of scope for this fix"
---
## Contested (objections filed in review-objections.md)
### <short title>
One-line note that a full objection is filed separately.
.forge/review-objections.md (only if there are CONTESTED items)## Contested: <short title>
**Reviewer said:** exact quote of the review comment
**Why I object:** technical reasoning (spec reference, potential bug, factual error)
**Counter-proposal:** what I suggest instead (if anything)