@bendyline/gilde 0.1.4 → 0.1.5

package/data/craftbook-templates/pl/plan/versions/1.0.1/test.json

@@ -1,91 +0,0 @@
-{
-  "schemaVersion": 1,
-  "title": "Reviewable draft task plan",
-  "objective": "Measure whether the plan craftbook creates a real draft task with a substantial about, concrete outcomes, gated build steps, and a terminal verification step.",
-  "tags": [
-    "planning"
-  ],
-  "prompt": "In the `Plan Eval` project, author a reviewable draft plan for building a self-contained `index.html` bug triage board for a small support team. The eventual board should let users add bugs, assign severity, filter open/closed items, and show a summary. Use the plan flow/start_plan rather than building the board now: the output should be a draft task with strong outcomes, ordered gated build steps, and a final verification step for the user to review and activate. Important: every non-terminal build step on the draft, including the initial placeholder step if you keep or rename it, must get `set_step_deliverable({ task: \"<draftRef>\", stepId, path: \"index.html\", kind: \"html-page\" })` before you finish.",
-  "setup": {
-    "projectName": "Plan Eval",
-    "about": "Self-contained eval project for the plan craftbook. The deliverable is a reviewable draft task, not workspace files.",
-    "missionObjectives": "Author a high-quality draft task plan for a bug triage board, including outcomes, gated build steps, and verification before activation. A build step is not gated until set_step_deliverable is called on that exact step.",
-    "files": [],
-    "worker": {
-      "name": "Pieter",
-      "role": "Planner"
-    }
-  },
-  "mocks": [],
-  "success": {
-    "summary": "A task sourced from the plan craftbook points to a draft task with outcomes, gated build steps, and terminal verification.",
-    "taskGraph": {
-      "checks": [
-        {
-          "kind": "contains",
-          "file": "task-graph.md",
-          "pattern": "index.html",
-          "flags": "i"
-        },
-        {
-          "kind": "contains",
-          "file": "task-graph.md",
-          "pattern": "bug|triage",
-          "flags": "i"
-        },
-        {
-          "kind": "contains",
-          "file": "task-graph.md",
-          "pattern": "severity",
-          "flags": "i"
-        },
-        {
-          "kind": "contains",
-          "file": "task-graph.md",
-          "pattern": "verify|outcome|evidence",
-          "flags": "i"
-        }
-      ],
-      "requireCraftbookTask": true,
-      "requireDraftRef": true,
-      "draft": {
-        "status": "draft",
-        "minDescriptionBytes": 120,
-        "minOutcomes": 3,
-        "minSteps": 3,
-        "requireTerminalVerification": true,
-        "requireGatedBuildSteps": true
-      }
-    }
-  },
-  "rubric": {
-    "artifact": {
-      "path": "task-graph.md",
-      "kind": "markdown"
-    },
-    "axes": [
-      {
-        "name": "playability",
-        "description": "The game is actually playable: input works, state advances, and a session can be completed."
-      },
-      {
-        "name": "completeness",
-        "description": "Core loop, scoring/win-lose, and restart are all present rather than stubbed."
-      },
-      {
-        "name": "polish",
-        "description": "Visual design and feedback (motion, states, messages) feel deliberate, not default."
-      },
-      {
-        "name": "robustness",
-        "description": "No console errors, dead controls, or states the player can get stuck in."
-      }
-    ]
-  },
-  "qualityFocus": [
-    "task-native deliverable",
-    "outcomes",
-    "gated build steps",
-    "verification step"
-  ]
-}

package/data/craftbook-templates/ro/root-cause-investigation/versions/1.0.1/craftbook.json

@@ -1,126 +0,0 @@
-{
-  "id": "root-cause-investigation",
-  "name": "Root-Cause Investigation",
-  "description": "Debug systematically: reproduce the failure and find the true root cause before changing any code, then fix and verify. Enforces a no-fix-without-diagnosis discipline.",
-  "basedOn": {
-    "name": "gstack",
-    "url": "https://github.com/garrytan/gstack"
-  },
-  "plan": "## Iron Law\n\n**NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.**\n\nFixing symptoms creates whack-a-mole debugging. Every fix that doesn't address root cause makes the next bug harder to find. Find the root cause, then fix it.\n\n---\n\n## Important Rules\n\n- **3+ failed fix attempts → STOP and question the architecture.** Wrong architecture, not failed hypothesis.\n- **Never apply a fix you cannot verify.** If you can't reproduce and confirm, don't ship it.\n- **Never say \"this should fix it.\"** Verify and prove it. Run the tests.\n- **If fix touches >5 files → AskUserQuestion** about blast radius before proceeding.\n- **Completion status:**\n  - DONE — root cause found, fix applied, regression test written, all tests pass\n  - DONE_WITH_CONCERNS — fixed but cannot fully verify (e.g., intermittent bug, requires staging)\n  - BLOCKED — root cause unclear after investigation, escalated",
-  "entryStepId": "phase-1",
-  "triggers": [
-    "debug this",
-    "fix this bug",
-    "why is this broken",
-    "root cause analysis",
-    "investigate this error"
-  ],
-  "command": "root-cause-investigation",
-  "steps": [
-    {
-      "id": "phase-1",
-      "name": "Phase 1: Root Cause Investigation",
-      "prompt": "> **Iron Law:**\n> **NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST.**\n> \n> Fixing symptoms creates whack-a-mole debugging. Every fix that doesn't address root cause makes the next bug harder to find. Find the root cause, then fix it.\n> \n> ---\n\nGather context before forming any hypothesis.\n\n1. **Collect symptoms:** Read the error messages, stack traces, and reproduction steps. If the user hasn't provided enough context, ask ONE question at a time via ask_user_question.\n\n2. **Read the code:** Trace the code path from the symptom back to potential causes. Use search_code to find all references, readFile to understand the logic.\n\n3. **Check recent changes:**\n   ```bash\n   git log --oneline -20 -- <affected-files>\n   ```\n   Was this working before? What changed? A regression means the root cause is in the diff.\n\n4. **Reproduce:** Can you trigger the bug deterministically? If not, gather more evidence before proceeding.\n\n5. **Check investigation history:** Search prior learnings for investigations on the same files. Recurring bugs in the same area are an architectural smell. If prior investigations exist, note patterns and check if the root cause was structural.\n\n### Scope Lock\n\nAfter forming your root cause hypothesis, lock edits to the affected module to prevent scope creep.\n\n**If FREEZE_AVAILABLE:** Identify the narrowest directory containing the affected files. Write it to the freeze state file:\n\nSubstitute `<detected-directory>` with the actual directory path (e.g., `src/auth/`). Tell the user: \"Edits restricted to `<dir>/` for this debug session. This prevents changes to unrelated code. Run `/unfreeze` to remove the restriction.\"\n\nIf the bug spans the entire repo or the scope is genuinely unclear, skip the lock and note why.\n\n**If FREEZE_UNAVAILABLE:** Skip scope lock. Edits are unrestricted.\n\n---\n\nKeep a running record in notes/investigation.md: symptoms, the traced code path, and candidate causes.",
-      "next": "phase-2",
-      "suggestedRole": "developer",
-      "gate": {
-        "maxAttempts": 3,
-        "checks": [
-          {
-            "kind": "minBytes",
-            "file": "notes/investigation.md",
-            "bytes": 300
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-2",
-      "name": "Phase 2: Pattern Analysis",
-      "prompt": "Check if this bug matches a known pattern:\n\n| Pattern | Signature | Where to look |\n|---------|-----------|---------------|\n| Race condition | Intermittent, timing-dependent | Concurrent access to shared state |\n| Nil/null propagation | NoMethodError, TypeError | Missing guards on optional values |\n| State corruption | Inconsistent data, partial updates | Transactions, callbacks, hooks |\n| Integration failure | Timeout, unexpected response | External API calls, service boundaries |\n| Configuration drift | Works locally, fails in staging/prod | Env vars, feature flags, DB state |\n| Stale cache | Shows old data, fixes on cache clear | Redis, CDN, browser cache, Turbo |\n\nAlso check:\n- `TODOS.md` for related known issues\n- `git log` for prior fixes in the same area — **recurring bugs in the same files are an architectural smell**, not a coincidence\n\n**External pattern search:** If the bug doesn't match a known pattern above, WebSearch for:\n- \"{framework} {generic error type}\" — **sanitize first:** strip hostnames, IPs, file paths, SQL, customer data. Search the error category, not the raw message.\n- \"{library} {component} known issues\"\n\nIf WebSearch is unavailable, skip this search and proceed with hypothesis testing. If a documented solution or known dependency bug surfaces, present it as a candidate hypothesis in Phase 3.\n\n---\n\nAppend a '## Pattern' section to notes/investigation.md naming the matched pattern (or 'novel — no known pattern').",
-      "next": "phase-3",
-      "suggestedRole": "developer",
-      "gate": {
-        "maxAttempts": 3,
-        "checks": [
-          {
-            "kind": "contains",
-            "file": "notes/investigation.md",
-            "pattern": "##\\s*Pattern",
-            "flags": "i"
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-3",
-      "name": "Phase 3: Hypothesis Testing",
-      "prompt": "Before writing ANY fix, verify your hypothesis.\n\n1. **Confirm the hypothesis:** Add a temporary log statement, assertion, or debug output at the suspected root cause. Run the reproduction. Does the evidence match?\n\n2. **If the hypothesis is wrong:** Before forming the next hypothesis, consider searching for the error. **Sanitize first** — strip hostnames, IPs, file paths, SQL fragments, customer identifiers, and any internal/proprietary data from the error message. Search only the generic error type and framework context: \"{component} {sanitized error type} {framework version}\". If the error message is too specific to sanitize safely, skip the search. If WebSearch is unavailable, skip and proceed. Then return to Phase 1. Gather more evidence. Do not guess.\n\n3. **3-strike rule:** If 3 hypotheses fail, **STOP**. Use ask_user_question:\n   ```\n   3 hypotheses tested, none match. This may be an architectural issue\n   rather than a simple bug.\n\n   A) Continue investigating — I have a new hypothesis: [describe]\n   B) Escalate for human review — this needs someone who knows the system\n   C) Add logging and wait — instrument the area and catch it next time\n   ```\n\n**Red flags** — if you see any of these, slow down:\n- \"Quick fix for now\" — there is no \"for now.\" Fix it right or escalate.\n- Proposing a fix before tracing data flow — you're guessing.\n- Each fix reveals a new problem elsewhere — wrong layer, not wrong code.\n\n---\n\nAppend a '## Hypothesis' section to notes/investigation.md: the confirmed root cause plus the one line of evidence that confirmed it.",
-      "next": "phase-4",
-      "suggestedRole": "developer",
-      "gate": {
-        "maxAttempts": 4,
-        "checks": [
-          {
-            "kind": "contains",
-            "file": "notes/investigation.md",
-            "pattern": "##\\s*Hypothesis",
-            "flags": "i"
-          }
-        ]
-      }
-    },
-    {
-      "id": "phase-4",
-      "name": "Phase 4: Implementation",
-      "prompt": "Once root cause is confirmed:\n\n1. **Fix the root cause, not the symptom.** The smallest change that eliminates the actual problem.\n\n2. **Minimal diff:** Fewest files touched, fewest lines changed. Resist the urge to refactor adjacent code.\n\n3. **Write a regression test** that:\n   - **Fails** without the fix (proves the test is meaningful)\n   - **Passes** with the fix (proves the fix works)\n\n4. **Run the full test suite.** Paste the output. No regressions allowed.\n\n5. **If the fix touches >5 files:** Use ask_user_question to flag the blast radius:\n   ```\n   This fix touches N files. That's a large blast radius for a bug fix.\n   A) Proceed — the root cause genuinely spans these files\n   B) Split — fix the critical path now, defer the rest\n   C) Rethink — maybe there's a more targeted approach\n   ```\n\n---",
-      "next": "phase-5",
-      "suggestedRole": "developer"
-    },
-    {
-      "id": "phase-5",
-      "name": "Phase 5: Verification & Report",
-      "prompt": "**Fresh verification:** Reproduce the original bug scenario and confirm it's fixed. This is not optional.\n\nRun the test suite and paste the output.\n\nOutput a structured debug report:\n```\nDEBUG REPORT\n════════════════════════════════════════\nSymptom:         [what the user observed]\nRoot cause:      [what was actually wrong]\nFix:             [what was changed, with file:line references]\nEvidence:        [test output, reproduction attempt showing fix works]\nRegression test: [file:line of the new test]\nRelated:         [TODOS.md items, prior bugs in same area, architectural notes]\nStatus:          DONE | DONE_WITH_CONCERNS | BLOCKED\n════════════════════════════════════════\n```\n\nLog the investigation as a learning for future sessions. Use `type: \"investigation\"` and include the affected files so future investigations on the same area can find this:\n\n### Important Rules\n\n- **3+ failed fix attempts → STOP and question the architecture.** Wrong architecture, not failed hypothesis.\n- **Never apply a fix you cannot verify.** If you can't reproduce and confirm, don't ship it.\n- **Never say \"this should fix it.\"** Verify and prove it. Run the tests.\n- **If fix touches >5 files → ask_user_question** about blast radius before proceeding.\n- **Completion status:**\n  - DONE — root cause found, fix applied, regression test written, all tests pass\n  - DONE_WITH_CONCERNS — fixed but cannot fully verify (e.g., intermittent bug, requires staging)\n  - BLOCKED — root cause unclear after investigation, escalated\n\nWrite the structured debug report to debug-report.md using the block above.",
-      "suggestedRole": "reviewer",
-      "gate": {
-        "maxAttempts": 4,
-        "checks": [
-          {
-            "kind": "minBytes",
-            "file": "debug-report.md",
-            "bytes": 400
-          },
-          {
-            "kind": "contains",
-            "file": "debug-report.md",
-            "pattern": "Root cause",
-            "flags": "i"
-          },
-          {
-            "kind": "contains",
-            "file": "debug-report.md",
-            "pattern": "Regression test",
-            "flags": "i"
-          }
-        ]
-      },
-      "next": "evaluate"
-    },
-    {
-      "id": "evaluate",
-      "name": "Evaluate",
-      "suggestedRole": "reviewer",
-      "next": "phase-4",
-      "prompt": "Re-read debug-report.md against the fresh verification: does the evidence actually show the original symptom is gone, and does the regression test fail without the fix? If a gap remains, loop back to Phase 4 and close it. If everything holds, advance to Finish. Routing: ALL criteria pass → advance to finish; ANY criterion fails → loop back to phase-4 with a note naming the exact gap."
-    },
-    {
-      "id": "finish",
-      "name": "Finish",
-      "suggestedRole": "developer",
-      "prompt": "Summarize the root cause, the fix, and where the debug report lives. Hand the thread back to the user. Write a one-paragraph DONE summary to task notes via `write_task_note`, then report DONE.",
-      "terminal": true
-    }
-  ],
-  "version": "1.0.1",
-  "releasedAt": "2026-07-25T22:45:00.000Z"
-}

package/data/craftbook-templates/te/technical-documentation/versions/1.0.1/craftbook.json

@@ -1,152 +0,0 @@
-{
-  "id": "technical-documentation",
-  "name": "Technical Documentation",
-  "description": "Generate a coherent documentation set from a codebase, organized by the Diataxis model (tutorials, how-to guides, reference, explanation), with cross-links and a coverage pass.",
-  "basedOn": {
-    "name": "gstack",
-    "url": "https://github.com/garrytan/gstack"
-  },
-  "plan": "## Important Rules\n\n- **Research before writing.** Step 1 is not optional. Read the code, read the tests, read the\n  existing docs. Insufficient research produces surface-level documentation.\n- **Accuracy is non-negotiable.** Every code example must work. Every API description must match\n  the actual code. If you're unsure about a detail, read the source again — do not guess.\n- **Diataxis quadrants serve different readers.** Do not mix tutorial content into reference docs\n  or reference content into how-tos. Each quadrant has a specific reader in a specific mode.\n- **Time to first result in tutorials.** If a reader can't see something working by step 3,\n  restructure the tutorial.\n- **Cross-link everything.** Isolated docs are undiscoverable docs.\n- **Voice: friendly, concrete, user-forward.** Write like you're explaining to a smart person\n  who hasn't seen the code. Never corporate, never academic.\n- **Completeness over minimalism.** AI makes comprehensive documentation cheap. Don't write\n  \"minimal viable docs\" — write complete docs. Boil the ocean.",
-  "entryStepId": "step-0",
-  "triggers": [
-    "write docs for this",
-    "generate documentation",
-    "document this feature",
-    "create a tutorial",
-    "write a how-to",
-    "explain this module",
-    "docs for this project"
-  ],
-  "command": "technical-documentation",
-  "steps": [
-    {
-      "id": "step-0",
-      "name": "Step 0: Scope & Intent",
-      "prompt": "1. Determine what to document:\n   - **If invoked with a specific target** (feature, module, file, skill): scope is that target\n   - **If invoked for an entire project**: scope is the full project\n   - **If called from /document-release with gaps**: scope is the specific entities from the coverage map\n\n2. Use AskUserQuestion to confirm scope and ask about documentation target:\n\n   - A) Write documentation inline in existing files (README, ARCHITECTURE, etc.)\n   - B) Create standalone documentation files (e.g., `docs/` directory)\n   - C) Both — inline summaries in existing files + deep docs in standalone files\n\n   RECOMMENDATION: Choose C because it maximizes both discoverability and depth.\n\n3. Determine the output format:\n   - If the project already has a `docs/` directory, follow its conventions\n   - If the project uses a doc framework (Nextra, Docusaurus, MkDocs, VitePress), follow its format\n   - Otherwise, use plain Markdown files in `docs/`\n\n---\n\nRecord the scope decision in docs/plan.md: what is being documented, for whom, and which Diataxis quadrants each target gets.",
-      "next": "step-1",
-      "suggestedRole": "planner",
-      "gate": {
-        "maxAttempts": 3,
-        "checks": [
-          {
-            "kind": "minBytes",
-            "file": "docs/plan.md",
-            "bytes": 150
-          }
-        ]
-      }
-    },
-    {
-      "id": "step-1",
-      "name": "Step 1: Codebase Archaeology (Research Phase)",
-      "prompt": "**This is the most important step.** Do not skip or rush it. The quality of your documentation\nis directly proportional to how well you understand the code.\n\n1. **Map the project structure:**\n\n2. **Read the entry points.** Identify and read:\n   - README.md, ARCHITECTURE.md, CONTRIBUTING.md, CLAUDE.md / AGENTS.md\n   - package.json / Cargo.toml / pyproject.toml / go.mod (understand the project type)\n   - Main entry files (index.ts, main.rs, app.py, cmd/main.go)\n   - Configuration files and examples\n\n3. **Read the source code for each target entity.** For each feature/module you're documenting:\n   - Read the implementation files end-to-end (not just signatures)\n   - Read the tests — they reveal intended behavior, edge cases, and usage patterns\n   - Read related modules that the target depends on or is depended upon by\n   - Read any existing inline comments, especially `// NOTE:`, `// DESIGN:`, `// WHY:`\n\n4. **Build a concept map.** Before writing, produce an internal outline:\n\n```\nTarget: [feature/module name]\nPurpose: [one sentence — what problem does it solve?]\nKey concepts: [list the 3-5 concepts a reader must understand]\nPublic surface: [commands, functions, config options, API endpoints]\nDependencies: [what it needs from other modules]\nDependents: [what relies on it]\nEdge cases: [from reading tests and code]\nDesign decisions: [any non-obvious \"why\" choices]\n```\n\n5. Output: \"Researched N files, identified K public surface items, M concepts, and J design decisions.\"\n\n---\n\nCapture the map under an '## Architecture notes' section in docs/plan.md — entry points, core modules, and the flows the docs must explain.",
-      "next": "step-2",
-      "suggestedRole": "developer",
-      "gate": {
-        "maxAttempts": 3,
-        "checks": [
-          {
-            "kind": "contains",
-            "file": "docs/plan.md",
-            "pattern": "##\\s*Architecture",
-            "flags": "i"
-          }
-        ]
-      }
-    },
-    {
-      "id": "step-2",
-      "name": "Step 2: Diataxis Partitioning",
-      "prompt": "For each target entity, decide which Diataxis quadrants to produce. Not every entity needs all four.\n\n**Decision matrix:**\n\n| Entity type | Tutorial? | How-to? | Reference? | Explanation? |\n|---|---|---|---|---|\n| New feature a user interacts with | ✅ | ✅ | ✅ | Maybe |\n| CLI command or flag | Maybe | ✅ | ✅ | No |\n| Internal module/architecture | No | No | ✅ | ✅ |\n| Config option | No | ✅ | ✅ | No |\n| Design pattern / philosophy | No | No | No | ✅ |\n| API endpoint | Maybe | ✅ | ✅ | No |\n| Workflow (multi-step process) | ✅ | ✅ | No | Maybe |\n\nOutput the partition plan:\n\n```\nDocumentation plan:\n  [entity]              [tutorial] [how-to] [reference] [explanation]\n  Widget system         ✅ new     ✅ new   ✅ new      ✅ new\n  --verbose flag        ❌        ✅ new   ✅ inline   ❌\n  Bayesian scheduler    ❌        ❌       ✅ new      ✅ new\n```\n\nIf the plan has more than 5 documents to create, use AskUserQuestion to confirm before proceeding.\nFor smaller scopes, proceed directly.\n\n---\n\nAdd the decision matrix as a '## Diataxis plan' table in docs/plan.md.",
-      "next": "step-3",
-      "suggestedRole": "planner",
-      "gate": {
-        "maxAttempts": 3,
-        "checks": [
-          {
-            "kind": "contains",
-            "file": "docs/plan.md",
-            "pattern": "##\\s*Diataxis",
-            "flags": "i"
-          }
-        ]
-      }
-    },
-    {
-      "id": "step-3",
-      "name": "Step 3: Write Reference Documentation First",
-      "prompt": "Reference docs are the foundation. They are factual, complete, and derived directly from code.\nWrite these before tutorials or how-tos because they establish the vocabulary.\n\n**Reference doc template:**\n\n```markdown\n# [Entity Name]\n\n[One paragraph: what it is, what it does, when you'd use it.]\n\n## API / Interface\n\n[Complete listing of public surface: functions, commands, config options, parameters.\nInclude types, defaults, and constraints. Pull directly from code — do not paraphrase\nloosely.]\n\n## Options / Configuration\n\n[If applicable: every option with its type, default, and effect.]\n\n## Examples\n\n[2-3 concrete examples showing actual usage. Prefer real command output or code that\nwould actually compile/run.]\n\n## Related\n\n[Links to other reference docs, how-tos, or explanations that provide context.]\n```\n\n**Rules for reference docs:**\n- Accuracy over elegance. Every claim must be traceable to code.\n- Include types, defaults, and constraints. \"Accepts a string\" is insufficient — \"Accepts a\n  string (max 256 chars, must match `^[a-z-]+$`)\" is reference-grade.\n- Show real examples that would actually work if copy-pasted.\n- Do not explain *why* — that belongs in explanation docs.\n\n---\n\nWrite each reference document under docs/reference/.",
-      "next": "step-4",
-      "suggestedRole": "copywriter",
-      "gate": {
-        "maxAttempts": 4,
-        "checks": [
-          {
-            "kind": "fileCount",
-            "ext": [
-              "md"
-            ],
-            "min": 1,
-            "dir": "docs/reference"
-          }
-        ]
-      }
-    },
-    {
-      "id": "step-4",
-      "name": "Step 4: Write Explanation Documentation",
-      "prompt": "Explanation docs answer \"why does this work this way?\" They are the design rationale.\n\n**Explanation doc template:**\n\n```markdown\n# [Concept / Design Decision]\n\n[Opening paragraph: the problem this design solves, stated in terms a smart reader\nwho hasn't seen the code would understand.]\n\n## The problem\n\n[Concrete description of what goes wrong without this design. Real failure modes,\nnot abstract risks.]\n\n## The approach\n\n[How the design solves the problem. Include diagrams (ASCII or Mermaid) for\narchitectural concepts.]\n\n## Trade-offs\n\n[What was given up. Every design decision trades something — name it explicitly.]\n\n## Alternatives considered\n\n[If discoverable from code comments, ADRs, or git history: what was tried or\nrejected and why.]\n```\n\n**Rules for explanation docs:**\n- Lead with the problem, not the solution.\n- Use ASCII diagrams for architecture. They're grep-able, diff-friendly, and render everywhere.\n- Name trade-offs explicitly. \"We chose X over Y because Z\" is the gold standard.\n- Do not repeat reference material — link to it.\n\n---\n\nWrite each explanation document under docs/explanation/.",
-      "next": "step-5",
-      "suggestedRole": "copywriter",
-      "gate": {
-        "maxAttempts": 4,
-        "checks": [
-          {
-            "kind": "fileCount",
-            "ext": [
-              "md"
-            ],
-            "min": 1,
-            "dir": "docs/explanation"
-          }
-        ]
-      }
-    },
-    {
-      "id": "step-5",
-      "name": "Step 5: Write How-To Guides",
-      "prompt": "How-tos are task-oriented. They assume the reader knows the basics and wants to accomplish\nsomething specific.\n\n**How-to doc template:**\n\n```markdown\n# How to [accomplish specific task]\n\n[One sentence: what you'll accomplish and the end result.]\n\n## Prerequisites\n\n[What the reader needs before starting. Be specific — versions, installed tools,\nconfig state.]\n\n## Steps\n\n1. [Action verb] [specific instruction]\n\n   ```bash\n   [exact command]\n   ```\n\n   [Expected output or result, if non-obvious.]\n\n2. [Next step...]\n\n### Verification\n\n[How to confirm it worked. A command, a URL to visit, a test to run.]\n\n### Troubleshooting\n\n[Common failure modes and their fixes. Pull from tests and error handling code.]\n```\n\n**Rules for how-to docs:**\n- Title starts with \"How to\" — no exceptions. This is the reader's entry point.\n- Every step must be actionable. No \"consider whether...\" — instead \"Run X\" or \"Add Y to Z\".\n- Include verification. The reader should never wonder \"did it work?\"\n- Troubleshooting section is mandatory if the task can fail.\n\n---\n\n## Step 6: Write Tutorials\n\nTutorials are learning-oriented. They take a newcomer from zero to a working example.\nThese are the hardest to write well and the most valuable.\n\n**Tutorial doc template:**\n\n```markdown\n# [Tutorial title — describes what you'll build/learn]\n\n[Opening paragraph: what you'll build, why it's useful, and what you'll understand\nby the end. Keep it concrete — \"You'll build a working X that does Y\" not\n\"This tutorial covers X\".]\n\n## What you'll need\n\n[Prerequisites: tools, versions, prior knowledge. Link to installation guides.]\n\n## Step 1: [Set up the foundation]\n\n[Start from a clean state. Show every command. Explain what each does on first\nencounter — but briefly, not a lecture.]\n\n```bash\n[exact command]\n```\n\n[Brief explanation of what just happened.]\n\nWrite each how-to guide under docs/how-to/.",
-      "next": "evaluate",
-      "suggestedRole": "copywriter",
-      "gate": {
-        "maxAttempts": 4,
-        "checks": [
-          {
-            "kind": "fileCount",
-            "ext": [
-              "md"
-            ],
-            "min": 1,
-            "dir": "docs/how-to"
-          }
-        ]
-      }
-    },
-    {
-      "id": "evaluate",
-      "name": "Evaluate",
-      "suggestedRole": "reviewer",
-      "next": "step-3",
-      "prompt": "Read docs/plan.md and spot-check each produced document against the code it describes: are the reference pages factual, do the how-tos actually work, is anything in the Diataxis plan still missing? If a quadrant is missing or wrong, loop back to Step 3 and fill it. Otherwise advance to Finish. Routing: ALL criteria pass → advance to finish; ANY criterion fails → loop back to step-3 with a note naming the exact gap."
-    },
-    {
-      "id": "finish",
-      "name": "Finish",
-      "suggestedRole": "developer",
-      "prompt": "Summarize what was documented and where it lives (the docs/ tree), and hand back to the user. Write a one-paragraph DONE summary to task notes via `write_task_note`, then report DONE.",
-      "terminal": true
-    }
-  ],
-  "version": "1.0.1",
-  "releasedAt": "2026-07-25T22:45:00.000Z"
-}