draht-claude 2026.4.23

package/commands/init-project.md

@@ -0,0 +1,65 @@
+---
+description: Initialize GSD planning for an existing project (codebase mapping → questioning → domain model → roadmap)
+argument-hint: "[focus area]"
+allowed-tools: Bash, Read, Write, Edit, Task
+---
+
+# /init-project
+
+Initialize planning framework for an existing project: codebase mapping → questioning → domain model → requirements → roadmap.
+
+Focus: $ARGUMENTS
+
+Use this when you have an existing codebase and want to add structured planning. For greenfield projects, use `/new-project` instead.
+
+> **Tool note**: Invoke `draht-tools <subcommand>` as `node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" <subcommand>` via the Bash tool.
+
+## Atomic Reasoning
+
+Before initializing, decompose project understanding into atomic reasoning units:
+
+**For each aspect of the existing project:**
+1. **State the logical component** — What does this project do? Who are the users? What problems does it solve?
+2. **Validate independence** — What bounded contexts exist in the code? What domain concepts are already present? Can they be separated cleanly?
+3. **Verify correctness** — What works well that we must preserve? What pain points exist? What constraints limit changes?
+
+**Synthesize initialization strategy:**
+- Map existing architecture and conventions
+- Extract domain model from code (bounded contexts, aggregates, ubiquitous language)
+- Identify test strategy and coverage
+- Define requirements that align with existing structure
+- Create roadmap that respects what already works
+
+## Steps
+1. Run `draht-tools init` to check preconditions (git repo, etc.)
+2. Run `draht-tools map-codebase` to build a structural map of the existing code
+3. Analyze the codebase map to understand architecture, tech stack, and conventions
+4. Deep questioning phase (3-7 rounds, 1-2 questions at a time):
+   - What is this project? Who uses it?
+   - What are the current pain points or goals?
+   - What is MVP vs aspirational scope?
+   - What constraints exist (infra, team size, deadlines)?
+5. Run `draht-tools create-project` with gathered info
+6. Run `draht-tools create-domain-model` to define bounded contexts, entities, and ubiquitous language
+7. Create `.planning/DOMAIN.md` with the same sections as `/new-project`:
+   Bounded Contexts, Ubiquitous Language, Context Map, Aggregates, Domain Events
+8. Create `.planning/TEST-STRATEGY.md` with: Test Framework, Directory Conventions, Coverage Goals, Testing Levels, Excluded
+9. Optional research phase via `draht-tools research`
+10. Run `draht-tools create-requirements` with v1/v2/out-of-scope (map requirements to bounded contexts)
+11. Run `draht-tools create-roadmap` with phases
+12. Run `draht-tools init-state`
+13. Git commit via `draht-tools commit-docs "initialize project planning"`
+
+## Workflow
+After project initialization, phases are executed one at a time in fresh sessions:
+
+```
+/init-project → /discuss-phase 1 → /plan-phase 1 → /execute-phase 1 → /verify-work 1
+              → ... (repeat for all phases in the milestone)
+              → /next-milestone (only after ALL phases are complete)
+```
+
+## Rules
+- Ask 1-2 questions at a time, never dump 10 at once
+- Respect what already exists — do not propose rewriting working code
+- Stop when you have: current state, goals, MVP scope, constraints, success criteria

package/commands/map-codebase.md

@@ -0,0 +1,52 @@
+---
+description: Analyze existing codebase before planning — extract architecture, domain model, and test strategy
+argument-hint: "[directory]"
+allowed-tools: Bash, Read, Write, Edit, Task, Grep, Glob
+---
+
+# /map-codebase
+
+Analyze existing codebase before planning, using subagents for parallel analysis.
+
+Directory: $1
+
+> **Tool note**: Invoke `draht-tools <subcommand>` as `node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" <subcommand>`. For subagents, use the **Task tool** with `subagent_type` matching the agent name (e.g. `architect`, `verifier`).
+
+## Atomic Reasoning
+
+Before analyzing, decompose codebase understanding into atomic reasoning units:
+
+**For each architectural layer:**
+1. **State the logical component** — What is this directory/module's responsibility? What concepts does it encapsulate?
+2. **Validate independence** — Is this a bounded context? What are its dependencies? Does it leak abstractions across boundaries?
+3. **Verify correctness** — What domain terms appear in code? What aggregates exist? What test infrastructure is present?
+
+**Synthesize analysis strategy:**
+- Map directory structure to bounded contexts
+- Extract domain language from identifiers (classes, functions, types)
+- Identify context relationships (upstream/downstream, shared kernel)
+- Document test strategy and coverage
+- Note architectural concerns and patterns
+
+## Steps
+1. Run `draht-tools map-codebase $1`
+2. Tool generates: STACK.md, ARCHITECTURE.md, CONVENTIONS.md, CONCERNS.md
+
+3. **Run parallel deep analysis via the Task tool**:
+   Dispatch these two subagents in parallel (single assistant turn, two Task tool calls):
+
+   - **Task tool** with `subagent_type: "architect"` and prompt:
+     "Analyze the codebase at $1. Identify bounded contexts from directory structure — look for top-level src/ subdirectories, packages, or modules that encapsulate coherent domain concepts. Note any cross-directory coupling suggesting blurred context boundaries. Extract domain language: collect PascalCase class/interface/type names, key function names, database table/collection names. Look for repeated nouns representing core domain concepts. Output a structured list of: bounded contexts (name + description), domain terms (glossary), aggregates per context, and context relationships (upstream/downstream, shared kernel, ACL)."
+
+   - **Task tool** with `subagent_type: "verifier"` and prompt:
+     "Analyze the test infrastructure at $1. Discover: test framework(s) in use (check package.json, config files), test directory conventions (co-located, __tests__/, test/), existing coverage configuration and goals, which layers have tests (unit, integration, e2e), gaps and recommendations. Output a structured test strategy report."
+
+4. Collect subagent results and merge with the draht-tools output
+5. Create `.planning/DOMAIN.md` (if it doesn't exist) with:
+   - `## Bounded Contexts` — one entry per discovered context with a brief description
+   - `## Ubiquitous Language` — glossary of extracted domain terms
+   - `## Context Map` — how bounded contexts relate (upstream/downstream, shared kernel, ACL)
+   - `## Aggregates` — aggregates and their root entities per context
+   - `## Domain Events` — any existing event names or patterns discovered
+6. Create `.planning/TEST-STRATEGY.md` with: Test Framework, Directory Conventions, Coverage Goals, Testing Levels, Excluded
+7. Commit: `draht-tools commit-docs "map existing codebase"`

package/commands/new-project.md

@@ -0,0 +1,73 @@
+---
+description: Initialize a new project with structured GSD planning (questioning → domain model → requirements → roadmap)
+argument-hint: "[description]"
+allowed-tools: Bash, Read, Write, Edit, Task
+---
+
+# /new-project
+
+Initialize a new project: questioning → research → requirements → roadmap.
+
+Description: $ARGUMENTS
+
+> **Tool note**: When this command says `draht-tools <subcommand>`, invoke it as `node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" <subcommand>` via the Bash tool. `CLAUDE_PLUGIN_ROOT` is set by Claude Code to the plugin's install directory.
+
+## Atomic Reasoning
+
+Before questioning, decompose project vision into atomic reasoning units:
+
+**For each aspect of the new project:**
+1. **State the logical component** — What problem does this solve? Who are the users? What is core vs peripheral?
+2. **Validate independence** — What bounded contexts will exist? What domain concepts are central? Can features be built independently?
+3. **Verify correctness** — What defines MVP success? What constraints exist (time, tech, team)? What is explicitly out of scope?
+
+**Synthesize project strategy:**
+- Define bounded contexts and ubiquitous language upfront
+- Establish test strategy before writing code
+- Create requirements mapped to domain contexts
+- Build roadmap with testable phase goals
+- Ensure each phase delivers verifiable user value
+
+## Steps
+1. Run `draht-tools init` to check preconditions
+2. If existing code detected, run `draht-tools map-codebase` first
+3. Deep questioning phase (3-7 rounds, 1-2 questions at a time)
+4. Run `draht-tools create-project` with gathered info
+5. Run `draht-tools create-domain-model` to define bounded contexts, entities, and ubiquitous language
+6. Create `.planning/DOMAIN.md` with:
+   - `## Bounded Contexts` — each context with name, responsibility, and brief description
+   - `## Ubiquitous Language` — glossary of domain terms agreed with the user (term → definition)
+   - `## Context Map` — how bounded contexts relate to each other (upstream/downstream, shared kernel, ACL)
+   - `## Aggregates` — aggregates and their root entities per context
+   - `## Domain Events` — named events that cross context boundaries
+7. Create `.planning/TEST-STRATEGY.md` with:
+   - `## Test Framework` — chosen framework and rationale
+   - `## Directory Conventions` — where test files live relative to source
+   - `## Coverage Goals` — target coverage percentage and which paths are critical
+   - `## Testing Levels` — what is tested at unit level vs integration vs e2e, with examples
+   - `## Excluded` — what is explicitly not tested and why (config files, generated code, etc.)
+8. Optional research phase via `draht-tools research`
+9. Run `draht-tools create-requirements` with v1/v2/out-of-scope (map requirements to bounded contexts)
+10. Run `draht-tools create-roadmap` with phases
+11. Run `draht-tools init-state`
+12. Git commit via `draht-tools commit-docs "initialize project planning"`
+
+## Workflow
+After project initialization, phases are executed one at a time in fresh sessions:
+
+```
+/new-project → /discuss-phase 1 → /plan-phase 1 → /execute-phase 1 → /verify-work 1
+             → /discuss-phase 2 → /plan-phase 2 → /execute-phase 2 → /verify-work 2
+             → ... (repeat for all phases in the milestone)
+             → /next-milestone (only after ALL phases are complete)
+```
+
+Start a fresh session (`/clear`) between steps. Do NOT suggest `/next-milestone` until every phase in the milestone is verified.
+
+## Rules
+- Ask 1-2 questions at a time, never dump 10 at once
+- Follow threads based on answers
+- Use examples ("Like Stripe Checkout, or custom?")
+- Confirm, don't assume
+- 3-7 follow-up rounds typical
+- Stop when you have: problem, audience, MVP scope, constraints, success criteria

package/commands/next-milestone.md

@@ -0,0 +1,49 @@
+---
+description: Plan the next milestone after ALL phases in the current one are complete
+allowed-tools: Bash, Read, Write, Edit
+---
+
+# /next-milestone
+
+Plan the next milestone after ALL phases in the current one are complete.
+
+> **Tool note**: Invoke `draht-tools <subcommand>` as `node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" <subcommand>` via the Bash tool.
+
+## Atomic Reasoning
+
+Before planning the next milestone, decompose progress into atomic reasoning units:
+
+**For each completed phase:**
+1. **State the logical component** — What was built? What user value was delivered? What requirements were satisfied?
+2. **Validate independence** — What worked well? What had issues? What assumptions proved wrong?
+3. **Verify correctness** — Is every phase truly complete? Are there lingering fix plans? Is the codebase healthy?
+
+**Synthesize milestone strategy:**
+- Identify gaps from the current milestone
+- Derive new requirements from lessons learned
+- Group into a coherent next milestone with testable phase goals
+- Ensure domain model and test strategy still reflect reality
+
+## Steps
+1. Run `draht-tools verify-milestone` to ensure every phase in the current milestone is `complete`
+2. If any phase is not complete, STOP and tell the user which phase needs attention
+3. Read all phase reports in `.planning/phase-N-report.md` to extract lessons learned
+4. Read the execution log `.planning/execution-log.jsonl` for failure patterns
+5. Review `.planning/DOMAIN.md` — is it still accurate? Any terms to add/revise?
+6. Review `.planning/TEST-STRATEGY.md` — any updates needed?
+7. Questioning phase (1-2 questions at a time):
+   - What is the next milestone's goal?
+   - What user-visible outcomes must be true by the end?
+   - What is in vs out of scope?
+8. Propose phases for the next milestone. Each phase must have:
+   - A clear goal (outcome, not activity)
+   - Mapped requirements
+   - Acceptance criteria
+9. Update `.planning/ROADMAP.md` with the new milestone header and phases (status: `pending`)
+10. Update `.planning/REQUIREMENTS.md` with any new requirements
+11. Commit: `draht-tools commit-docs "plan milestone <N>"`
+
+## Rules
+- Do not start planning phase details — that happens in `/discuss-phase` + `/plan-phase`
+- Respect lessons learned from the previous milestone — don't repeat mistakes
+- Keep the next milestone focused — 3-6 phases is typical

package/commands/orchestrate.md

@@ -0,0 +1,58 @@
+---
+description: Decompose a task and orchestrate multiple specialist subagents in parallel and chain modes
+argument-hint: "<task description>"
+allowed-tools: Bash, Read, Write, Edit, Task
+---
+
+# /orchestrate
+
+Decompose a task and dispatch the right mix of specialist subagents.
+
+Task: $ARGUMENTS
+
+> **Tool note**: Use the **Task tool** with `subagent_type` set to one of: `architect`, `implementer`, `reviewer`, `debugger`, `verifier`, `git-committer`, `security-auditor`. Dispatch multiple tasks in the same assistant turn for parallel execution.
+
+## Atomic Reasoning
+
+Before delegating, decompose the task into atomic work units:
+
+1. **State the logical components** — What sub-tasks make up this work? Which are independent?
+2. **Match agents to work** — Which specialist is right for each sub-task?
+3. **Determine order** — What can run in parallel vs what must be sequential?
+4. **Define success** — What does "done" look like for each sub-task, and for the whole?
+
+## Agent Selection Guide
+
+| Need | Agent |
+|---|---|
+| Plan structure before coding | `architect` |
+| Write or change code | `implementer` |
+| Find what's broken | `debugger` |
+| Review for correctness / conventions / domain | `reviewer` |
+| Audit for security issues | `security-auditor` |
+| Run lint / typecheck / tests | `verifier` |
+| Create atomic commits | `git-committer` |
+
+## Orchestration Modes
+
+### Parallel
+Dispatch several Task tool calls in a single assistant turn when the sub-tasks don't depend on each other. Example: review + security audit of the same change set.
+
+### Chain
+Dispatch Task tool calls sequentially when later work depends on earlier output. Example: architect produces plan → implementer executes plan → verifier runs tests → reviewer audits the diff.
+
+### Fan-out / Fan-in
+Architect decomposes into N independent plans → dispatch N implementers in parallel → collect all outputs → single verifier run → single reviewer audit. This is the standard pattern for `/execute-phase` work.
+
+## Steps
+1. Read the task description and identify sub-tasks
+2. Map each sub-task to the right agent from the table above
+3. Decide parallel vs chain vs fan-out based on dependencies
+4. Dispatch Task tool calls accordingly
+5. Collect results, handle failures, report the final outcome to the user
+
+## Rules
+- Prefer parallel dispatch when possible — it's faster and each subagent has its own context
+- Pass complete context to subagents — they cannot see the main conversation
+- Do not nest delegations deeply — one level is usually enough
+- If a subagent fails, report the failure and suggest next steps rather than retrying blindly

package/commands/pause-work.md

@@ -0,0 +1,38 @@
+---
+description: Create a CONTINUE-HERE handoff document for session continuity
+allowed-tools: Bash, Read, Write, Edit
+---
+
+# /pause-work
+
+Create a handoff document for session continuity.
+
+> **Tool note**: Invoke `draht-tools <subcommand>` as `node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" <subcommand>` via the Bash tool.
+
+## Atomic Reasoning
+
+Before pausing, decompose session state into atomic reasoning units:
+
+1. **State the logical component** — What was accomplished this session? What is in-progress? What is the current phase/task?
+2. **Validate independence** — Are there uncommitted changes? Are there blockers? What decisions were made?
+3. **Verify correctness** — Is the current state stable? Can work resume cleanly? What context needs to be captured?
+
+## Steps
+1. Run `git status` and `git diff --stat` to see uncommitted changes
+2. Read `.planning/STATE.md` for current phase/status
+3. Write `.planning/CONTINUE-HERE.md` with:
+   - `## Current Phase` — which phase and plan is active
+   - `## Last Completed` — last task or milestone that finished cleanly
+   - `## In Progress` — what is partially done (be specific: file paths, failing tests)
+   - `## Uncommitted Changes` — list of modified files and why
+   - `## Decisions Made This Session` — any design decisions or context
+   - `## Next Steps` — exact commands to run when resuming
+   - `## Blockers` — anything waiting on external input or clarification
+4. Update `.planning/STATE.md` last activity timestamp via `draht-tools update-state`
+5. Commit: `draht-tools commit-docs "pause work — handoff"`
+6. Tell the user: "Resume with `/resume-work` in a fresh session."
+
+## Rules
+- Be specific — "fix bug in auth" is useless; "null check in src/auth/session.ts:42, test reproducing in test/auth-null.test.ts" is useful
+- Include exact commands, not vague directions
+- Capture any in-flight decisions or trade-offs being weighed

package/commands/plan-phase.md

@@ -0,0 +1,107 @@
+---
+description: Create atomic execution plans for a roadmap phase (parallel via architect subagents)
+argument-hint: "<phase-number>"
+allowed-tools: Bash, Read, Write, Edit, Task
+---
+
+# /plan-phase
+
+Create atomic execution plans for a roadmap phase, using subagents for parallel plan creation.
+
+Phase: $1
+
+> **Tool note**: Invoke `draht-tools <subcommand>` as `node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" <subcommand>`. For subagents, use the **Task tool** with `subagent_type: "architect"`. Dispatch multiple parallel tasks in a single assistant turn by making multiple Task tool calls at once.
+
+## Atomic Reasoning
+
+Before creating plans, decompose this phase goal into atomic reasoning units:
+
+**For each observable truth (user-visible outcome):**
+1. **State the logical component** — What must be true for the user? What can they do/see/verify?
+2. **Validate independence** — Which artifacts (files, endpoints, schemas) prove this truth exists? Can it be built independently?
+3. **Verify correctness** — What test scenarios would prove this observable truth? What are the specific inputs → expected outputs?
+
+**Synthesize planning strategy:**
+- Group related observable truths into cohesive plans (2-5 tasks each)
+- Identify which plans can be created in parallel vs sequentially
+- Map each plan to specific bounded contexts and domain concepts
+- Ensure each plan produces testable, verifiable outcomes
+
+## Steps
+1. Run `draht-tools load-phase-context $1` to gather all context
+2. Optional: `draht-tools research-phase $1` for domain research
+3. Goal-backward planning:
+   a. State the goal (outcome, not activity)
+   b. Derive observable truths (3-7 from user perspective)
+   c. From each observable truth, derive the test scenarios that would prove it (specific inputs → expected outputs or state changes)
+   d. Map to required artifacts (files, endpoints, schemas)
+   e. Break into plan groups of 2-5 tasks each
+4. Identify which plans are independent (no shared files, no dependency edges)
+
+5. **Delegate plan creation to subagents via the Task tool:**
+   - For **independent plans**: dispatch multiple `Task` tool calls in parallel (single assistant turn), each with `subagent_type: "architect"`, one per plan.
+   - For **dependent plans**: dispatch sequentially — one `Task` call per plan, feeding predecessor outputs as context into the next.
+   - Each architect prompt must include:
+     - The phase context summary (paste it inline — subagents cannot run draht-tools)
+     - The specific observable truths this plan must satisfy
+     - The target files/artifacts
+     - The XML task format specification (below)
+     - Instruction to output the plan as XML text, which the main assistant will save via `draht-tools create-plan`
+
+6. Collect all plan outputs from subagents
+7. Save each plan by piping the subagent's output into `draht-tools create-plan`:
+   ```bash
+   echo 'plan content from subagent' | node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" create-plan $1 P [title]
+   ```
+   The content must contain real task details (files, actions, tests) — NOT placeholder brackets. If `create-plan` is called without stdin, it writes a useless template.
+8. Validate: `draht-tools validate-plans $1`
+9. Commit: `draht-tools commit-docs "create phase $1 plans"`
+
+## Plan Format
+Plans use XML task format:
+```xml
+<task type="auto">
+  <n>Task name</n>
+  <context>Bounded context this task belongs to</context>
+  <domain>Aggregates, entities, value objects, or events touched</domain>
+  <files>affected files</files>
+  <test>
+    RED phase: Write failing tests FIRST.
+    - List specific test cases with expected behavior
+    - Test domain invariants and business rules
+    - Test at the right level: unit for domain logic, integration for context boundaries
+    - Tests MUST fail before implementation
+  </test>
+  <action>
+    GREEN phase: Minimal implementation to make tests pass.
+    - No gold-plating — just make the red tests green
+    - Respect aggregate boundaries
+    - Use domain language in code (class names, method names, variable names)
+  </action>
+  <refactor>
+    REFACTOR phase: Improve structure while keeping tests green.
+    - Extract value objects, push logic into domain layer
+    - Ensure naming matches ubiquitous language
+    - Remove duplication across bounded contexts (or make shared kernel explicit)
+  </refactor>
+  <verify>How to verify (tests pass + manual check if needed)</verify>
+  <done>What "done" looks like — expressed as passing test assertions</done>
+</task>
+```
+
+Task types: `auto`, `checkpoint:human-verify`, `checkpoint:decision`
+
+## Workflow
+This is one step in the per-phase cycle:
+
+```
+/discuss-phase N → /plan-phase N → /execute-phase N → /verify-work N
+```
+
+After completing this command, tell the user to start a fresh session (`/clear`) and run `/execute-phase $1`. Do NOT suggest `/next-milestone`.
+
+## Domain Rules for Plans
+- File/module structure should mirror bounded contexts (e.g., `src/billing/`, `src/catalog/`)
+- Never scatter one aggregate's logic across multiple contexts without an explicit ACL
+- If a plan introduces a new domain term, update `.planning/DOMAIN.md` first
+- Cross-context communication should use domain events, not direct imports

package/commands/progress.md

@@ -0,0 +1,30 @@
+---
+description: Show current GSD project status (milestone, phase, task, blockers)
+allowed-tools: Bash, Read
+---
+
+# /progress
+
+Show current project status.
+
+> **Tool note**: Invoke `draht-tools <subcommand>` as `node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" <subcommand>` via the Bash tool.
+
+## Atomic Reasoning
+
+Before checking progress, decompose project state into atomic reasoning units:
+
+1. **State the logical component** — What milestone are we in? What phase is active? What work is complete vs in-progress?
+2. **Validate independence** — Are there blockers? Are phases in the correct sequence? Is anything waiting on external input?
+3. **Verify correctness** — Does the reported state match reality? Are all verified phases truly complete? Are there unreported issues?
+
+## Steps
+1. Read `.planning/STATE.md` for current phase and status
+2. Read `.planning/ROADMAP.md` and extract all phases with their status
+3. Check for `.planning/CONTINUE-HERE.md` (paused session)
+4. Read `.planning/execution-log.jsonl` for the last 10 entries
+5. Report:
+   - Current phase and status
+   - Milestone completion (X of Y phases complete)
+   - Recent activity (last 5 task results)
+   - Any blockers or paused work
+   - Next suggested command based on state (e.g., `/resume-work`, `/discuss-phase N+1`)

package/commands/quick.md

@@ -0,0 +1,50 @@
+---
+description: Execute a small ad-hoc task with tracking (implementer subagent + TDD cycle)
+argument-hint: "<description>"
+allowed-tools: Bash, Read, Write, Edit, Task
+---
+
+# /quick
+
+Execute a small ad-hoc task with tracking.
+
+Task: $ARGUMENTS
+
+> **Tool note**: Invoke `draht-tools <subcommand>` as `node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" <subcommand>`. For subagents, use the **Task tool** with `subagent_type: "implementer"`.
+
+## Atomic Reasoning
+
+Before executing, decompose this task into atomic reasoning units:
+
+1. **State the logical component** — What is the single, concrete outcome? What files need to change? What behavior needs to work?
+2. **Validate independence** — Can this be done without touching other features? What dependencies exist? What could break?
+3. **Verify correctness** — What test proves this works? What edge cases matter? Is this testable behavior or pure config?
+
+**Synthesize execution plan:**
+- Define specific files to modify
+- Write failing test (if testable behavior)
+- Implement minimal solution
+- Verify and document
+
+## Steps
+1. Run `draht-tools next-quick-number` to get task number
+2. Analyze the task and write a concrete plan with actual task details (files, actions, verification). Pipe it into `draht-tools create-quick-plan`:
+   ```bash
+   echo 'plan content here' | node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" create-quick-plan NNN "$ARGUMENTS"
+   ```
+   The plan content must include: a `# Quick Task NNN: title` heading, a `## Tasks` section with one or more `<task>` XML blocks containing real file paths, real actions, and real verification steps — NOT placeholders like `[files]`.
+
+3. **Delegate execution via the Task tool** with `subagent_type: "implementer"` and prompt:
+   "Execute this task: $ARGUMENTS
+
+   Follow the TDD cycle:
+   - RED — Write a failing test that describes the desired behaviour
+   - GREEN — Write the minimum implementation to make it pass
+   - REFACTOR — Clean up while keeping the test green
+
+   Exception: skip the TDD cycle only for pure config or documentation-only tasks that have no testable behaviour.
+
+   After completion, report: files changed, tests written, and verification results."
+
+4. Write summary: `draht-tools write-quick-summary NNN`
+5. Update state: `draht-tools update-state`

package/commands/resume-work.md

@@ -0,0 +1,35 @@
+---
+description: Resume from the CONTINUE-HERE handoff document
+allowed-tools: Bash, Read, Write, Edit
+---
+
+# /resume-work
+
+Resume from last session state.
+
+> **Tool note**: Invoke `draht-tools <subcommand>` as `node "${CLAUDE_PLUGIN_ROOT}/bin/draht-tools.cjs" <subcommand>` via the Bash tool.
+
+## Atomic Reasoning
+
+Before resuming, decompose handoff context into atomic reasoning units:
+
+1. **State the logical component** — What phase/task was active? What was the last accomplishment? What decisions were made?
+2. **Validate independence** — Are there blockers? What changed since the pause? Is the codebase in the expected state?
+3. **Verify correctness** — Is the handoff document complete? Does the current state match what was documented? Can work continue safely?
+
+## Steps
+1. Read `.planning/CONTINUE-HERE.md` (if missing, tell the user there's nothing to resume)
+2. Read `.planning/STATE.md` for current phase/status
+3. Run `git status` to check current working state
+4. Compare handoff document's "Uncommitted Changes" to actual git state — report any discrepancies
+5. Summarize to the user:
+   - What was in progress
+   - What the next step is
+   - Any blockers to resolve first
+6. Delete `.planning/CONTINUE-HERE.md` only after the user confirms work is resumed
+7. Proceed with the next step from the handoff
+
+## Rules
+- Do not auto-execute the next step — confirm with the user first
+- If the codebase state doesn't match the handoff (e.g., uncommitted changes missing), flag it before proceeding
+- Preserve CONTINUE-HERE.md until the user acknowledges; this is the safety net

package/commands/review.md

@@ -0,0 +1,55 @@
+---
+description: Code review and security audit of recent changes (parallel reviewer + security-auditor subagents)
+argument-hint: "[scope]"
+allowed-tools: Bash, Read, Task
+---
+
+# /review
+
+Code review and security audit of recent changes, using subagents for parallel analysis.
+
+Scope: $ARGUMENTS
+
+If no scope given, reviews all recent uncommitted changes.
+
+> **Tool note**: For subagents, use the **Task tool** and dispatch multiple in parallel (single assistant turn = multiple Task tool calls).
+
+## Atomic Reasoning
+
+Before reviewing, decompose code changes into atomic reasoning units:
+
+**For each changed file:**
+1. **State the logical component** — What does this change do? What problem does it solve? What behavior does it add/modify?
+2. **Validate independence** — Does this change have side effects? Does it affect other modules? Are there hidden dependencies?
+3. **Verify correctness** — Is this change correct? Type-safe? Secure? Does it follow conventions? What could go wrong?
+
+**Synthesize review strategy:**
+- Group changes by concern (correctness, security, style)
+- Prioritize findings (critical, important, minor)
+- Identify patterns across multiple files
+- Check domain language compliance and bounded context boundaries
+
+## Steps
+1. Identify the scope:
+   - If argument given: use those files/directories/description as scope
+   - If no argument: run `git diff --stat` and `git diff --cached --stat` to find changes
+2. Determine the list of changed files and produce a scope summary
+
+3. **Delegate to subagents in parallel via the Task tool** (dispatch both in the same assistant turn):
+
+   - **Task tool** with `subagent_type: "reviewer"` and prompt:
+     "Review the following code changes for correctness, type safety, conventions, and potential issues. Scope: <scope summary and file list>. Read each changed file to understand the changes. For each finding: cite the exact file and line, explain the issue, suggest the fix. Prioritize: Critical (must fix) > Important (should fix) > Minor (style/optional). Check domain language compliance against `.planning/DOMAIN.md` if it exists."
+
+   - **Task tool** with `subagent_type: "security-auditor"` and prompt:
+     "Audit the following code changes for security vulnerabilities. Scope: <scope summary and file list>. Read each changed file. Check for: injection risks, auth bypasses, secrets in code, unsafe deserialization, path traversal, prototype pollution. Report findings with severity, file, line, and recommendation."
+
+4. Collect and merge results from both subagents
+5. Produce a unified, prioritized findings report:
+   - **Critical** — must fix before merge (security, data loss, crashes)
+   - **Important** — should fix (bugs, type issues, missing error handling)
+   - **Minor** — style, naming, or optional improvements
+
+## Rules
+- Cite file paths and line numbers precisely
+- Do not restate the diff — focus on findings
+- If no issues found, state that explicitly