Structure
Create your company
Skill

plan

before work starts on anything that spans a sitting, a handoff, or a gate — turn the intent into a decision-complete plan

Turns an intent into a plan whose every step is already decided, so whoever executes it makes no judgment calls the planner could have made. For work that spans a sitting, a handoff or a review gate.

structure generate skill plan

Skill — plan

Invoke in any agent conversation with /plan and an intent — a sentence about what should be true that is not true yet. What comes back is not a to-do list: it is a plan whose every step is decided, so the person or agent executing it makes no judgment calls the planner already had the context to make. The grammar below is a starting opinion; edit it until it matches how this company actually decomposes work.

When to use. Before work starts on anything that will span more than one sitting, more than one pair of hands, or any review gate. Not for a one-command errand — a plan that costs more than the work it plans is ceremony.

Read first. A plan steers from canon, and says what it read: the roadmap (does this intent even rank?), the owning department's mission and steering docs (the standards the work will be reviewed against), and any process definition the department keeps for this kind of work — when one exists, the plan's steps feed that process's stages and gates by name, never a private version of them. Open the plan with one line citing what was read.

The audience rule. Write every step for a reader with zero context and no stake in how it gets done — someone who will do exactly what the step says and nothing it merely implies. Where a step leaves the choice open, the plan has handed back a decision it had the context to make; decide it in the step, or raise it as an open question at the top with a named owner. Soft words inside a step — "probably", "as appropriate", "if needed" — are undecided decisions wearing a costume.

The step grammar. A step is decision-complete when it names five things:

  1. Its outcome — what is true after, said as a postcondition, not an activity. "The door test passes behind the flag", never "work on the door".
  2. Its territory — the files, surfaces, or accounts it touches. Two steps that can run in parallel have disjoint territory, and the plan says so.
  3. Its dependencies — the steps it needs, by number, so everything ready can start at once.
  4. Its Verify: clause — the named check that proves the outcome: the test file, the command and the output it must show, or the named reviewer. This is the evidence bar, and it is named before the work starts, because a check chosen after the fact tends to be the one that passes.
  5. The gate it feeds — which review or approval boundary consumes this step's output, by name. A step that feeds no gate says "no gate" out loud rather than leaving it to be guessed.

Parks. What was considered and not admitted is written down at the bottom as parked, each with one sentence on why — a plan that silently drops half the intent is how the same conversation happens twice.

The Iron Law. A plan step without a named verification is not a step — it is a hope with a number in front of it. There is no plan so small and no deadline so close that the Verify: clauses come off; an unverifiable plan spends its savings at exactly the moment you can least afford it, when "done" turns out to be an opinion.

Where it lands. A plan that binds only you can stay in the conversation. A plan that would bind anyone else — spend their hours, claim their territory, change a standard, or feed a gate someone owns — lands as a proposal through the propose gate (structure propose), never as a direct write to a gated path. Stamp skill: plan in the plan document's frontmatter: that is what places it in the plan sensor's jurisdiction, so structure check reads the steps mechanically (warn tier — a missing Verify: label is a reason to look, never a build break) and the review reads them with judgment.

The refusal. Asked for a "quick plan, skip the checks" — or any plan whose steps are to be taken on faith — this skill refuses and says why: the checks are not overhead on the plan, they are the plan. What it offers instead is smaller scope with the checks kept, because a plan you cannot verify is one you cannot hand to anyone, including yourself next week.

Also in the folder

Sources — the plan skillskills/plan/_sources.md

Sources — the plan skill

Provenance for the adaptation: the discipline in SKILL.md was adapted 2026-08-22 from two MIT-licensed skill libraries, named here so the lineage lives beside the file it shaped. The formal attribution is the repo root's NOTICE; this note is the local copy of the trail. No verbatim text was copied — the rule forms and method were adapted and rewritten against this repo's own process grammar.

  • obra/superpowers (Jesse Vincent) — MIT. The writing-plans audience rule (write each step for a reader who brings no context of their own), and the Iron Law + refusal form its skills carry.
  • gstack (Garry Tan) — MIT. The spec skill's intent-to-executable-spec phasing and the plan-review chain's habit of feeding a named gate rather than ending at prose.

Corrected 2026-08-22. This note used to quote the upstream's own phrasing of the audience rule, and SKILL.md used that phrasing in its body — where it rendered into every scaffolded company. Under the ratified licensing boundary a generated document arrives clean, so the rule is now stated in our words and the quoted phrase is gone from both files. NOTICE is append-only; the correction is appended there rather than edited over.

Adapted for the authorized skill set: process-aware (the skill reads canon, cites the gates it feeds, and lands binding output as proposals through the propose gate), compile-time placeholders, description as trigger conditions only, and the adversarial refusal pinned in packages/engine/test/plan_skill_test.ts. The underscore name keeps this note out of the catalogue: it is machinery beside the skill, and no generator renders it into a company.