planning-flow-quick

Planning Flow — Quick

Overview

Turn a small request into one short plan: the change, where it goes, the pattern it copies, the tests it extends, and the decisions behind it. It is the lighter version of the planning-flow skill: it skips the full codebase map, the parallel exploration, the separate reviewers, the second opinion, and the delivery-shape question. It keeps the parts that stop a small change from going wrong: following the repository's patterns, extending the right tests, settling unknowns before they are built on, and leaving the user's decisions to the user.

A quick plan that stops being quick is one failure this skill watches for; a small change interrupted by switch offers the user did not want is the other. The Too big for a quick plan section below names the signs, how to judge them, and the one offer to switch, which a user's no ends for the session.

These rules bind everything below:

1. The plan never describes its own earlier versions. Every revision rewrites the file in place, so it reads as if written fresh today. The decisions section is the only memory: a choice, its alternative, and its reason. No "revisited", no "Edit:", no "after the check", no struck text.
2. The reader has not seen the code. A function, file, or variable name is a label for a thing you explain in plain words, never the explanation (communication.md).
3. Technical direction is yours, logged; functional and operational direction is the user's, asked. The test: if a reasonable user could say "I didn't want that", the decision is theirs. Output, wording, defaults, ordering, error behavior, what is stored and where, and how the thing is deployed or configured are the user's. A decision the user already made in chat is never asked again: log it with their words. A choice with one workable answer is not a question either — list the alternatives first, and when every one but one fails the ask, decide it and log it — and a principle the user settled in this feature is followed, not asked again (question-format.md).
4. Facts are yours to find; decisions are the user's to make. Ask only what the codebase cannot answer, in the one shape in question-format.md, one question per chat message. Never answer a question you put to the user. A change may have no questions; do not invent them.
5. The new code looks like the code around it. The plan names the pattern the change follows and the closest existing example, and every acceptance criterion names the test it extends. A small change that ignores the repository's conventions is not small; someone pays for it in review.
6. An unknown a check can settle is settled now, or you ask to settle it now. If an answer would change the plan, run the check at once or ask permission at once (verification.md). Never write that something "could be tested" and move on. A quick plan that turns out impossible at implementation time saves nothing.
7. The plan is a document, and it plans the simplest thing that works. The deliverable is markdown. Probes are encouraged while planning and deleted before the plan is shown. Reuse what the codebase, the standard library, the platform, or an installed dependency has before planning new code. Never cut validation at a trust boundary, data-loss handling, security, or accessibility.
8. Nothing an agent writes counts things that live elsewhere. No "the 24 handlers", no "all seven tests": list them or state the rule that finds them. A number stays only when it is the fact: a limit the code enforces, a version, a size band.
9. Every subagent is one-shot; more work is a new subagent. Each subagent gets one self-contained prompt, returns its result, and ends. It never waits for a reply, for the user, or for your next instruction, and you never resume, message, or continue it (SendMessage in Claude Code, or the equivalent). A follow-up goes to a new subagent with everything it needs, the earlier result included. An idle subagent loses its prompt cache within minutes, so the next message re-reads its whole history at full price.
10. Long commands keep a heartbeat no more than three minutes apart. A command that may run past three minutes (a test suite, a build) starts in the background with output and exit code going to a log, ( <command>; echo "EXIT=$?" ) > <log> 2>&1 &, and is checked with a foreground loop capped at three minutes, for i in $(seq 18); do grep -q '^EXIT=' <log> && break; sleep 10; done; tail -n 3 <log>, repeated until the log shows EXIT=. Never a bare sleep, never a monitor with no cap, never ending the run while the command is still going. Past about 40 minutes of expected wait, one cold restart is cheaper than the checks. Every prompt template in this skill ends with a line that says so. Waiting for a subagent's report is not a command: the harness tells you when it returns, so never loop, sleep, or poll for one.