I haven’t posted in a while, as I’ve been working on several Claude Code skills to share. I’ve made my claude-plugins marketplace publicly available. There’s a lot there, and I’ll be covering them in a series of posts.

I’ll start with the write-plan and implement-plan skills. I wrote a post on iterative planning three months ago but it feels like a million years ago. A lot has changed since then. My argument back then was that no amount of up front planning and research was going to catch every problem, so letting Claude execute a plan without supervision did not seem wise to me. That reflected my experience at the time, working in both greenfield projects and large legacy codebases. Since then, the Claude Code models have kept improving, and my ability to coax increasingly robust work out of them has also steadily improved. My updated plan skills reflect that learning. I was also inspired by the RubyConf talk I wrote about earlier, about making AI coding output trustworthy by default, as well as other similar talks and articles.

Benefits of using write-plan

1. Each step is small. The write-plan skill relies on my organize-commits skill to ensure each step is a small, and cohesive change. This makes code review easier for both humans and AI agents.
2. After the plan is drafted, it gets an independent review. Doing code reviews is important, and doing plan reviews is equally important. First, the main session double-checks that the plan isn’t missing any decisions from the conversation. Then a subagent reads the plan cold, with no conversation context from the main session. It verifies the claims of the plan (e.g. how the existing code behaves, etc) and checks for gaps and inconsistencies. It then reports back to the main session with recommended corrections. If anything requires a decision from you, it asks. I’m always amazed at how much it finds, no matter how carefully the plan was drafted.
3. You can specify how much you want to be engaged with the implementation. A plan has three options for an approval mode:
   • each step: you approve every change
   • before push: you review before a PR is created
   • draft PR: a Claude subagent does a “cold” review using my pr-review skill, the main session addresses any findings, and then opens a draft PR for your review

   If the plan includes a step where a decision is required from you, Claude will stop to ask you for it (such as a decision that can only be made after some data analysis), in any approval mode.

Benefits of using implement-plan

1. Each step runs in a fresh subagent, so the session for the main agent stays small. A plan can involve many steps, and if the implementation is running unsupervised, you want to minimize how far the main session might get into the dumb zone. The main session instructs the subagents and gets reports of their work, rather than doing the work itself. So its judgment stays sharp across a long plan. The subagents cannot edit the plan and cannot commit. The main session keeps control of both.
   • There is one exception to this: if a change is small, the main session agent will do it, rather than incurring the start-up token costs of a subagent for minor work.
2. It leverages the intelligence of the subagents. You can use a specialized coding agent if you have one, such as my rails-core agent. Departures from the plan are allowed, within the realm of implementation details. Just like a human coder, when a subagent starts implementing, it will notice things that may have been missed during planning, and it’s allowed to adjust accordingly. The subagent reads the whole plan, including the introductory Context section, so it knows about the decisions that informed the plan. At the end of each step, it reports any departures from the plan. It also reports any questions that came up, and if for any reason it gets stuck and cannot proceed after two attempts at fixes, it will stop and report the situation (I’ve never had this happen, but it’s there as a failsafe so the agent doesn’t churn and burn excessive tokens).
3. Each steps ends with the main session doing a series of checks and updates:
   • Running tests and linters for the code that was changed
   • Optionally running a separate review subagent
   • Updating the status of the plan
   • Commiting the changes (it uses my commit-messages skill to write clear and concise messages, focusing on “the why” of the change, instead of reciting what was changed).
4. Plan progress is documented. Each step is marked with a ✅ when it’s done, so your progress on the plan is clear. After completing a step you can stop and resume later if needed.
5. It checks project documents and cleans up when it’s done. it reads CLAUDE.md, README.md, and any other standing documents and makes any needed changes (with your approval). It trims the implementation detail from the plan file, but keeps its Context section and a short record of each step, as they may be useful for future reference (you can of course delete them if you prefer).

The workflow for using the skills

1. Determine the goals and scope. The write-plan skill is literally for writing the plan, so you will want to discuss the goals of the work before invoking it. I highly recommend Matt Pocock’s grilling and grill-with-docs skills to flush out all the details and possible gaps in what you want to do. Start the grilling session with a brain dump of what you want to do. The grilling skill then interviews you with a series of questions that drive you to reach a “mutual understanding” of the work to be done. I recommend scoping the conversation to what you would put in typical pull request. Alternately, if you are planning a large project, you can keep the conversation at a high level and write an “epic” level plan, which will encompass several smaller plans that you’ll flesh out later.
2. Write the plan. This part is easy, as the write-plan skill will take the results of the grilling session and organize it into a well defined, step by step plan. The first time you use the skill, it will ask you where you prefer to save plan files, and it will record your preference per project. I’m not a fan of Claude’s default ~/.claude/plans directory, as I like to keep my plans with the relevant project, but it’s up to you.
3. Compact or clear the session. The grilling and plan writing will use up a good chunk of a session’s context. Clearing or compacting the session after writing the plan gives you a fresh context for implementing the plan.
4. Implement the plan! As noted above, it will follow the approval mode you selected for the plan.