I have a skill for planning features with AI: rstack-plan, one of the skills in rstack. I use it when I describe something I want to build, not a bug. For bugs I have another one.
It does one thing: it listens, checks what already exists and negotiates the plan with me, question by question, before touching code.
The rule
The skill starts with a sentence: don't act on assumption, propose or listen, never just do.
It came from something that happened to me. I asked the AI to think through a new skill together and, instead, it handed me a finished diagram, with its own design, without having first confirmed that it had understood what I wanted. The solution wasn't asking it to think harder. It was a structure that makes jumping ahead impossible.
Its job ends in an approved plan, saved in the repository. It doesn't write implementation code: whatever happens after approval is separate work.
And Claude Code's plan mode
Claude Code already has a plan mode: according to its documentation, Claude reads files and proposes a plan, but makes no edits until you approve. It works for not touching the disk.
What I'm after is something else. A plan that arrives whole, all at once, is a decision made alone with an approval request attached. I want the plan to be built with my answers.
The four phases
Each phase ends with a stop: the skill tells me what it has done and waits for my answer before continuing.
The first is listening. It restates my request in its own words, without adding scope. It doesn't search the code or touch anything yet. If the request is ambiguous, it says what is ambiguous instead of resolving it by guessing the obvious interpretation. And it waits for explicit confirmation. A "yes" counts. A correction is not a soft adjustment: it goes back to phase 1 and restates from scratch. There is no exception for size: a request that looks simple goes through the same gate.
The second is looking at what already exists, read-only. The question isn't how something similar is done here, in the abstract. It's whether something that already exists can be used as is, instead of building something new. For each piece it finds, it says whether it can be reused as is, with changes or not at all, and why. The example the skill gives: if I ask for a new kind of plugin, the right output of this phase is "there is already a working OAuth flow for plugin authentication, reuse it", not a generic review of authentication patterns. This is where the first file is written, specs/<feature>/spec.md, with the what and the why, never the how.
The third is proposing, by negotiation. It doesn't hand me a complete plan. It asks me questions one at a time about what the previous phase left open, and the plan is built with my answers. Each question has to be answerable in a single message: it doesn't pack three decisions into one because it's faster. The plan.md file grows with the conversation: after each answer, the relevant section is updated, not at the end. A file that is only written at the end is the chat transcript with extra steps.
If the feature has a flow or several actors, the skill draws a diagram and keeps updating it as I decide each piece. For that it uses archify if it's available. If it isn't, it says so and carries on with text only: it doesn't fake a diagram in ASCII.
The fourth is the approval gate. There are only two valid answers: "this plan is enough", and then spec.md and plan.md are the deliverable and nothing gets implemented; or "yes, implement it", and the skill ends, because implementation is separate work. A "sure", a thumbs up or changing the subject is neither, and it asks again. When the gate closes, it gives me the file paths and doesn't commit them to git: that's up to me.
The red flags
These are the signs that force a stop:
- Writing the whole plan before asking a single question.
- Drawing a diagram "to show progress" before I have decided that piece.
- Treating an "ok", or silence, as approval.
- Looking for existing code after proposing a new design instead of before. If reuse doesn't come first, it never gets considered.
- Skipping a phase because the request "seems simple".
- Keeping the decisions in its head and writing
spec.mdandplan.mdall at once at the end.
Which files it writes
Only three kinds: spec.md, plan.md and the drafts of their diagrams. It never touches the application's code.
It also doesn't create by default the rest of the files from the spec-kit convention, GitHub's toolkit for spec-driven development: data-model.md, contracts/, research.md or tasks.md. It adds one only if that feature needs it, and says why.
What it costs
It asks more questions and is slower than a plan delivered all at once. That's on purpose. And it isn't for everything: it's meant for features that aren't trivial, not for a bug. A configuration value or a single field doesn't get a diagram, although it does go through the first gate.
For something new, make it ask before it proposes.
Top comments (0)