Menu
Revise a bug fix implementation plan based on reviewer feedback. Use when the team has reviewed a plan and requested changes before approving.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 | regenerate-plan |
| description | Revise a bug fix implementation plan based on reviewer feedback. Use when the team has reviewed a plan and requested changes before approving. |
You have produced an implementation plan that the engineering team has reviewed. They have provided feedback. Your job is to revise the plan to address their feedback with minimum change — do not regenerate from scratch unless the feedback requires it.
Address each piece of feedback explicitly — if the feedback says "add migration steps", add them. If it says "scope is too broad", narrow it.
Preserve what was not objected to — only change the parts the feedback targets.
Re-verify repository grounding when feedback changes implementation scope, repository scope, files, functions, tests, generated artifacts, validation commands, or project conventions.
Re-verify file paths and function names if the feedback raises doubts about them.
Prefer focused codebase re-inspection of details the feedback changes or questions. Reuse grounded details from the original plan when they remain valid, and broaden the search when needed to revise safely. Do not inspect project-management metadata such as unrelated branches, open issues, pull requests, milestones, or release boards unless the feedback explicitly asks for them.
Follow repository standards discovered from guidance files and existing implementation patterns. If feedback requests a deviation from a repository standard, explain why the revised plan accepts or rejects that deviation.
Preserve nearby patterns — revised files and tests should stay aligned with nearby source and test patterns unless feedback justifies a change.
Keep repo:<owner>/<name> tags for repositories whose scope is unchanged. Update or add tags if the feedback changes the repository scope.
Write the revised plan to .forge/plan.md in the same structured Markdown format. Do not write any other files. Do not commit.
