Turning Designs Into Executable Plans

Overview

Turn a validated design — usually a /brainstorming design doc — into a plan that can be executed task by task. Write it for an executor with zero prior context for this work who will follow it literally: spell out which units or artifacts each task touches, the concrete outcome that proves the task is done, and how to confirm it. Hand over the whole thing as a sequence of tasks, each sized to a meaningful human review checkpoint — walked through together, never executed autonomously.

Domain-agnostic: the executor might be writing code, booking a trip, or rebalancing a budget. Translate every instruction to the domain rather than assuming software. YAGNI throughout — plan only what the design calls for.

Start from the validated design

Planning is the consume side of the design → plan handoff. It expects a validated design to already exist — normally a /brainstorming design doc.

• Locate and read it in full. Find the design doc (it lives in the context the design belongs to — an execution partner's repo, a project layer, or working/ for Yggdrasil itself) and read the whole thing, not a skim. The plan is only as sound as the design under it; reading partially is how requirements get dropped.
• No validated design yet? Planning is downstream of design — don't build a plan on a vague idea. Recommend /brainstorming first and stop. (The lone exception is work trivial enough that the design gate would have waved it through — but then there's little to plan.)
• Confirm the source. Tell the user which design doc you're planning from before you start drafting tasks, so a wrong or stale design surfaces now rather than after the plan is written.

Scope Check

Before drafting tasks, check the design's scope. If it really covers several independent pieces (a feature and a billing system and analytics; or "get the finances in order," which is budgeting and debt payoff and retirement), it should have been decomposed during brainstorming. If it slipped through, say so and suggest one plan per piece rather than one sprawling plan — each plan should produce a self-contained, verifiable result on its own.

This is a backstop for the decomposition brainstorming's own Scope Check is meant to have done; catching it here is cheaper than discovering it mid-execution.

Map what the plan touches

Before defining tasks, list the units or artifacts the plan will create or change, and what each one is responsible for. This is where the decomposition gets locked in — task structure follows from it.

• One responsibility per unit, clear boundaries. Each piece should do one thing with a well-defined edge — a code module, a single booking, a budget category, a document section.
• Group by what changes together. Things that move as a unit belong together; split by responsibility, not by incidental layer.
• In an existing context, follow its established patterns. Don't unilaterally restructure what's already there; match the conventions in place. If something you're touching has grown unwieldy, a deliberate split can be part of the plan.

Translate to the domain: in code these are files and modules; for a trip, the legs and bookings; for a budget, the accounts and categories.

Plan document header

Every plan opens with this header:

# [Name] Plan

**Goal:** [one sentence — what this plan accomplishes]

**Approach:** [2–3 sentences on how, at a high level]

**Design source:** [path to the validated design doc this plan derives from]

---

Design source is a back-pointer to the design doc the plan came from — anyone reading the plan can reach the reasoning behind it. Keep the header lean: goal, approach, and that pointer, nothing more.

Tasks — each anchored to a verifiable outcome

A task is the unit of the plan. Every task is anchored to a verifiable outcome: a concrete, checkable result, plus how you'll confirm it's reached. This is the spine of the whole skill — if a task has no checkable outcome, it isn't a task yet.

• Name exact targets. Which units or artifacts the task touches, named specifically — exact file paths and commands in code; "lodging for Jun 26–28" for a trip; "the Q3 grocery category" for a budget. No vague "the relevant files."
• Spell out the work. Include the actual content the executor needs to do the task — they have zero prior context and will follow it literally. (What counts as "spelled out" enough, and the placeholders that fail this bar, get their own section below.)
• State how it's confirmed — and bring the result to the review. Each task ends in a check: a command with expected output, a passing test, a confirmation email, a total that balances, "the section reads right on a re-read." When a check is machine-checkable, run it and present the findings — the machine result is evidence the human weighs at the checkpoint, never a substitute for the human seeing it. (A task whose outcome is fully machine-confirmable on its own is usually too small to stand alone — fold it into a larger task, unless it matters enough to deserve its own designated review step.)

Size each task to a meaningful human review checkpoint — the point where it makes sense to stop and confirm the outcome before moving on — not the smallest possible step. The smallest-step sizing assumes an unattended executor churning through tasks; we walk the plan together, so the task is the natural review unit. Let detail scale to complexity: a simple task is a sentence or two; a nuanced one spells out more.

Task shape

### Task N: [short name]

**Touches:** [exact units/artifacts — paths, bookings, categories, sections]

[The work, spelled out in full — the content the executor needs, in order.]

**Done when:** [the concrete, checkable result]
**Confirm by:** [the check whose result you bring to the review — a command +
expected output, a test run, a received confirmation, a balanced total, a re-read
together]

Two quick translations of the same shape:

• Code — Touches: src/auth/session.ts. … Done when: the session-timeout test passes. Confirm by: run npm test session (expect 12 passing) and present the output.
• Trip — Touches: lodging, Jun 26–28. … Done when: a room is booked for those nights. Confirm by: the confirmation email in the inbox.

No untracked placeholders

Every active task must contain the actual content the executor needs — they have zero prior context and follow the plan literally. A vague gap left inside a task that's presented as ready is a plan failure. Never write:

• "TBD", "TODO", "figure this out later", "fill in details"
• "Handle the edge cases" / "add appropriate safeguards" — without saying which ones, and how
• "Same as the previous task" — repeat it; the executor may read tasks out of order
• A step that says what to do without saying how (in code, the actual code; in any domain, the concrete instruction)
• A reference to something — a function, a booking, a figure — defined in no task

The carve-out — deliberate deferral is not a placeholder. This rule forbids the untracked gap, not the honest "not yet." Work you're consciously setting aside goes in the plan's ## Deferred section (next), where it's dated and visible. What makes a deferral legitimate is being placed there — not how good its reason is. So the line the rule actually polices is the masquerade: a vague "TBD" sitting inside an active task, pretending to be ready. A deliberately deferred item, parked openly, is fine.

The Deferred section

Plans get a dedicated ## Deferred section — the home for work consciously set aside. It's the hottest parked-item store and the one that lives in the plan, right next to the active tasks it may turn into.

Notation — a dated prose bullet, optionally carrying a revival trigger (what would bring it back):

## Deferred

- **2026-06-26** — Automated reminder emails for the itinerary. Trigger: once the
  itinerary is locked.
- **2026-06-26** — Comparison-shop the flights harder. Trigger: didn't have the
  energy today — revisit when fresh.

• The trigger is encouraged, never required. A sharp one names a dependency or an external event; an honest soft one ("no spoons for this right now," "didn't feel like it today") is equally valid. Recommend a sharper trigger when none is given — but don't push. A deferral with only a soft reason is still fully tracked.
• Exits — three ways out: promote to an active task (the trigger fired, or you're ready to spell it out); demote to bookmarks.md (it turned out bigger than this plan, or not really this plan's job — offered, never forced); prune (decided against — drop it).
• Re-deferring appends a dated update rather than rewriting, so the history stays visible.

Reviewing the section over time — surfacing deferrals whose trigger has fired or that have simply aged — is the job of the session bookends and the hygiene routine, not this skill. Planning's job is to author the section and keep the No-Placeholders line honest.

Isolate execution from the source of truth

A plan that will be carried out should keep the work-in-progress from corrupting the thing it changes until the work checks out. That's the domain-neutral kernel: isolate in-progress execution from the source of truth. For a budget, that's working a copy before touching the live ledger; for a document, a draft alongside the published version.

Assume the plan is git-backed by default. Most work benefits from revision history, and most of what these plans produce is markdown — cheap and natural to keep in git — so default to a git repo even for non-code domains, falling back to the bare kernel above only when something genuinely can't live in git. With git, the concrete isolation mechanism is a git worktree (or at least a branch): execution happens on its own branch under .worktrees/, isolated from main, and merges back once the work checks out.

• Call for the isolation in the plan, so the executor works in a worktree rather than directly on the source of truth.
• The kernel from using-git-worktrees: detect existing isolation before creating more; prefer the native worktree tool; keep .worktrees/ gitignored; never write on main without consent.

The worktree lifecycle — creating one on the way in, merging / keeping / discarding on the way out — is wired into the session bookends (/good-morning, /save-progress), not performed by this skill. Planning's job is to call for the isolation; the bookends provide it.

Save the plan

Save the finished plan to whichever context the plan belongs to — the same place its design lives, not Yggdrasil:

