Skip to content

Instantly share code, notes, and snippets.

@toppa
Last active August 23, 2026 14:59
Show Gist options
  • Select an option

  • Save toppa/8f7141b3620c962dbe0597b3f88a9357 to your computer and use it in GitHub Desktop.

Select an option

Save toppa/8f7141b3620c962dbe0597b3f88a9357 to your computer and use it in GitHub Desktop.
My implement-plan Claude Code skill, for iterartive planning and implementation
name implement-plan
description The workflow that runs while a plan document is implemented — one step at a time, each closed by checks, a review by the user, an update to the plan, and a commit.
when_to_use Use when you implement a plan document, when you pick up a plan that is part done, and when you finish a step and need to know what closes it. For writing the plan in the first place, use the `dev-workflow:write-plan` skill.

Implementing a plan

Work the plan one step at a time. Finish the current step's completion workflow before you start the next step.

Before the first step

  • Set the plan's Status line to in progress.

Step completion workflow

Run this at the end of every step that produces code to commit.

  1. Run the checks. Run the tests and the linters over the changed files. The project's CLAUDE.md names the commands.
  2. Ask for a review. Ask the user to review the code. Name where the code departed from the plan. Wait for them to confirm that the review is finished and the code is approved. Until they confirm, leave the plan unchanged and draft no commit message.
  3. Update the plan document. Mark the step ✅. Where the implementation departed from the plan, edit the step to match what you built. Edit every later step the departure changes. The plan holds no historical record.
  4. Update the standing documents. Where the step settled a term, a rule, or a decision, edit the document that owns it — the glossary, the rules file, an ADR. The write-plan skill's "Standing documents outrank the plan" section names them. The closing pass below is the backstop, and not the first opportunity.
  5. Commit. Draft the message with the commit-messages skill, which also covers the approval the message needs before git commit runs. Include the updated plan document, and every standing document this step changed, in the commit.

After the final step

  • Read the project's CLAUDE.md and README.md, and every standing document CLAUDE.md names. Update whatever this work made stale.
  • Find what cites the plan, before you trim it. A plan is where the reasoning gets written while the work runs, so other documents end up pointing at it for detail none of them copied. Send that detail to a document that owns it, then repoint each pointer. Search two ways: for the plan's path, and for the words the project uses to name a plan in prose. A pointer that reads "the known gap from the plan" carries no path, and a search for the filename will not find it.
  • Keep the plan file. Trim it to its Context and a short record per step. The Context is the handoff to the plan that follows it, and it is what earns the file its keep.
  • Set the plan's Status line to done.
@toppa

toppa commented Aug 23, 2026

Copy link
Copy Markdown
Author

For revision 2, please see my comment on the update to the write-plan skill for an overview.

Two additional points for the implement-plan update:

  • The step completion workflow now says to update standing documents at the end of each step. The original guidance was to update them when the plan was complete. The problem with the original approach is that important updates from an early step could be forgotten by the time you get to the end of the plan.
  • When implementation is complete, we remove implementation details from the plan. These will naturally go stale over time, and the part of the plan worth keeping around is the Content section, and then just a concise record of what was done in each step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment