implement-plan
Skill4 starsChanged 6 months agoMITView on GitHub
Reads a structured plan from a GitHub issue and orchestrates the full delivery workflow: parses unchecked tasks in dependency order, steps through them one at a time, commits via create-commit, reviews via review-pr, and opens a PR linked back to the plan issue. Use when the user says "implement #N", "implement this plan", "execute plan #N", "work through issue #N", "implement the plan in #N", or "carry out the tasks in #N". TRIGGER when: user wants to execute or implement a plan stored as a GitHub issue. DO NOT TRIGGER when: user wants to create or update a plan (use upsert-plan instead).
28 other projects use a version of this.
Adopted by
Most recently taken up by
- korcekj/skillstheir own version, first seen Oct 28, 2026
- spalladino/claude-skillstheir own version, first seen Oct 20, 2026
- TylerAkins/ai-agent-skillstheir own version, first seen Oct 15, 2026
- insapption-projects/claude-agent-team-startertheir own version, first seen Oct 15, 2026
- paultyng/skill-issuetheir own version, first seen Oct 13, 2026
- Pablomg02/pamaga-agent-toolkittheir own version, first seen Oct 11, 2026
Used with
Projects with it also use iterate-plan, validate-plan and 8 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
corticalstackSkilliterate-plan
Revise an existing implementation plan in flow/plans/ based on feedback, researching when needed. Explicit-only; run only when invoked via /iterate-plan or explicitly asked.
Also in 5 projects that use this
shawn-dumasSkillvalidate-plan
Validate an orchestration plan after pre-flight certification. Runs adversarial review, deep review (verify prompt data against codebase), and PoC gate for risky approaches. Auto-invoked by orchestrate-* skills at Step 8.
Also in 4 projects that use this
parcadeiSkilldescribe-pr
Generate comprehensive PR descriptions following repository templates
Also in 4 projects that use this
joshuaalpuertoSkillresearch-codebase
Conducts structured research across a codebase to answer questions about architecture, components, and data flow. Use when investigating how code works, where functionality lives, or how systems interact. Decomposes questions, runs parallel investigations, synthesizes findings with file:line references, and produces persistent research documents.
Also in 4 projects that use this
JetBrainsSkillcreate-plan
Research the codebase and create an implementation plan with architecture notes, design document, and track decomposition. Use when starting a new feature or large change.
Also in 8 projects that use this
JetBrainsSkillfix-bug
End-to-end bug fix workflow for the Exposed project. Accepts a GitHub issue (#NUMBER), YouTrack issue (EXPOSED-NUMBER), or YouTrack URL (https://youtrack.jetbrains.com/issue/EXPOSED-NUMBER). Fetches the issue, creates a failing reproducer test, commits on a new branch, implements the fix, validates, and opens a PR. Use this skill whenever the user wants to fix a bug from an issue tracker, mentions a EXPOSED issue number, or references a GitHub issue to fix.
Also in 3 projects that use this
Other versions28 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 28
- penpot/penpot★ 62ksame name
- ChatbotXIO/ChatbotX★ 1.1ksame name
- OpenFn/lightning★ 321same name
- maxedapps/agent-skills★ 59same name
- atomicinnovation/accelerator★ 34same name
- hawkyre/hawk-skills★ 30same name
- mhylle/claude-skills-collection★ 20same name
- L-X-T/ng-agentic-skills★ 13same name
- paultyng/skill-issue★ 8same name
- Akindu23/my-agent-skills★ 4same name
18 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- audit-skillsSkill
- create-commitSkill
- format-review-commentsSkill
- refine-proseSkill
- review-agents-mdSkill
- review-planSkill
- review-prSkill
- review-skillSkill
- upsert-agents-mdSkill
- upsert-planSkill
- upsert-skillSkill
The file
We split this skill into the rules it gives an agent
12 rules. 0 are common, 10 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 28 edited versions we read keep these.
10
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 36
If no plan is specified, ask: "Which plan issue should I implement?
- Distinctive: line 49
Call out any tasks blocked by incomplete dependencies
- Distinctive: line 58
If a task cannot be completed (missing dependency, ambiguity, external blocker), stop and ask the user for guidance before continuing.
- Distinctive: line 62
Do not: check off task checkboxes on the plan issue — leave them unchecked so the skill can be retried or re-run without losing progress …
- Distinctive: line 64
After all tasks are implemented, write a brief summary of what was done, then immediately proceed to step 4 — do not stop or wait for user …
- Very specific: line 70
Wait for the commit to succeed, then proceed immediately to step 5.
- Distinctive: line 92
If none of these are present and no convention is documented, skip this step and note it in the PR body.
- Distinctive: line 97
If a command fails, inspect the output and fix the root cause — do not suppress warnings or disable rules to make them pass.
- Distinctive: line 102
Escalation: if failures persist after 2 fix attempts, or if a failure is clearly outside the scope of this plan (e.g.
- Distinctive: line 108
When all commands pass (or the step is skipped per the rules above), proceed immediately to step 7 — do not stop or wait for user input.
- Distinctive: line 114
Keep the title concise (under 70 characters) and imperative (e.g.
- Distinctive: line 116
Create the PR using the GitHub tools available in the environment, linking back to the plan issue in the body:
“Common” is measured: kept by at least 6 in 10 of the 28 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Implement Plan
Fetches a structured plan from a GitHub issue, steps through each unchecked task in dependency order, commits the result, runs a PR review, and opens a PR linked back to the plan issue. Composes create-commit and review-pr rather than reimplementing their logic.
Instructions
Side effects: implements code changes, creates a git commit, may open a GitHub PR. Task checkboxes on the plan issue are left unchecked throughout, allowing the skill to be re-run or retried.
1. Accept input and fetch the plan issue
Accept the plan as:
- A bare integer (e.g.
126) — a GitHub issue number; infer the repo fromgit remote get-url origin - A
#Nreference (e.g.#126) - A full GitHub issue URL (e.g.
https://github.com/owner/repo/issues/126)
If no plan is specified, ask: "Which plan issue should I implement? Provide an issue number, #N reference, or full URL."
Fetch the issue body using the GitHub tools available in the environment. If the issue cannot be fetched, report the error and stop.
2. Parse and present unchecked tasks
Extract all unchecked checkboxes (- [ ]) from the issue body, preserving their order and any phase groupings. Checked tasks (- [x]) are skipped — they represent already-completed work.
Respect dependency annotations (e.g. _(depends on: Task A)_) to surface tasks in an order that satisfies all declared dependencies. When tasks are marked _(parallel with: Task X)_, implement them sequentially but note they can be batched in future runs.
Present the task list to the user before starting:
- State the plan issue number and title
- List all unchecked tasks grouped by phase (if phases exist)
- Call out any tasks blocked by incomplete dependencies
3. Implement each task in order
For each unchecked task (in dependency-resolved order):
- State which task you are beginning (e.g. "Starting: Create
.agents/skills/implement-plan/SKILL.md"). - Implement the task using the tools available (Read, Write, Edit, Bash, Glob, Grep, GitHub tools, etc.).
- Report completion: "Done:
<task description>." - If a task cannot be completed (missing dependency, ambiguity, external blocker), stop and ask the user for guidance before continuing.
Defer all lint, test, and typecheck runs until the dedicated final-validation step (step 6). In this step, do not run lint, tests, or typecheck after individual tasks — intermediate states are not the validation target, and per-task runs accumulate redundant work across the loop. All such commands are deferred to step 6, where they execute exactly once against the final post-review state. The only exception is running a command to confirm a task's concrete output (e.g. a generator script the task explicitly requires); even then, do not invoke repo-wide lint or test suites.
Do not check off task checkboxes on the plan issue — leave them unchecked so the skill can be retried or re-run without losing progress markers.
After all tasks are implemented, write a brief summary of what was done, then immediately proceed to step 4 — do not stop or wait for user input.
4. Commit via create-commit
Immediately after all tasks are complete, invoke the create-commit skill (/commit) — do not pause, summarize and stop, or ask for confirmation. Proceed directly.
Wait for the commit to succeed, then proceed immediately to step 5. If create-commit reports nothing to commit, note this and proceed immediately to step 5 — do not stop.
5. Review via review-pr
Immediately after the commit in step 4 completes, invoke the review-pr skill on the current branch against the base branch (default: main) — do not pause or ask for confirmation:
/review-pr <current-branch>review-pr will automatically fix all actionable findings and commit them. Do not run lint, tests, or typecheck during review-pr fix iteration — lint and tests are deferred to step 6, where they run exactly once on the final post-review state. Validating against each intermediate fix-and-recommit cycle is redundant, since only the final state ships. When review-pr completes, proceed immediately to step 6 — do not stop or wait for user input.
6. Run lint and tests on final state
Immediately after review-pr completes, run the repository's lint, typecheck, and test commands exactly once against the final post-review state — do not pause or ask for confirmation. This is the single validation gate; per-task and per-review runs were deferred here specifically to avoid redundant validation of intermediate states.
Command discovery (in priority order — use the first source that defines each command):
AGENTS.md/CLAUDE.md— look for an explicit "Testing", "Linting", or "Validation" section naming the commands to runpackage.jsonscripts— preferlint,typecheck,test(in that order); fall back tocheckorciif they existMakefile— prefermake lint,make typecheck,make test- Language defaults —
ruff check . && pytest(Python),cargo clippy && cargo test(Rust),go vet ./... && go test ./...(Go), etc.
If none of these are present and no convention is documented, skip this step and note it in the PR body.
Execution order: lint → typecheck → tests. Stop at the first failure; a failing lint run typically masks real type or test errors.
Fix-and-recommit loop (capped at 2 fix attempts after the initial failure):
- If a command fails, inspect the output and fix the root cause — do not suppress warnings or disable rules to make them pass.
- Invoke
create-committo commit the fix. - Re-run the failed command (and any later commands in the order above).
- Repeat up to 2 fix attempts before escalating.
Escalation: if failures persist after 2 fix attempts, or if a failure is clearly outside the scope of this plan (e.g. a pre-existing broken test unrelated to the changed files), stop and report to the user:
- which command failed
- the relevant error excerpt
- what was tried
- whether the agent believes the failure is in-scope or pre-existing
When all commands pass (or the step is skipped per the rules above), proceed immediately to step 7 — do not stop or wait for user input.
7. Open a PR linked to the plan issue
Immediately after step 6 completes, derive the PR title from the plan issue title and open the PR — do not pause or ask for confirmation.
Keep the title concise (under 70 characters) and imperative (e.g. "Add implement-plan skill to orchestrate plan execution").
Create the PR using the GitHub tools available in the environment, linking back to the plan issue in the body:
## Summary
<bullet points summarizing what was implemented>
## Plan
Closes #<plan-issue-number>
## Test plan
<bulleted checklist of how to verify the changes>Report the PR URL to the user.
Examples
Invocation with issue number:
/implement-plan 126Invocation with #N reference:
/implement-plan #126Invocation with URL:
/implement-plan https://github.com/geemus/hax-yax/issues/126Invocation (interactive):
/implement-planThe agent will ask which plan issue to implement.
Sample task presentation:
Plan: #126 — Add implement-plan skill to orchestrate plan execution
Phase 1 — Design (2 tasks):
- [ ] Define task-parsing contract
- [ ] Confirm checkpointing behavior
Phase 2 — Implementation (5 tasks):
- [ ] Create .agents/skills/implement-plan/SKILL.md _(depends on: Phase 1)_
- [ ] Write Step 1 instructions _(depends on: Phase 1)_
- [ ] Write Step 2 instructions _(depends on: Step 1)_
- [ ] Write Step 3 instructions _(depends on: Step 2)_
- [ ] Write Step 4 instructions _(depends on: Step 3)_
Phase 3 — Housekeeping (1 task):
- [ ] Run upsert-agents-md _(depends on: Phase 2)_
Ready to implement these 8 tasks. Proceed?Sample blocking-finding fix:
review-pr found 1 blocking issue:
issue [blocking]: `SKILL.md` frontmatter is missing the required `name` field
Fixing automatically…
[edits file]
Committing fix via create-commit…
[commits]
Proceeding to step 6 (lint and tests on final state).Sample lint/test failure recovery:
Step 6 — running lint and tests on final post-review state.
Discovered commands from package.json scripts: `npm run lint`, `npm test`.
Attempt 1:
$ npm run lint
✗ src/plan.ts:42 no-unused-vars: 'tmp' is defined but never used
Fix attempt 1/2: remove unused `tmp` binding in src/plan.ts:42.
Committing fix via create-commit…
[commits]
Attempt 2:
$ npm run lint
✓ passed
$ npm test
✓ 47 passed
All validation commands pass. Proceeding to step 7 (open PR).Sample full flow (happy path):
Step 3 — implementing 4 tasks, deferring all lint/test runs to step 6.
[task 1 done] [task 2 done] [task 3 done] [task 4 done]
Step 4 — /commit
Step 5 — /review-pr claude/implement-plan-126 (no blocking findings)
Step 6 — lint + typecheck + tests on final state (all pass)
Step 7 — opening PRDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