• A plan for an execution partner (e.g. Odin Codin')? Save it in that partner's repo working directory.
• A project-specific plan? Save it in the project layer.
• Planning Yggdrasil itself? working/ in this repo.

Mirror the design doc's location and stem. Name it <name>-plan.md — the design's short-name with the -design suffix swapped for -plan, no date while active — so the design/plan pair shares the exact stem and sits together (e.g. list-hygiene-design.md ↔ list-hygiene-plan.md). A date is prepended only at archive time (YYYY-MM-DD-<name>-plan.md). Tell the user where you saved it. Saving is durable on its own; hold off on committing until the reviews below are done — that's the natural commit point, and you can prompt for it then.

Self-Review

After writing the complete plan, look at it against the design with fresh eyes. This is a checklist you run yourself, not a subagent dispatch — fix what you find inline, then move on.

1. Design coverage. Skim each part of the design. Can you point to a task that delivers it? List any gaps and add the missing tasks.
2. Placeholder scan. Hunt the No-Placeholders red flags. Every active task is either fully spelled out or moved to ## Deferred — catch any masquerade (a vague "TBD" posing as a ready task).
3. Verifiable outcome. Does every active task carry a concrete "Done when" and a "Confirm by"? A task with no checkable outcome isn't finished being written.
4. Consistency. Do the names and references in later tasks match what earlier tasks define? A thing called one name in Task 3 and another in Task 7, or a task that depends on an output no earlier task produces, is a bug.

Fix issues inline — no need to re-review, just fix and move on. If a design requirement has no task, add the task.

Lens audit (optional, scaled to the stakes)

Once the plan is written and self-reviewed, optionally put it through a lens audit — perspective passes that attack the finished plan from distinct angles, each catching a class of holes the others miss. This is where review shifts from "is it built right?" to "is it the right, robust, bearable, durable, in-bounds plan?"

Four orthogonal lenses (harvested from the community multi-agent-brainstorming skill, run our single-thread, human-in-the-loop way):

Treat each lens's axis as a focus hint — what it looks at — not a rigid set of rules it must police.

Scale the pass to how much the work matters, and present it as a choice, never forced:

• Skip — trivial work; no lens pass.
• Single-thread — you roleplay the lenses yourself and present one consolidated read. Lighter; accepts some echo-chamber risk. For work that needn't be bulletproof.
• Independent subagents — dispatch a lens per subagent to attack the finished plan; you synthesize their findings for the user. This breaks the echo chamber, and it's a textbook subagent fit (a complete artifact, one-shot fan-out, independence buys the hole-finding). For work that matters.

Lens subagents stay inside the advisory carve-out: read-only, their product is critique (risks and sharper questions — never decisions, writing, or actions), and findings route through you to the user. The user is the Arbiter — they weigh the findings and decide what to act on; the audit informs, it never overrides.

Execution handoff

When the plan is written, self-reviewed, and any lens audit is done, it's final — the natural point to commit the plan doc (prompt the user if they haven't already).

There's no autonomous-execution fork here — no subagent grinding through the tasks unattended. Execution is the two of you walking the plan together, task by task:

• Take the next task, do the work, and confirm its outcome — run the "Confirm by" check and present the result (a machine check is evidence for the human, never a substitute for their review).
• Stop at that checkpoint and let the user confirm before moving on. That pause is the human-in-the-loop gate the whole skill is built around.
• Adjust as you go: a task that turns out not-yet moves to ## Deferred; a deferral whose moment has come gets promoted up into the tasks.

Disposing of the work itself — merging the session worktree back, keeping it, or discarding it — belongs to the session bookends (/save-progress), not this skill.

Don't kick off execution silently or automatically. The plan is the handoff artifact; the user decides when to start the walk.

Exit Criteria

Exit planning only when all of these are true:

• the plan covers the design — every part maps to a task
• every active task carries a verifiable outcome (a "Done when" and a "Confirm by")
• no untracked placeholders — deliberate deferrals live in ## Deferred
• self-review done
• lens audit done, or deliberately skipped
• plan saved to its context (committed at the execution handoff)

Gate: if any criterion is unmet, keep refining — don't begin execution.

Key Principles

• Human-in-the-loop — never autonomous execution
• Every task anchored to a verifiable outcome
• Exact targets, spelled out — write for zero prior context
• No untracked placeholders; defer deliberately, in the open
• Size tasks to a human review checkpoint
• Translate everything to the domain
• YAGNI