@claudetools/tools 0.8.2 → 0.8.4

package/dist/setup.js

@@ -747,11 +747,22 @@ fi
 # Escape the query for JSON (handle quotes and newlines)
 ESCAPED_QUERY=$(echo "$USER_QUERY" | head -c 500 | jq -Rs '.')
 
+# Get session state for query-aware budget allocation (if SESSION_ID available)
+SESSION_STATE_JSON='{}'
+if [ -n "$SESSION_ID" ]; then
+  # Try to get session state from SessionStore
+  TOOLS_DIR="$HOME/.claudetools/node_modules/@claudetools/tools"
+  if [ -f "$TOOLS_DIR/dist/context/session-helper.js" ]; then
+    SESSION_STATE_JSON=$(node "$TOOLS_DIR/dist/context/session-helper.js" "$SESSION_ID" 2>/dev/null || echo '{}')
+  fi
+fi
+
 # Inject context with semantic search based on the user's prompt
+# Include session_state if available for dynamic budget calculation
 RESULT=$(curl -s --max-time 2 -X POST "$API_URL/api/v1/context/inject" \\
   -H "Authorization: Bearer $API_KEY" \\
   -H "Content-Type: application/json" \\
-  -d "{\\"query\\": $ESCAPED_QUERY, \\"project_id\\": \\"$PROJECT_ID\\", \\"cwd\\": \\"$CWD\\"}" \\
+  -d "{\\"query\\": $ESCAPED_QUERY, \\"project_id\\": \\"$PROJECT_ID\\", \\"cwd\\": \\"$CWD\\", \\"session_state\\": $SESSION_STATE_JSON}" \\
   2>/dev/null)
 
 # Output context as additionalContext JSON for Claude Code
@@ -1330,6 +1341,170 @@ export async function runUninstall() {
     console.log('\n' + chalk.green('ClaudeTools removed from Claude Code.'));
     console.log(chalk.dim('Your ~/.claudetools/ config and data are preserved.\n'));
 }
