← All craftbooks

Plan

Documents and decksevalv1.0.1released 2026-07-26workflow: build-loop

Steps

Entry step: frame. Each step names the specialist role it wants; the full working prompt is expandable.

1. Frame the goalplannerentry

   Write a strong 'about' and set the outcomes on the draft plan.

   Show working prompt

   You are drafting a PLAN. The plan is a separate **draft task** — its ref is in your task's `craftbookParams.draftRef` (shown in your task description / entry note). Everything you author here targets that draft via the `task` argument.
   
   Your next message must START with a tool call — not a description of what you are about to do. Make exactly these two calls, in this order, then stop:
   
   1. `update_task({ task: "<draftRef>", description })` — the job-to-be-done from the user's perspective, 120+ characters.
   2. `set_outcomes({ task: "<draftRef>", outcomes: [ ... ] })` — 3–8 concrete, individually-verifiable statements of what gets created or updated.
   
   Neither call is optional and prose is not a substitute for either: the gate reads the draft itself and rejects until both landed.
   
   **Detail:**
   
   1. **Write a strong "about".** Call `update_task({ task: "<draftRef>", description })` with a clear job-to-be-done from the user's perspective — what success looks like, in 120+ characters.
   2. **Set the outcomes.** Call `set_outcomes({ task: "<draftRef>", outcomes: [ ... ] })` with 3–8 concrete, individually-verifiable statements of what should be **created or updated** at completion (e.g. "An index.html with a playable snake game and a game-over/restart screen", "A README documenting how to run it").
   
   When done, call `advance_task_step({ ref, stepId: "frame", next: "outline" })`. The gate rejects until the draft has a real about and at least 3 outcomes — fix what it names and advance again.

2. Design the build stepsplanner

   Add ordered build steps to the draft, each gated on a concrete static deliverable.

   Show working prompt

   Design the implementation as an ordered series of **build steps** on the draft (`craftbookParams.draftRef`). Each build step must produce a **concrete static file** with an enforced gate.
   
   The draft starts with one placeholder step named **"Implement"**. First call `craftbook_read({ task: "<draftRef>" })` and note the actual id of that placeholder step. Then either:
   - repurpose that exact step with `craftbook_update_step({ task: "<draftRef>", stepId: "<actualId>", name, prompt, suggestedRole })`, then immediately call `set_step_deliverable({ task: "<draftRef>", stepId: "<actualId>", path, kind })`; or
   - remove that exact step with `craftbook_remove_step({ task: "<draftRef>", stepId: "<actualId>" })` after you have added the real build steps.
   
   For each added step, in order:
   1. `craftbook_add_step({ task: "<draftRef>", name, prompt, suggestedRole })` — a concrete, instructive step (e.g. name "Build the game", role "developer", a prompt that says exactly what to make).
   2. Call `craftbook_read({ task: "<draftRef>" })` and use the actual id of the step you just added.
   3. `set_step_deliverable({ task: "<draftRef>", stepId: "<actualId>", path, kind })` — declare the named file it produces and auto-attach the gate. Pick `kind` to match the artifact: `html-page` / `html-game` / `markdown-report` / `code-with-tests` / `json` / etc.
   
   Do not invent step ids like `build` unless `craftbook_read` shows that exact id. Do not advance while any build step lacks `advanceWhen`/`gate`. Order the steps so each builds on the last. When every build step has a deliverable, call `advance_task_step({ ref, stepId: "outline", next: "verify-step" })`. The gate lists any step still missing a deliverable.

3. Add the verification stepplanner

   Append a terminal verification step that checks the outcomes were kept.

   Show working prompt

   Add the final **verification step** to the draft (`craftbookParams.draftRef`): call `add_verification_step({ task: "<draftRef>" })`. This appends a terminal step — gated by `checkOutcomesMet` — that makes the executor confirm each outcome (with evidence) before the task can close. Pass a custom `prompt` only if you need domain-specific verification instructions.
   
   Then call `advance_task_step({ ref, stepId: "verify-step", next: "review" })`. The gate rejects until the draft has a terminal step that verifies the outcomes.

4. Review the planplanner

   Sanity-check the whole plan before handing it to the user.

   Show working prompt

   Final check before handing the plan to the user. `craftbook_read({ task: "<draftRef>" })` and sanity-check: the steps are ordered sensibly, each build step has a deliverable, and the last step verifies the outcomes. Fix anything off with the `craftbook_*` / `set_step_deliverable` tools on the draft.
   
   When the plan is solid, call `advance_task_step({ ref, stepId: "review", next: "done" })`. The gate returns a single list of anything still missing (thin about, fewer than 3 outcomes, ungated steps, or no verification step).

5. Hand off to the userplanner

   Summarize the plan and tell the user to review and activate it.

   Show working prompt

   The plan is ready. Summarize it for the user in your reply: mention the draft task **<draftRef>** by its ref (so it renders as a reviewable plan card), and recap the about, the outcomes, and the build steps. Tell the user they can **review and activate** the plan to run it — or ask you to tweak it first. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

• plan this
• make a plan
• plan for
• /plan

Source

View this craftbook on GitHub · MIT license