@draht/coding-agent 2026.3.3 → 2026.3.4

package/dist/prompts/commands/init-project.md

@@ -0,0 +1,49 @@
+# /init-project
+
+Initialize GSD planning framework for an existing project: codebase mapping → questioning → domain model → requirements → roadmap.
+
+## Usage
+```
+/init-project [focus area or goal]
+```
+
+Use this when you have an existing codebase and want to add GSD methodology.
+For greenfield projects, use `/new-project` instead.
+
+## 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:
+   - `## 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
+8. 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.)
+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 GSD planning"`
+
+## 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
+- Respect what already exists — do not propose rewriting working code
+- Stop when you have: current state, goals, MVP scope, constraints, success criteria

package/dist/prompts/commands/next-milestone.md

@@ -0,0 +1,44 @@
+# /next-milestone
+
+Plan the next milestone after the current one is complete.
+
+## Usage
+```
+/next-milestone
+```
+
+## Prerequisites
+- `.planning/ROADMAP.md` must exist
+- Current milestone should be complete or nearly complete
+
+## Steps
+1. Load project context:
+   - Read `.planning/ROADMAP.md` — identify the completed milestone and its phases
+   - Read `.planning/STATE.md` — understand current status
+   - Read `.planning/REQUIREMENTS.md` — check which requirements are satisfied
+   - Read `.planning/DOMAIN.md` (if exists) — review domain model for evolution needs
+2. Review completed work:
+   - Scan `.planning/phases/` for all UAT reports (`*-UAT.md`) and summaries (`*-SUMMARY.md`)
+   - Note what was built, what worked well, what had issues
+3. Assess requirements:
+   - Which v1 requirements are now satisfied?
+   - Which v1 requirements remain?
+   - Should any v2 requirements be promoted based on what we learned?
+   - Are there new requirements discovered during implementation?
+4. Propose next milestone:
+   - Define 3-5 phases, each with a clear goal (outcome, not activity)
+   - Order phases by dependency
+   - Map each phase to specific requirements
+   - Estimate relative complexity
+5. Present the proposed milestone for user approval before writing files
+6. After approval:
+   - Update `ROADMAP.md` with the new milestone and phases
+   - Update `STATE.md` to reflect milestone transition
+   - Update `REQUIREMENTS.md` if requirements changed
+   - Update `DOMAIN.md` if domain model needs evolution
+   - Commit: `draht-tools commit-docs "plan next milestone"`
+
+## Rules
+- Always review what was actually built, not just what was planned
+- Be honest about requirements that slipped or changed scope
+- Each phase goal must be testable — "user can X" not "implement Y"

package/dist/prompts/commands/review.md

@@ -0,0 +1,26 @@
+# /review
+
+Ad-hoc code review and security audit of recent changes or a specific scope.
+
+## Usage
+```
+/review [scope]
+```
+
+If no scope given, reviews all recent uncommitted changes.
+
+## Steps
+1. Identify the scope:
+   - If argument given: review those files/directories/description
+   - If no argument: run `git diff --stat` and `git diff --cached --stat` to find changes
+2. For each changed file, examine:
+   - Correctness: logic errors, off-by-one, null handling, error paths
+   - Type safety: any `as` casts, `any` types, missing null checks
+   - Conventions: naming, file organization, import style
+   - Security: injection risks, auth bypasses, secrets in code, unsafe deserialization
+   - Performance: unnecessary allocations, missing indexes, N+1 queries
+3. Produce a 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
+4. For each finding: cite the exact file and line, explain the issue, suggest the fix

package/docs/custom-provider.md

@@ -172,10 +172,17 @@ models: [{
   // ...
   compat: {
     supportsDeveloperRole: false,      // use "system" instead of "developer"
-    supportsReasoningEffort: false,    // disable reasoning_effort param
+    supportsReasoningEffort: true,
+    reasoningEffortMap: {              // map pi-ai levels to provider values
+      minimal: "default",
+      low: "default",
+      medium: "default",
+      high: "default",
+      xhigh: "default"
+    },
     maxTokensField: "max_tokens",      // instead of "max_completion_tokens"
     requiresToolResultName: true,      // tool results need name field
-    requiresMistralToolIds: true       // tool IDs must be 9 alphanumeric chars
+    requiresMistralToolIds: true,
     thinkingFormat: "qwen"             // uses enable_thinking: true
   }
 }]