+async function runOnboarding(apiUrl, apiKey, projectId, projectName) {
+    header('Project Onboarding');
+    info('Answer a few questions to help Claude understand your project better.');
+    console.log(chalk.dim('This creates memory facts that provide context in future sessions.\n'));
+    const spinner = ora('Starting onboarding session...').start();
+    try {
+        // Start onboarding session
+        const startResponse = await fetch(`${apiUrl}/api/v1/onboarding/start`, {
+            method: 'POST',
+            headers: {
+                'Content-Type': 'application/json',
+                'Authorization': `Bearer ${apiKey}`,
+            },
+            body: JSON.stringify({ project_id: projectId }),
+        });
+        if (!startResponse.ok) {
+            spinner.fail('Could not start onboarding');
+            const errorData = await startResponse.json().catch(() => ({}));
+            error(errorData.error || `HTTP ${startResponse.status}`);
+            return;
+        }
+        const startData = await startResponse.json();
+        if (!startData.success || !startData.data) {
+            spinner.fail('Failed to start onboarding');
+            return;
+        }
+        spinner.succeed('Onboarding session started');
+        const sessionId = startData.data.session_id;
+        let questions = startData.data.questions;
+        let state = startData.data.state;
+        let questionCount = 0;
+        const maxQuestions = 8; // Limit to avoid fatigue
+        // Interactive question loop
+        while (questions.length > 0 && questionCount < maxQuestions) {
+            const question = questions[0];
+            questionCount++;
+            console.log('');
+            console.log(chalk.cyan(`Question ${questionCount}`) + (question.category ? chalk.dim(` [${question.category}]`) : ''));
+            console.log(chalk.bold(question.question));
+            let answer;
+            if (question.options && question.options.length > 0) {
+                // Multiple choice question
+                const { selected } = await prompts({
+                    type: 'select',
+                    name: 'selected',
+                    message: 'Select an option:',
+                    choices: [
+                        ...question.options.map(opt => ({ title: opt, value: opt })),
+                        { title: 'Skip this question', value: '__skip__' },
+                    ],
+                });
+                if (selected === '__skip__' || !selected) {
+                    questions.shift();
+                    continue;
+                }
+                answer = selected;
+            }
+            else {
+                // Free text question
+                const { response } = await prompts({
+                    type: 'text',
+                    name: 'response',
+                    message: '>',
+                    validate: (v) => v.length > 0 || 'Please enter a response (or type "skip" to skip)',
+                });
+                if (!response || response.toLowerCase() === 'skip') {
+                    questions.shift();
+                    continue;
+                }
+                answer = response;
+            }
+            // Submit answer
+            const answerSpinner = ora('Processing...').start();
+            try {
+                const answerResponse = await fetch(`${apiUrl}/api/v1/onboarding/answer`, {
+                    method: 'POST',
+                    headers: {
+                        'Content-Type': 'application/json',
+                        'Authorization': `Bearer ${apiKey}`,
+                    },
+                    body: JSON.stringify({
+                        session_id: sessionId,
+                        question_id: question.id,
+                        answer,
+                    }),
+                });
+                if (answerResponse.ok) {
+                    const answerData = await answerResponse.json();
+                    if (answerData.success && answerData.data) {
+                        const factsCount = answerData.data.facts_extracted || 0;
+                        if (factsCount > 0) {
+                            answerSpinner.succeed(`Recorded (${factsCount} fact${factsCount > 1 ? 's' : ''} extracted)`);
+                        }
+                        else {
+                            answerSpinner.succeed('Recorded');
+                        }
+                        // Update questions and state
+                        if (answerData.data.next_questions) {
+                            questions = answerData.data.next_questions;
+                        }
+                        else {
+                            questions.shift();
+                        }
+                        if (answerData.data.state) {
+                            state = answerData.data.state;
+                        }
+                    }
+                    else {
+                        answerSpinner.warn('Answer recorded (no facts extracted)');
+                        questions.shift();
+                    }
+                }
+                else {
+                    answerSpinner.fail('Could not submit answer');
+                    questions.shift();
+                }
+            }
+            catch {
+                answerSpinner.fail('Network error');
+                questions.shift();
+            }
+            // Check if we should stop
+            if (state.phase === 'confirmation' || state.phase === 'done') {
+                break;
+            }
+        }
+        // Complete onboarding
+        console.log('');
+        const completeSpinner = ora('Completing onboarding...').start();
+        try {
+            const completeResponse = await fetch(`${apiUrl}/api/v1/onboarding/complete`, {
+                method: 'POST',
+                headers: {
+                    'Content-Type': 'application/json',
+                    'Authorization': `Bearer ${apiKey}`,
+                },
+                body: JSON.stringify({
+                    session_id: sessionId,
+                    project_id: projectId,
+                }),
+            });
+            if (completeResponse.ok) {
+                const completeData = await completeResponse.json();
+                if (completeData.success && completeData.data) {
+                    const totalFacts = completeData.data.facts_extracted || 0;
+                    completeSpinner.succeed(`Onboarding complete! ${totalFacts} facts stored in memory.`);
+                }
+                else {
+                    completeSpinner.succeed('Onboarding complete!');
+                }
+            }
+            else {
+                completeSpinner.warn('Onboarding session saved (completion had issues)');
+            }
+        }
+        catch {
+            completeSpinner.warn('Could not finalize onboarding');
+        }
+    }
+    catch (err) {
+        spinner.fail('Onboarding failed');
+        error(err instanceof Error ? err.message : String(err));
+    }
+}
 // -----------------------------------------------------------------------------
 // Project Init
 // -----------------------------------------------------------------------------
@@ -1491,12 +1666,41 @@ export async function runInit() {
     const newContent = existingContent.trimEnd() + '\n' + projectContent;
     writeFileSync(projectClaudeMd, newContent);
     success('Created .claude/CLAUDE.md');
+    // Ensure hooks are installed and configured
+    // (User might have run init without setup, or hooks might have been deleted)
+    header('Hook Configuration');
+    try {
+        await installHooks();
+        await configureSettings();
+        info('Hooks configured successfully');
+    }
+    catch (err) {
+        // Non-fatal - just warn
+        console.log(chalk.yellow('⚠ Warning: Could not configure hooks. Run "claudetools --setup" to fix.'));
+    }
     // Summary
     console.log('\n' + chalk.green('  Project initialized!\n'));
     console.log('  ' + chalk.bold('Project:') + ` ${projectName}`);
     console.log('  ' + chalk.bold('ID:') + ` ${projectId}`);
     console.log('  ' + chalk.bold('Config:') + ` ${projectClaudeMd}\n`);
-    console.log(chalk.dim('  Memory tools are now configured for this project.\n'));
+    // Offer onboarding
+    if (config.apiKey) {
+        const { runOnboard } = await prompts({
+            type: 'confirm',
+            name: 'runOnboard',
+            message: 'Run project onboarding? (Helps Claude understand your project)',
+            initial: true,
+        });
+        if (runOnboard) {
+            await runOnboarding(config.apiUrl || DEFAULT_CONFIG.apiUrl, config.apiKey, projectId, projectName);
+        }
+        else {
+            console.log(chalk.dim('\n  You can run onboarding later with: claudetools onboard\n'));
+        }
+    }
+    else {
+        console.log(chalk.dim('  Memory tools are now configured for this project.\n'));
+    }
 }
 // -----------------------------------------------------------------------------
 // Cleanup Command (standalone)

package/dist/templates/claude-md.d.ts

@@ -5,7 +5,7 @@ export declare const PROJECT_SECTION_END = "<!-- CLAUDETOOLS:PROJECT:END -->";
 /**
  * Global CLAUDE.md content - added to ~/.claude/CLAUDE.md
  */
-export declare const GLOBAL_TEMPLATE = "\n<!-- CLAUDETOOLS:START -->\n# ClaudeTools Memory System\n\nYou have access to a persistent memory system via the `claudetools_memory` MCP server. Use it to remember context across sessions.\n\n## Memory Tools\n\n### Searching Memory\n```\nmemory_search(query: \"authentication patterns\")\n```\nSearch for relevant facts, entities, and past context. Use this when:\n- Starting work on a feature to recall past decisions\n- Looking for patterns or conventions used before\n- Finding related code or architectural context\n\n### Storing Facts\n```\nmemory_store_fact(\n  entity1: \"UserService\",\n  relationship: \"USES\",\n  entity2: \"bcrypt\",\n  context: \"Password hashing uses bcrypt with 12 rounds\"\n)\n```\nStore important facts as relationships between entities. Use for:\n- Architectural decisions\n- Code patterns and conventions\n- Dependencies and relationships\n- User preferences learned during conversation\n\n### Context Injection\nContext is automatically injected at the start of each session based on the current project. Check `~/.claudetools/session-context.md` for project-specific context.\n\n## Task Management\n\n### Creating Work Plans with Auto-Dispatch\n```\ntask_plan(\n  goal: \"Add user authentication\",\n  epic_title: \"User Auth System\",\n  tasks: [...]\n)\n```\nBreak down complex work into tracked tasks. **Tasks are automatically set to `ready` status.**\n\nAfter `task_plan` completes, you will receive Task tool invocations to spawn parallel agents.\n**Execute ALL Task tool calls in a SINGLE message** to enable parallel execution.\n\n### Parallel Agent Workflow\n1. User describes work needed\n2. Call `task_plan_draft` to present the plan\n3. User says \"go\" to approve\n4. Call `task_plan` - tasks created in `ready` status\n5. Execute the provided Task tool calls in ONE message\n6. Agents work in parallel, each calling `task_complete` when done\n\n### Manual Task Start (Sequential)\n```\ntask_start(task_id: \"task_xxx\")\n```\nClaim a task before working on it. Use for sequential execution.\n\n### Completing Tasks\n```\ntask_complete(task_id: \"task_xxx\", summary: \"Implemented JWT auth with refresh tokens\")\n```\nMark tasks done with a summary of work completed. **Always call this when a task is finished.**\n\n## Codebase Intelligence\n\n### Start with codebase_map() - ALWAYS\n```\ncodebase_map()  # FIRST TOOL when exploring unfamiliar code\n```\n**When to use:** Starting a new task, exploring unfamiliar code, understanding project structure, finding entry points.\n\nThe map shows:\n- Project structure and key directories\n- Entry points and their exports\n- Framework detection (React, Express, etc.)\n- Key symbols and their locations\n\n**Use codebase_map BEFORE using Grep/Glob** - it gives you the lay of the land so you know where to look.\n\n### Then use targeted tools\n```\ncodebase_find(\"UserService\")  # Find specific symbols/files\ncodebase_context(\"src/auth.ts\")  # Get file dependencies\nanalyze_impact(\"validateToken\")  # See what changing a function affects\n```\n\n## CodeDNA: Generate Code, Save 99% Tokens\n\n**When creating APIs/CRUD operations:** Call `codedna_generate_api` instead of writing code manually.\n\n```\ncodedna_generate_api({\n  spec: \"User(email:string:unique, password:string:hashed, age:integer:min(18))\",\n  framework: \"express\",\n  options: { auth: true, validation: true, tests: true }\n})\n```\n\n**Generates 6 production files** (models, controllers, routes, validators, auth, tests) in ~5 seconds.\n**Saves:** 30,000 tokens \u2192 200 tokens (99% reduction)\n\n## Best Practices\n\n1. **Search before implementing** - Check memory for existing patterns\n2. **Store decisions** - Save architectural choices as facts\n3. **Use task tracking** - Break complex work into tasks\n4. **Use CodeDNA for APIs** - Generate instead of write (99% token savings)\n<!-- CLAUDETOOLS:END -->\n";
+export declare const GLOBAL_TEMPLATE = "\n<!-- CLAUDETOOLS:START -->\n# ClaudeTools Memory System\n\nYou have access to a persistent memory system. **Context is AUTO-INJECTED via hooks** - you rarely need to call memory tools explicitly.\n\n## \u26A0\uFE0F IMPORTANT: Hooks vs MCP Tools\n\n**AUTOMATIC (via hooks - zero context cost):**\n- Context injection \u2192 `user-prompt-submit` hook runs on every message\n- Fact extraction \u2192 `post-tool-use` hook extracts from your work\n- Session context \u2192 `session-start` hook provides initial context\n\n**EXPLICIT (MCP tools - costs context):**\n- `memory_store_fact` \u2192 Store a specific fact you learned\n- `task_plan` / `task_start` / `task_complete` \u2192 Task management\n\n**DO NOT CALL these tools routinely (context already injected):**\n- `memory_search` - only if you need DIFFERENT search params\n- `memory_inject` - only if you need to refresh for a different query\n- `memory_get_context` - only for debugging\n- `memory_index` - only for debugging\n\n## Storing Facts (DO use this)\n```\nmemory_store_fact(\n  entity1: \"UserService\",\n  relationship: \"USES\",\n  entity2: \"bcrypt\",\n  context: \"Password hashing uses bcrypt with 12 rounds\"\n)\n```\nStore important facts when you learn something concrete. The `post-tool-use` hook also extracts facts automatically.\n\n## Task Management\n\n### Creating Work Plans with Auto-Dispatch\n```\ntask_plan(\n  goal: \"Add user authentication\",\n  epic_title: \"User Auth System\",\n  tasks: [...]\n)\n```\nBreak down complex work into tracked tasks. **Tasks are automatically set to `ready` status.**\n\nAfter `task_plan` completes, you will receive Task tool invocations to spawn parallel agents.\n**Execute ALL Task tool calls in a SINGLE message** to enable parallel execution.\n\n### Parallel Agent Workflow\n1. User describes work needed\n2. Call `task_plan_draft` to present the plan\n3. User says \"go\" to approve\n4. Call `task_plan` - tasks created in `ready` status\n5. Execute the provided Task tool calls in ONE message\n6. Agents work in parallel, each calling `task_complete` when done\n\n### Manual Task Start (Sequential)\n```\ntask_start(task_id: \"task_xxx\")\n```\nClaim a task before working on it. Use for sequential execution.\n\n### Completing Tasks\n```\ntask_complete(task_id: \"task_xxx\", summary: \"Implemented JWT auth with refresh tokens\")\n```\nMark tasks done with a summary of work completed. **Always call this when a task is finished.**\n\n## Codebase Intelligence\n\n### Start with codebase_map() - ALWAYS\n```\ncodebase_map()  # FIRST TOOL when exploring unfamiliar code\n```\n**When to use:** Starting a new task, exploring unfamiliar code, understanding project structure, finding entry points.\n\nThe map shows:\n- Project structure and key directories\n- Entry points and their exports\n- Framework detection (React, Express, etc.)\n- Key symbols and their locations\n\n**Use codebase_map BEFORE using Grep/Glob** - it gives you the lay of the land so you know where to look.\n\n### Then use targeted tools\n```\ncodebase_find(\"UserService\")  # Find specific symbols/files\ncodebase_context(\"src/auth.ts\")  # Get file dependencies\nanalyze_impact(\"validateToken\")  # See what changing a function affects\n```\n\n## CodeDNA: Generate Code, Save 99% Tokens\n\n**When creating APIs/CRUD operations:** Call `codedna_generate_api` instead of writing code manually.\n\n```\ncodedna_generate_api({\n  spec: \"User(email:string:unique, password:string:hashed, age:integer:min(18))\",\n  framework: \"express\",\n  options: { auth: true, validation: true, tests: true }\n})\n```\n\n**Generates 6 production files** (models, controllers, routes, validators, auth, tests) in ~5 seconds.\n**Saves:** 30,000 tokens \u2192 200 tokens (99% reduction)\n\n## Best Practices\n\n1. **Trust auto-injection** - Context is injected automatically, don't call memory_search\n2. **Store decisions** - Use `memory_store_fact` for architectural choices\n3. **Use task tracking** - Break complex work into tasks\n4. **Use CodeDNA for APIs** - Generate instead of write (99% token savings)\n5. **Minimize tool calls** - Every MCP call costs context tokens\n<!-- CLAUDETOOLS:END -->\n";
 /**
  * Project-level CLAUDE.md content - added to .claude/CLAUDE.md
  */

package/dist/templates/claude-md.js

@@ -14,20 +14,26 @@ export const GLOBAL_TEMPLATE = `
 ${SECTION_START}
 # ClaudeTools Memory System
 
-You have access to a persistent memory system via the \`claudetools_memory\` MCP server. Use it to remember context across sessions.
+You have access to a persistent memory system. **Context is AUTO-INJECTED via hooks** - you rarely need to call memory tools explicitly.
 
-## Memory Tools
+## ⚠️ IMPORTANT: Hooks vs MCP Tools
 
-### Searching Memory
-\`\`\`
-memory_search(query: "authentication patterns")
-\`\`\`
-Search for relevant facts, entities, and past context. Use this when:
-- Starting work on a feature to recall past decisions
-- Looking for patterns or conventions used before
-- Finding related code or architectural context
+**AUTOMATIC (via hooks - zero context cost):**
+- Context injection → \`user-prompt-submit\` hook runs on every message
+- Fact extraction → \`post-tool-use\` hook extracts from your work
+- Session context → \`session-start\` hook provides initial context
+
+**EXPLICIT (MCP tools - costs context):**
+- \`memory_store_fact\` → Store a specific fact you learned
+- \`task_plan\` / \`task_start\` / \`task_complete\` → Task management
 
-### Storing Facts
+**DO NOT CALL these tools routinely (context already injected):**
+- \`memory_search\` - only if you need DIFFERENT search params
+- \`memory_inject\` - only if you need to refresh for a different query
+- \`memory_get_context\` - only for debugging
+- \`memory_index\` - only for debugging
+
+## Storing Facts (DO use this)
 \`\`\`
 memory_store_fact(
   entity1: "UserService",
@@ -36,14 +42,7 @@ memory_store_fact(
   context: "Password hashing uses bcrypt with 12 rounds"
 )
 \`\`\`
-Store important facts as relationships between entities. Use for:
-- Architectural decisions
-- Code patterns and conventions
-- Dependencies and relationships
-- User preferences learned during conversation
-
-### Context Injection
-Context is automatically injected at the start of each session based on the current project. Check \`~/.claudetools/session-context.md\` for project-specific context.
+Store important facts when you learn something concrete. The \`post-tool-use\` hook also extracts facts automatically.
 
 ## Task Management
 
@@ -120,10 +119,11 @@ codedna_generate_api({
 
 ## Best Practices
 
-1. **Search before implementing** - Check memory for existing patterns
-2. **Store decisions** - Save architectural choices as facts
+1. **Trust auto-injection** - Context is injected automatically, don't call memory_search
+2. **Store decisions** - Use \`memory_store_fact\` for architectural choices
 3. **Use task tracking** - Break complex work into tasks
 4. **Use CodeDNA for APIs** - Generate instead of write (99% token savings)
+5. **Minimize tool calls** - Every MCP call costs context tokens
 ${SECTION_END}
 `;
 /**
@@ -134,31 +134,19 @@ export function getProjectTemplate(projectId, projectName) {
 ${SECTION_START}
 # Project: ${projectName}
 
-This project is registered with ClaudeTools Memory.
-
 **Project ID:** \`${projectId}\`
 
-## Project Memory
-
-Use memory tools to search and store project-specific context:
+Context is **auto-injected** via hooks. Only use \`memory_store_fact\` to store new facts:
 
 \`\`\`
-# Search this project's memory
-memory_search(query: "your search", project_id: "${projectId}")
-
-# Store a project fact
 memory_store_fact(
   entity1: "ComponentName",
   relationship: "IMPLEMENTS",
   entity2: "PatternName",
-  context: "Description of the relationship",
+  context: "Why this decision was made",
   project_id: "${projectId}"
 )
 \`\`\`
-
-## Session Context
-
-Project-specific context is injected automatically. Check \`~/.claudetools/session-context.md\` for current context.
 ${SECTION_END}
 `;
 }

package/dist/templates/worker-prompt.js

@@ -67,136 +67,42 @@ function buildIdentitySection(worker) {
 function buildBehavioralSection(taskId) {
     return `<!-- Layer 2: Behavioral Guidelines -->
 <behavioral_guidelines>
-  <core_behaviors>
-    <behavior id="codedna_first" priority="MANDATORY">
-      BEFORE writing code manually, check if CodeDNA can generate it:
-
-      DISCOVERY WORKFLOW:
-      1. Call codedna_list_generators() to see available generators
-      2. Check if task includes Entity DSL format
-         Example: "User(email:string:unique, password:string:hashed)"
-      3. Detect framework from project (package.json, existing code)
-      4. Match detected framework to generator capabilities
-      5. Call appropriate generator with detected settings
-
-      BENEFITS:
-      → Saves 95-99% tokens vs manual coding
-      → Generates production-ready code with validation, auth, tests
-
-      ONLY write code manually when:
-      - Logic is too complex for generation
-      - Modifying existing code (not creating new)
-      - Custom business rules that can't be templated
-    </behavior>
-
-    <behavior id="tool_first" priority="MANDATORY">
-      BEFORE writing code, use available tools:
-
-      1. codebase_map: START HERE - Get project overview
-         → Understand project structure and key entry points
-         → Identify frameworks and patterns in use
-         → Find relevant directories before diving in
-         → Use BEFORE Grep/Glob for unfamiliar code
-
-      2. memory_search: Check for existing patterns and decisions
-         → "How was authentication implemented?"
-         → "What patterns are used for X?"
-
-      3. codebase_find: Find specific symbols/files
-         → Search for existing code to extend/adapt
-
-      4. codebase_context: Understand file dependencies
-         → See what a file imports/exports
-
-      5. docs_get: Retrieve cached documentation
-         → Get up-to-date API references
-    </behavior>
-
-    <behavior id="minimal_changes" priority="IMPORTANT">
-      Make ONLY the changes required for this task.
-      NEVER:
-      - Refactor unrelated code
-      - Add features not requested
-      - Over-engineer solutions
-      - Add unnecessary abstractions
-    </behavior>
-  </core_behaviors>
+  <behavior id="codedna_first" priority="MANDATORY">
+    BEFORE writing code: codedna_list_generators() → check if task matches generator
+    Entity DSL: "User(email:string:unique, password:string:hashed)"
+    Only write manually for: complex logic, modifications, custom business rules
+  </behavior>
+
+  <behavior id="tool_first" priority="MANDATORY">
+    Tool precedence: codebase_map → memory_search → codebase_find → docs_get
+  </behavior>
+
+  <behavior id="minimal_changes" priority="IMPORTANT">
+    Make ONLY task-required changes. No refactoring, features, or abstractions.
+  </behavior>
 </behavioral_guidelines>`;
 }
 function buildStandardsSection() {
     return `<!-- Layer 3: Standards & Best Practices -->
 <standards>
   <code_quality>
-    - Write code that others can understand
-    - Prefer explicit over implicit
-    - Validate inputs at system boundaries
-    - Handle errors with clear messages
+    Australian English. Explicit over implicit. Validate boundaries. Clear errors.
   </code_quality>
 
-  <formatting>
-    - Use Australian English in comments and messages
-    - Follow existing code style in the project
-    - Include file paths with line numbers in references
-  </formatting>
-
   <memory_usage priority="CRITICAL">
-    When storing facts with memory_store_fact(), follow these rules:
-
-    ✅ STORE (learned contextual knowledge):
-    - Project discoveries: Anti-patterns found, bugs fixed, patterns discovered
-    - User preferences: Workflows, communication styles learned through interaction
-    - Architectural decisions WHY: Reasoning behind choices, rejected alternatives
-    - Solutions that worked: Specific implementations with context
-
-    ❌ DON'T STORE (generic documentation):
-    - Tool behavior: How the tool system works (already in API docs)
-    - Universal knowledge: Programming concepts, language features
-    - Temporary state: Current task status, session-specific data
-
-    Rule of thumb: "Would I need to rediscover this in 3 months?"
-    → YES = store it (learned pattern, specific to this context)
-    → NO = don't store it (universal knowledge, temporary state)
+    Store: project discoveries, user preferences, decision rationale, working solutions
+    Don't store: tool behavior, universal knowledge, temporary state
+    Rule: "Would I rediscover this in 3 months?" → YES = store
   </memory_usage>
 
   <documentation_files priority="MANDATORY">
-    NEVER create .md files in random locations. Follow these rules:
-
-    DIRECTORY STRUCTURE:
-    - docs/           → Project documentation, guides, specs
-    - docs/research/  → Research notes, analysis, investigations
-    - docs/decisions/ → Architecture Decision Records (ADRs)
-    - CHANGELOG.md    → Only in project root
-    - README.md       → Only in project root or package roots
-
-    NAMING CONVENTIONS:
-    - Use lowercase with hyphens: user-authentication-guide.md
-    - NEVER use spaces or underscores in filenames
-    - Include date prefix for time-sensitive docs: YYYY-MM-DD-topic.md
-      Example: 2025-12-05-api-migration-plan.md
-    - Research docs: YYYY-MM-DD-research-topic.md
-    - Decision records: NNNN-decision-title.md (e.g., 0001-use-jwt-auth.md)
-
-    ANTI-PATTERNS (NEVER DO):
-    - Creating PLAN.md, NOTES.md, TODO.md in project root
-    - Random capitalised filenames like IMPLEMENTATION_GUIDE.md
-    - Nested docs in src/ or lib/ directories
-    - Multiple README files outside package roots
-    - Temporary docs without dates (impossible to clean up later)
-
-    BEFORE CREATING ANY .md FILE:
-    1. Check if docs/ directory exists - create if needed
-    2. Determine correct subdirectory (research/, decisions/, etc.)
-    3. Use proper naming convention with date if temporal
-    4. Ask user if uncertain about placement
+    Structure: docs/research/, docs/decisions/, README.md/CHANGELOG.md in root only
+    Naming: lowercase-with-hyphens.md, YYYY-MM-DD-topic.md for temporal docs
+    Never: PLAN.md/NOTES.md in root, random caps, nested in src/, undated temp files
   </documentation_files>
 
   <completion_summary>
-    When calling task_complete, include:
-    - Implementation: What you built/changed
-    - Files: List of modified files with paths
-    - Decisions: Any architectural choices made
-    - Testing: How changes were verified
-    - Notes: Caveats, limitations, follow-up needed
+    Include: implementation, files modified, decisions, testing, notes
   </completion_summary>
 </standards>`;
 }
@@ -204,31 +110,10 @@ function buildDomainSection(worker) {
     return `<!-- Layer 4: Domain Knowledge -->
 <domain_knowledge>
   <codedna_capabilities>
-    CODEDNA DISCOVERY PATTERN:
-    1. Call codedna_list_generators() to see available generators
-    2. Each generator lists supported frameworks and options
-    3. Detect project framework from package.json/pyproject.toml
-    4. Match detected framework to generator capabilities
-    5. If no match, ASK the user which framework to use
-
-    ENTITY DSL FORMAT:
-    EntityName(field:type:constraint, field:type:constraint, ...)
-
-    TYPES:
-    - string, integer, decimal, boolean, datetime
-    - ref(EntityName) - foreign key reference
-    - enum(val1|val2|val3) - enumeration
-
-    CONSTRAINTS:
-    - unique, required, min(n), max(n), hashed, default(value)
-    - UI hints: textarea, switch, radio (for form rendering)
-
-    WORKFLOW:
-    1. codedna_list_generators() → discover capabilities
-    2. codedna_validate_spec(spec) → validate DSL syntax
-    3. codedna_generate_*(spec, framework, options) → generate code
-
-    DO NOT assume frameworks exist - always discover via codedna_list_generators
+    Discovery: codedna_list_generators() → detect framework → validate spec → generate
+    DSL: EntityName(field:type:constraint, ...)
+    Types: string, integer, decimal, boolean, datetime, ref(Entity), enum(a|b)
+    Constraints: unique, required, min(n), max(n), hashed, default(v), textarea, switch
   </codedna_capabilities>
 
   <worker_expertise>
@@ -239,26 +124,9 @@ function buildDomainSection(worker) {
 function buildCrossCuttingSection() {
     return `<!-- Layer 5: Cross-Cutting Concerns -->
 <cross_cutting_concerns>
-  <error_handling>
-    - Validate inputs at boundaries (API, CLI, file I/O)
-    - Fail fast with clear error messages
-    - Log errors with sufficient context for debugging
-    - Provide actionable guidance to users
-  </error_handling>
-
-  <security>
-    CRITICAL: Follow OWASP Top 10 guidelines
-    - Never expose sensitive data (API keys, passwords, tokens)
-    - Sanitize all user inputs
-    - Use parameterized queries (never string concat for SQL)
-    - Apply principle of least privilege
-  </security>
-
-  <performance>
-    - Don't optimise prematurely
-    - Consider token efficiency in prompts
-    - Use CodeDNA for boilerplate (saves 95%+ tokens)
-  </performance>
+  <error_handling>Validate boundaries. Fail fast. Clear messages. Actionable guidance.</error_handling>
+  <security>OWASP Top 10. No exposed secrets. Sanitize inputs. Parameterized queries. Least privilege.</security>
+  <performance>No premature optimization. Token efficiency. CodeDNA for boilerplate.</performance>
 </cross_cutting_concerns>`;
 }
 function buildTaskSection(task, epicContext) {
@@ -309,54 +177,19 @@ function buildSiblingSection(siblingTasks) {
 function buildProtocolSection(taskId) {
     return `<!-- Protocol -->
 <protocol>
-  <step number="1" action="START">
-    Call: task_start(task_id="${taskId}", agent_id="your-agent-id")
-    This claims the task and prevents conflicts.
-  </step>
-
-  <step number="2" action="CHECK_CODEDNA">
-    IF task involves creating entities/APIs:
-    → Look for Entity DSL in task description
-    → Call codedna_generate_api with the spec
-    → Review generated code, make adjustments if needed
-
-    IF task is modification/complex logic:
-    → Use memory_search and codebase_find first
-    → Write code manually only when necessary
-  </step>
-
-  <step number="3" action="IMPLEMENT">
-    Complete the requirements described in the task.
-    Make minimal changes. Don't over-engineer.
-  </step>
-
-  <step number="4" action="COMPLETE">
-    Call: task_complete(task_id="${taskId}", summary="detailed summary")
-
-    Include in summary:
-    - What you implemented
-    - Files created/modified
-    - Decisions made
-    - How you verified it works
-  </step>
+  <step number="1">task_start(task_id="${taskId}")</step>
+  <step number="2">Check CodeDNA for entities/APIs, else use tools (memory_search, codebase_find)</step>
+  <step number="3">Implement requirements. Minimal changes.</step>
+  <step number="4">task_complete(task_id="${taskId}", summary="impl, files, decisions, testing")</step>
 
   <error_handling>
-    IF you encounter blocking issues:
-
-    1. Log error:
-       task_add_context(task_id="${taskId}", context_type="work_log",
-         content="ERROR: description", added_by="your-agent-id")
-
-    2. Release task:
-       task_release(task_id="${taskId}", agent_id="your-agent-id",
-         new_status="blocked", work_log="summary of issue")
-
-    Do NOT mark incomplete work as complete.
+    Blocking issues: task_add_context + task_release(status="blocked")
+    Never mark incomplete work as complete.
   </error_handling>
 </protocol>
 
 ---
-**Begin work now. Remember to call task_start first!**`;
+**Begin work now. Call task_start first!**`;
 }
 /**
  * Build a minimal prompt for simple tasks