@@ -568,6 +575,7 @@ interface ProviderModelConfig {
     supportsStore?: boolean;
     supportsDeveloperRole?: boolean;
     supportsReasoningEffort?: boolean;
+    reasoningEffortMap?: Partial<Record<"minimal" | "low" | "medium" | "high" | "xhigh", string>>;
     supportsUsageInStreaming?: boolean;
     maxTokensField?: "max_completion_tokens" | "max_tokens";
     requiresToolResultName?: boolean;

package/docs/extensions.md

@@ -880,6 +880,14 @@ Subscribe to events. See [Events](#events) for event types and return values.
 
 Register a custom tool callable by the LLM. See [Custom Tools](#custom-tools) for full details.
 
+`pi.registerTool()` works both during extension load and after startup. You can call it inside `session_start`, command handlers, or other event handlers. New tools are refreshed immediately in the same session, so they appear in `pi.getAllTools()` and are callable by the LLM without `/reload`.
+
+Use `pi.setActiveTools()` to enable or disable tools (including dynamically added tools) at runtime.
+
+Use `promptSnippet` to customize that tool's one-line entry in `Available tools`, and `promptGuidelines` to append tool-specific bullets to the default `Guidelines` section when the tool is active.
+
+See [dynamic-tools.ts](../examples/extensions/dynamic-tools.ts) for a full example.
+
 ```typescript
 import { Type } from "@sinclair/typebox";
 import { StringEnum } from "@draht/ai";
@@ -888,6 +896,8 @@ pi.registerTool({
   name: "my_tool",
   label: "My Tool",
   description: "What this tool does",
+  promptSnippet: "Summarize or transform text according to action",
+  promptGuidelines: ["Use this tool when the user asks to summarize previously generated text."],
   parameters: Type.Object({
     action: StringEnum(["list", "add"] as const),
     text: Type.Optional(Type.String()),
@@ -1116,7 +1126,7 @@ const result = await pi.exec("git", ["status"], { signal, timeout: 5000 });
 
 ### pi.getActiveTools() / pi.getAllTools() / pi.setActiveTools(names)
 
-Manage active tools.
+Manage active tools. This works for both built-in tools and dynamically registered tools.
 
 ```typescript
 const active = pi.getActiveTools();  // ["read", "bash", "edit", "write"]
@@ -1276,6 +1286,10 @@ export default function (pi: ExtensionAPI) {
 
 Register tools the LLM can call via `pi.registerTool()`. Tools appear in the system prompt and can have custom rendering.
 
+Use `promptSnippet` for a short one-line entry in the `Available tools` section in the default system prompt. If omitted, pi falls back to `description`.
+
+Use `promptGuidelines` to add tool-specific bullets to the default system prompt `Guidelines` section. These bullets are included only while the tool is active (for example, after `pi.setActiveTools([...])`).
+
 Note: Some models are idiots and include the @ prefix in tool path arguments. Built-in tools strip a leading @ before resolving paths. If your custom tool accepts a path, normalize a leading @ as well.
 
 ### Tool Definition
@@ -1289,6 +1303,10 @@ pi.registerTool({
   name: "my_tool",
   label: "My Tool",
   description: "What this tool does (shown to LLM)",
+  promptSnippet: "List or add items in the project todo list",
+  promptGuidelines: [
+    "Use this tool for todo planning instead of direct file edits when the user asks for a task list."
+  ],
   parameters: Type.Object({
     action: StringEnum(["list", "add"] as const),  // Use StringEnum for Google compatibility
     text: Type.Optional(Type.String()),
@@ -1886,6 +1904,7 @@ All examples in [examples/extensions/](../examples/extensions/).
 | `question.ts` | Tool with user interaction | `registerTool`, `ui.select` |
 | `questionnaire.ts` | Multi-step wizard tool | `registerTool`, `ui.custom` |
 | `todo.ts` | Stateful tool with persistence | `registerTool`, `appendEntry`, `renderResult`, session events |
+| `dynamic-tools.ts` | Register tools after startup and during commands | `registerTool`, `session_start`, `registerCommand` |
 | `truncated-tool.ts` | Output truncation example | `registerTool`, `truncateHead` |
 | `tool-override.ts` | Override built-in read tool | `registerTool` (same name as built-in) |
 | **Commands** |||

package/docs/providers.md

@@ -65,6 +65,7 @@ pi
 | Vercel AI Gateway | `AI_GATEWAY_API_KEY` | `vercel-ai-gateway` |
 | ZAI | `ZAI_API_KEY` | `zai` |
 | OpenCode Zen | `OPENCODE_API_KEY` | `opencode` |
+| OpenCode Go | `OPENCODE_API_KEY` | `opencode-go` |
 | Hugging Face | `HF_TOKEN` | `huggingface` |
 | Kimi For Coding | `KIMI_API_KEY` | `kimi-coding` |
 | MiniMax | `MINIMAX_API_KEY` | `minimax` |
@@ -81,7 +82,8 @@ Store credentials in `~/.pi/agent/auth.json`:
   "anthropic": { "type": "api_key", "key": "sk-ant-..." },
   "openai": { "type": "api_key", "key": "sk-..." },
   "google": { "type": "api_key", "key": "..." },
-  "opencode": { "type": "api_key", "key": "..." }
+  "opencode": { "type": "api_key", "key": "..." },
+  "opencode-go": { "type": "api_key", "key": "..." }
 }
 ```
 

package/docs/settings.md

@@ -69,6 +69,7 @@ Edit directly or use `/settings` for common options.
 | Setting | Type | Default | Description |
 |---------|------|---------|-------------|
 | `branchSummary.reserveTokens` | number | `16384` | Tokens reserved for branch summarization |
+| `branchSummary.skipPrompt` | boolean | `false` | Skip "Summarize branch?" prompt on `/tree` navigation (defaults to no summary) |
 
 ### Retry
 

package/examples/extensions/README.md

@@ -33,6 +33,7 @@ cp permission-gate.ts ~/.draht/agent/extensions/
 | `question.ts` | Demonstrates `ctx.ui.select()` for asking the user questions with custom UI |
 | `questionnaire.ts` | Multi-question input with tab bar navigation between questions |
 | `tool-override.ts` | Override built-in tools (e.g., add logging/access control to `read`) |
+| `dynamic-tools.ts` | Register tools after startup (`session_start`) and at runtime via command, with prompt snippets and tool-specific prompt guidelines |
 | `built-in-tool-renderer.ts` | Custom compact rendering for built-in tools (read, bash, edit, write) while keeping original behavior |
 | `minimal-mode.ts` | Override built-in tool rendering for minimal display (only tool calls, no output in collapsed mode) |
 | `truncated-tool.ts` | Wraps ripgrep with proper output truncation (50KB/2000 lines) |

package/examples/extensions/antigravity-image-gen.ts

@@ -49,8 +49,10 @@ type SaveMode = (typeof SAVE_MODES)[number];
 
 const ANTIGRAVITY_ENDPOINT = "https://daily-cloudcode-pa.sandbox.googleapis.com";
 
+const DEFAULT_ANTIGRAVITY_VERSION = "1.18.3";
+
 const ANTIGRAVITY_HEADERS = {
-	"User-Agent": "antigravity/1.15.8 darwin/arm64",
+	"User-Agent": `antigravity/${process.env.PI_AI_ANTIGRAVITY_VERSION || DEFAULT_ANTIGRAVITY_VERSION} darwin/arm64`,
 	"X-Goog-Api-Client": "google-cloud-sdk vscode_cloudshelleditor/0.1",
 	"Client-Metadata": JSON.stringify({
 		ideType: "IDE_UNSPECIFIED",

package/examples/extensions/custom-provider-anthropic/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "pi-extension-custom-provider",
-  "version": "1.6.3",
+  "version": "1.7.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "pi-extension-custom-provider",
-      "version": "1.6.3",
+      "version": "1.7.0",
       "dependencies": {
         "@anthropic-ai/sdk": "^0.52.0"
       }

package/examples/extensions/custom-provider-anthropic/package.json

@@ -1,7 +1,7 @@
 {
   "name": "pi-extension-custom-provider-anthropic",
   "private": true,
-  "version": "1.6.3",
+  "version": "1.7.0",
   "type": "module",
   "scripts": {
     "clean": "echo 'nothing to clean'",

package/examples/extensions/custom-provider-gitlab-duo/package.json

@@ -1,7 +1,7 @@
 {
   "name": "pi-extension-custom-provider-gitlab-duo",
   "private": true,
-  "version": "1.6.3",
+  "version": "1.7.0",
   "type": "module",
   "scripts": {
     "clean": "echo 'nothing to clean'",

package/examples/extensions/custom-provider-qwen-cli/package.json

@@ -1,7 +1,7 @@
 {
   "name": "pi-extension-custom-provider-qwen-cli",
   "private": true,
-  "version": "1.5.3",
+  "version": "1.6.0",
   "type": "module",
   "scripts": {
     "clean": "echo 'nothing to clean'",

package/examples/extensions/dynamic-tools.ts

@@ -0,0 +1,74 @@
+/**
+ * Dynamic Tools Extension
+ *
+ * Demonstrates registering tools after session initialization.
+ *
+ * - Registers one tool during session_start
+ * - Registers additional tools at runtime via /add-echo-tool <name>
+ */
+
+import type { ExtensionAPI } from "@draht/coding-agent";
+import { Type } from "@sinclair/typebox";
+
+const ECHO_PARAMS = Type.Object({
+	message: Type.String({ description: "Message to echo" }),
+});
+
+function normalizeToolName(input: string): string | undefined {
+	const trimmed = input.trim().toLowerCase();
+	if (!trimmed) return undefined;
+	if (!/^[a-z0-9_]+$/.test(trimmed)) return undefined;
+	return trimmed;
+}
+
+export default function dynamicToolsExtension(pi: ExtensionAPI) {
+	const registeredToolNames = new Set<string>();
+
+	const registerEchoTool = (name: string, label: string, prefix: string): boolean => {
+		if (registeredToolNames.has(name)) {
+			return false;
+		}
+
+		registeredToolNames.add(name);
+		pi.registerTool({
+			name,
+			label,
+			description: `Echo a message with prefix: ${prefix}`,
+			promptSnippet: `Echo back user-provided text with ${prefix.trim()} prefix`,
+			promptGuidelines: ["Use this tool when the user asks for exact echo output."],
+			parameters: ECHO_PARAMS,
+			async execute(_toolCallId, params) {
+				return {
+					content: [{ type: "text", text: `${prefix}${params.message}` }],
+					details: { tool: name, prefix },
+				};
+			},
+		});
+
+		return true;
+	};
+
+	pi.on("session_start", (_event, ctx) => {
+		registerEchoTool("echo_session", "Echo Session", "[session] ");
+		ctx.ui.notify("Registered dynamic tool: echo_session", "info");
+	});
+
+	pi.registerCommand("add-echo-tool", {
+		description: "Register a new echo tool dynamically: /add-echo-tool <tool_name>",
+		handler: async (args, ctx) => {
+			const toolName = normalizeToolName(args);
+			if (!toolName) {
+				ctx.ui.notify("Usage: /add-echo-tool <tool_name> (lowercase, numbers, underscores)", "warning");
+				return;
+			}
+
+			const created = registerEchoTool(toolName, `Echo ${toolName}`, `[${toolName}] `);
+			if (!created) {
+				ctx.ui.notify(`Tool already registered: ${toolName}`, "warning");
+				return;
+			}
+
+			ctx.ui.notify(`Registered dynamic tool: ${toolName}`, "info");
+		},
+	});
+}

package/examples/extensions/with-deps/package-lock.json

@@ -1,12 +1,12 @@
 {
   "name": "pi-extension-with-deps",
-  "version": "1.19.3",
+  "version": "1.20.0",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "pi-extension-with-deps",
-      "version": "1.19.3",
+      "version": "1.20.0",
       "dependencies": {
         "ms": "^2.1.3"
       },

package/examples/extensions/with-deps/package.json

@@ -1,7 +1,7 @@
 {
   "name": "pi-extension-with-deps",
   "private": true,
-  "version": "1.19.3",
+  "version": "1.20.0",
   "type": "module",
   "scripts": {
     "clean": "echo 'nothing to clean'",

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@draht/coding-agent",
-	"version": "2026.3.3",
+	"version": "2026.3.4",
 	"description": "Coding agent CLI with read, bash, edit, write tools and session management",
 	"type": "module",
 	"drahtConfig": {
@@ -30,7 +30,6 @@
 		"examples",
 		"prompts",
 		"hooks",
-		"extensions",
 		"agents",
 		"bin",
 		"CHANGELOG.md"
@@ -40,16 +39,16 @@
 		"dev": "tsgo -p tsconfig.build.json --watch --preserveWatchOutput",
 		"build": "tsgo -p tsconfig.build.json && shx chmod +x dist/cli.js && bun run copy-assets",
 		"build:binary": "bun run build && bun build --compile ./dist/cli.js --outfile dist/pi && bun run copy-binary-assets",
-		"copy-assets": "shx mkdir -p dist/modes/interactive/theme && shx cp src/modes/interactive/theme/*.json dist/modes/interactive/theme/ && shx mkdir -p dist/core/export-html/vendor && shx cp src/core/export-html/template.html src/core/export-html/template.css src/core/export-html/template.js dist/core/export-html/ && shx cp src/core/export-html/vendor/*.js dist/core/export-html/vendor/ && shx rm -rf dist/prompts dist/hooks dist/extensions dist/agents && shx cp -r prompts dist/prompts && shx cp -r hooks dist/hooks && shx cp -r extensions dist/extensions && shx cp -r agents dist/agents",
-		"copy-binary-assets": "shx cp package.json dist/ && shx cp README.md dist/ && shx cp CHANGELOG.md dist/ && shx mkdir -p dist/theme && shx cp src/modes/interactive/theme/*.json dist/theme/ && shx mkdir -p dist/export-html/vendor && shx cp src/core/export-html/template.html dist/export-html/ && shx cp src/core/export-html/vendor/*.js dist/export-html/vendor/ && shx cp -r docs dist/ && shx cp -r examples dist/ && shx cp -r prompts dist/ && shx cp -r hooks dist/ && shx cp -r extensions dist/ && shx cp -r agents dist/ && shx cp ../../node_modules/@silvia-odwyer/photon-node/photon_rs_bg.wasm dist/",
+		"copy-assets": "shx mkdir -p dist/modes/interactive/theme && shx cp src/modes/interactive/theme/*.json dist/modes/interactive/theme/ && shx mkdir -p dist/core/export-html/vendor && shx cp src/core/export-html/template.html src/core/export-html/template.css src/core/export-html/template.js dist/core/export-html/ && shx cp src/core/export-html/vendor/*.js dist/core/export-html/vendor/ && shx rm -rf dist/prompts dist/hooks dist/agents && shx cp -r prompts dist/prompts && shx cp -r hooks dist/hooks && shx cp -r agents dist/agents",
+		"copy-binary-assets": "shx cp package.json dist/ && shx cp README.md dist/ && shx cp CHANGELOG.md dist/ && shx mkdir -p dist/theme && shx cp src/modes/interactive/theme/*.json dist/theme/ && shx mkdir -p dist/export-html/vendor && shx cp src/core/export-html/template.html dist/export-html/ && shx cp src/core/export-html/vendor/*.js dist/export-html/vendor/ && shx cp -r docs dist/ && shx cp -r examples dist/ && shx cp -r prompts dist/ && shx cp -r hooks dist/ && shx cp -r agents dist/ && shx cp ../../node_modules/@silvia-odwyer/photon-node/photon_rs_bg.wasm dist/",
 		"test": "vitest --run",
 		"prepublishOnly": "bun run clean && bun run build"
 	},
 	"dependencies": {
 		"@mariozechner/jiti": "^2.6.2",
-		"@draht/agent-core": "2026.3.3",
-		"@draht/ai": "2026.3.3",
-		"@draht/tui": "2026.3.3",
+		"@draht/agent-core": "2026.3.4",
+		"@draht/ai": "2026.3.4",
+		"@draht/tui": "2026.3.4",
 		"@silvia-odwyer/photon-node": "^0.3.4",
 		"chalk": "^5.5.0",
 		"cli-highlight": "^2.1.11",
@@ -62,6 +61,8 @@
 		"marked": "^15.0.12",
 		"minimatch": "^10.2.3",
 		"proper-lockfile": "^4.1.2",
+		"strip-ansi": "^7.1.0",
+		"undici": "^7.19.1",
 		"yaml": "^2.8.2"
 	},
 	"overrides": {

package/prompts/commands/fix.md

@@ -0,0 +1,29 @@
+# /fix
+
+Diagnose and fix a specific bug or failing task with TDD discipline.
+
+## Usage
+```
+/fix [description of what's broken]
+```
+
+## Steps
+1. **Diagnose**: Read the relevant code and error output to identify the root cause
+   - If a test is failing, run it first to see the actual error
+   - If a runtime bug, reproduce it and capture the error
+2. **Write a reproducing test**: Before touching any implementation:
+   - Write a test that demonstrates the bug (it must fail)
+   - Commit: `draht-tools commit-docs "red: reproduce bug"`
+3. **Minimal fix**: Write the smallest change that makes the test pass
+   - Do not refactor or add features — just fix the bug
+   - Run the full test suite to check for regressions
+   - Commit: `draht-tools commit-docs "green: fix description"`
+4. **Refactor** (if needed): Clean up without changing behavior
+   - Tests must stay green after every change
+   - Commit: `draht-tools commit-docs "refactor: description"`
+5. **Update state**: `draht-tools update-state`
+
+## Rules
+- Always reproduce before fixing — a fix without a test is a guess
+- One bug, one fix, one commit. Do not bundle unrelated changes.
+- If the root cause spans multiple files, explain the chain in the commit message

package/prompts/commands/init-project.md

@@ -0,0 +1,49 @@
+# /init-project
+
+Initialize GSD planning framework for an existing project: codebase mapping → questioning → domain model → requirements → roadmap.
+
+## Usage
+```
+/init-project [focus area or goal]
+```
+
+Use this when you have an existing codebase and want to add GSD methodology.
+For greenfield projects, use `/new-project` instead.
+
+## 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:
+   - `## 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
+8. 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.)
+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 GSD planning"`
+
+## 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
+- Respect what already exists — do not propose rewriting working code
+- Stop when you have: current state, goals, MVP scope, constraints, success criteria

package/prompts/commands/next-milestone.md

@@ -0,0 +1,44 @@
+# /next-milestone
+
+Plan the next milestone after the current one is complete.
+
+## Usage
+```
+/next-milestone
+```
+
+## Prerequisites
+- `.planning/ROADMAP.md` must exist
+- Current milestone should be complete or nearly complete
+
+## Steps
+1. Load project context:
+   - Read `.planning/ROADMAP.md` — identify the completed milestone and its phases
+   - Read `.planning/STATE.md` — understand current status
+   - Read `.planning/REQUIREMENTS.md` — check which requirements are satisfied
+   - Read `.planning/DOMAIN.md` (if exists) — review domain model for evolution needs
+2. Review completed work:
+   - Scan `.planning/phases/` for all UAT reports (`*-UAT.md`) and summaries (`*-SUMMARY.md`)
+   - Note what was built, what worked well, what had issues
+3. Assess requirements:
+   - Which v1 requirements are now satisfied?
+   - Which v1 requirements remain?
+   - Should any v2 requirements be promoted based on what we learned?
+   - Are there new requirements discovered during implementation?
+4. Propose next milestone:
+   - Define 3-5 phases, each with a clear goal (outcome, not activity)
+   - Order phases by dependency
+   - Map each phase to specific requirements
+   - Estimate relative complexity
+5. Present the proposed milestone for user approval before writing files
+6. After approval:
+   - Update `ROADMAP.md` with the new milestone and phases
+   - Update `STATE.md` to reflect milestone transition
+   - Update `REQUIREMENTS.md` if requirements changed
+   - Update `DOMAIN.md` if domain model needs evolution
+   - Commit: `draht-tools commit-docs "plan next milestone"`
+
+## Rules
+- Always review what was actually built, not just what was planned
+- Be honest about requirements that slipped or changed scope
+- Each phase goal must be testable — "user can X" not "implement Y"

package/prompts/commands/review.md

@@ -0,0 +1,26 @@
+# /review
+
+Ad-hoc code review and security audit of recent changes or a specific scope.
+
+## Usage
+```
+/review [scope]
+```
+
+If no scope given, reviews all recent uncommitted changes.
+
+## Steps
+1. Identify the scope:
+   - If argument given: review those files/directories/description
+   - If no argument: run `git diff --stat` and `git diff --cached --stat` to find changes
+2. For each changed file, examine:
+   - Correctness: logic errors, off-by-one, null handling, error paths
+   - Type safety: any `as` casts, `any` types, missing null checks
+   - Conventions: naming, file organization, import style
+   - Security: injection risks, auth bypasses, secrets in code, unsafe deserialization
+   - Performance: unnecessary allocations, missing indexes, N+1 queries
+3. Produce a 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
+4. For each finding: cite the exact file and line, explain the issue, suggest the fix