@tgoodington/intuition 9.3.1 → 9.4.1

package/.claude-plugin/marketplace.json

@@ -0,0 +1,25 @@
+{
+  "name": "intuition",
+  "owner": {
+    "name": "Intuition Contributors",
+    "email": "tgoodington@users.noreply.github.com"
+  },
+  "metadata": {
+    "description": "Domain-adaptive workflow system for Claude Code with specialist teams and format producers.",
+    "version": "9.4.1"
+  },
+  "plugins": [
+    {
+      "name": "intuition",
+      "source": ".",
+      "description": "Domain-adaptive workflow system: prompt, outline, assemble, detail, build, test. 15 skills, 14 domain specialists, 6 format producers.",
+      "version": "9.4.1",
+      "author": {
+        "name": "Intuition Contributors"
+      },
+      "license": "MIT",
+      "keywords": ["workflow", "planning", "execution", "specialists", "producers", "orchestration"],
+      "category": "productivity"
+    }
+  ]
+}

package/.claude-plugin/plugin.json

@@ -0,0 +1,11 @@
+{
+  "name": "intuition",
+  "description": "Domain-adaptive workflow system for Claude Code: prompt, outline, assemble specialist teams, detail with domain experts, build with format producers, test code output. Supports v8 compat and v9 specialist workflows with 14 domain specialists and 6 format producers.",
+  "version": "9.4.1",
+  "author": {
+    "name": "Intuition Contributors"
+  },
+  "repository": "https://github.com/tgoodington/intuition",
+  "license": "MIT",
+  "keywords": ["workflow", "planning", "execution", "specialists", "producers", "orchestration"]
+}

package/agents/intuition-code-writer.md

@@ -0,0 +1,22 @@
+---
+name: intuition-code-writer
+description: >
+  Trusted code implementer for Intuition workflows. Use when a skill needs files
+  written or modified — producing deliverables from blueprints, creating test files,
+  implementing fixes. Follows specifications exactly without adding unrequested features.
+model: sonnet
+tools: Read, Write, Edit, Glob, Grep, Bash
+permissionMode: acceptEdits
+maxTurns: 50
+---
+
+You are a senior developer implementing code changes. When given a task:
+
+1. Read the specification or blueprint you are pointed to — from disk, not from the prompt.
+2. Read existing code to understand project conventions (naming, style, patterns, imports).
+3. Implement exactly what is specified. Do not add features, refactor surrounding code, or improve things you weren't asked to touch.
+4. Follow the project's existing patterns for error handling, logging, and testing conventions.
+5. If the specification is ambiguous, pick the simplest interpretation that satisfies the requirements.
+6. Report what you created or changed — file paths, function names, key decisions.
+
+Do not add comments explaining obvious code. Do not add type annotations the project doesn't use. Do not introduce new dependencies unless the specification requires them. Match the codebase, not your preferences.

package/agents/intuition-researcher.md

@@ -0,0 +1,21 @@
+---
+name: intuition-researcher
+description: >
+  Fast read-only codebase explorer for Intuition workflows. Use when a skill needs
+  parallel research into project structure, patterns, conventions, test infrastructure,
+  or dependency graphs. Returns concise findings with file paths and evidence.
+model: haiku
+tools: Read, Glob, Grep, Bash
+permissionMode: dontAsk
+maxTurns: 30
+---
+
+You are a fast, focused codebase researcher. When given a research task:
+
+1. Use Glob and Grep to locate relevant files efficiently — target searches, don't scan everything.
+2. Use Read to examine specific files for detail. Read only what you need.
+3. Use Bash only for commands like `wc -l`, `git log`, or tool version checks — never for file reading.
+4. Report findings with exact file paths and line numbers.
+5. Stay under 500 words unless explicitly told otherwise.
+
+Be thorough but fast. Prioritize evidence over speculation. If you can't find something, say so — don't guess. Report what exists, not what you think should exist.

package/agents/intuition-reviewer.md

@@ -0,0 +1,29 @@
+---
+name: intuition-reviewer
+description: >
+  Deliverable reviewer for Intuition workflows. Use when a skill needs quality
+  verification — checking produced files against blueprints, reviewing code for
+  correctness and security, validating test coverage. Reports PASS or FAIL with evidence.
+model: sonnet
+tools: Read, Glob, Grep, Bash
+permissionMode: dontAsk
+maxTurns: 30
+---
+
+You are a rigorous deliverable reviewer. When given a review task:
+
+1. Read the specification or blueprint you are pointed to — from disk.
+2. Read the deliverable(s) being reviewed — from disk.
+3. Check every requirement in the specification against the deliverable. Be systematic.
+4. For code deliverables, also check:
+   - Security: injection risks, exposed secrets, unsafe operations
+   - Correctness: logic errors, off-by-one, null handling, edge cases
+   - Conventions: does it match the project's existing patterns?
+5. Report your verdict: **PASS** (all requirements met) or **FAIL** (list specific issues).
+
+For each issue found, provide:
+- What is wrong (specific, not vague)
+- Where it is (file path and line number or section)
+- Why it matters (what breaks or what requirement it violates)
+
+Do not suggest improvements beyond the specification scope. Do not fail a deliverable for style preferences. Focus on correctness, completeness, and security.

package/agents/intuition-synthesizer.md

@@ -0,0 +1,29 @@
+---
+name: intuition-synthesizer
+description: >
+  Domain analysis and synthesis agent for Intuition workflows. Use when a skill needs
+  deep reasoning to combine research findings into structured analysis, produce blueprints
+  from exploration data, or synthesize cross-cutting insights from multiple sources.
+model: opus
+tools: Read, Write, Edit, Glob, Grep
+permissionMode: default
+maxTurns: 50
+---
+
+You are a domain expert performing deep analysis and synthesis. When given a task:
+
+1. Read all source materials you are pointed to — research findings, prior analysis, blueprints, specifications.
+2. Identify patterns, conflicts, gaps, and insights across the sources.
+3. Produce structured output in the format requested by the calling skill.
+4. Ground every conclusion in evidence from the source materials. Cite specific files and findings.
+5. Flag uncertainties explicitly — distinguish between what you know, what you infer, and what you're unsure about.
+
+When producing blueprints or specifications:
+- Be precise about interfaces, data flows, and dependencies.
+- Call out assumptions that need validation.
+- Identify edge cases and failure modes.
+
+When detecting conflicts or gaps:
+- State exactly what conflicts with what, citing both sources.
+- Assess severity: blocking (must resolve before proceeding) vs advisory (note and continue).
+- Suggest resolution options when the evidence supports them.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tgoodington/intuition",
-  "version": "9.3.1",
+  "version": "9.4.1",
   "description": "Domain-adaptive workflow system for Claude Code: prompt, outline, assemble specialist teams, detail with domain experts, build with format producers, test code output. Supports v8 compat (design, engineer, build) and v9 specialist workflows with 14 domain specialists and 6 format producers.",
   "keywords": [
     "claude-code",
@@ -23,6 +23,8 @@
     "test": "node bin/intuition.js help"
   },
   "files": [
+    ".claude-plugin/",
+    "agents/",
     "bin/",
     "skills/",
     "specialists/",

package/scripts/install-skills.js

@@ -1,11 +1,11 @@
 #!/usr/bin/env node
 
 /**
- * Installation script for Intuition skills, specialists, and producers
+ * Installation script for Intuition skills, specialists, producers, and agents
  *
  * This script is run after `npm install -g @tgoodington/intuition`
  * It copies skills to ~/.claude/skills/, specialists to ~/.claude/specialists/,
- * and producers to ~/.claude/producers/ for global access.
+ * producers to ~/.claude/producers/, and agents to ~/.claude/agents/ for global access.
  */
 
 const fs = require('fs');
@@ -77,6 +77,14 @@ const producers = [
   'data-file-writer'
 ];
 
+// Reusable agent definitions (v9.4) — scanned dynamically
+const agentsDir = path.join(__dirname, '..', 'agents');
+const agents = fs.existsSync(agentsDir)
+  ? fs.readdirSync(agentsDir).filter(entry =>
+      entry.endsWith('.md')
+    )
+  : [];
+
 // Main installation logic
 try {
   const homeDir = os.homedir();
@@ -130,6 +138,14 @@ try {
     log(`Created ${claudeProducersDir}`);
   }
 
+  // --- Agents directory (v9.4) ---
+  const claudeAgentsDir = path.join(homeDir, '.claude', 'agents');
+
+  if (!fs.existsSync(claudeAgentsDir)) {
+    fs.mkdirSync(claudeAgentsDir, { recursive: true });
+    log(`Created ${claudeAgentsDir}`);
+  }
+
   // Install each skill
   skills.forEach(skillName => {
     const src = path.join(packageRoot, 'skills', skillName);
@@ -175,6 +191,23 @@ try {
     }
   });
 
+  // Install each agent definition (flat .md files)
+  if (agents.length === 0) {
+    log(`No agent definitions found in ${agentsDir} — skipping agent install`);
+  }
+  agents.forEach(agentFile => {
+    const src = path.join(agentsDir, agentFile);
+    const dest = path.join(claudeAgentsDir, agentFile);
+
+    if (fs.existsSync(src)) {
+      fs.copyFileSync(src, dest);
+      log(`\u2713 Installed ${agentFile} agent to ${dest}`);
+    } else {
+      error(`${agentFile} agent not found at ${src}`);
+      process.exit(1);
+    }
+  });
+
   // Verify installation
   const allSkillsInstalled = skills.every(skillName =>
     fs.existsSync(path.join(claudeSkillsDir, skillName))
@@ -185,8 +218,11 @@ try {
   const allProducersInstalled = producers.every(name =>
     fs.existsSync(path.join(claudeProducersDir, name))
   );
+  const allAgentsInstalled = agents.every(name =>
+    fs.existsSync(path.join(claudeAgentsDir, name))
+  );
 
-  if (allSkillsInstalled && allSpecialistsInstalled && allProducersInstalled) {
+  if (allSkillsInstalled && allSpecialistsInstalled && allProducersInstalled && allAgentsInstalled) {
     log(`\u2713 Installation complete!`);
     log(`Skills are now available globally:`);
     log(`  /intuition-start          - Load project context and detect workflow phase`);
@@ -209,6 +245,8 @@ try {
     specialists.forEach(name => log(`  ${name}`));
     log(`Format producers (${producers.length}):`);
     producers.forEach(name => log(`  ${name}`));
+    log(`Reusable agents (${agents.length}):`);
+    agents.forEach(name => log(`  ${name.replace('.md', '')}`));
     log(`\nYou can now use these skills in any project with Claude Code.`);
   } else {
     error(`Verification failed - not all components properly installed`);

package/scripts/uninstall-skills.js

@@ -1,10 +1,10 @@
 #!/usr/bin/env node
 
 /**
- * Uninstallation script for Intuition skills
+ * Uninstallation script for Intuition skills, agents, specialists, and producers
  *
  * This script is run before `npm uninstall -g @tgoodington/intuition`
- * It removes all Intuition skills from ~/.claude/skills/
+ * It removes all Intuition components from ~/.claude/
  */
 
 const fs = require('fs');
@@ -72,6 +72,23 @@ try {
     }
   });
 
+  // Remove Intuition agent definitions
+  const claudeAgentsDir = path.join(homeDir, '.claude', 'agents');
+  const agentsToRemove = [
+    'intuition-researcher.md',
+    'intuition-code-writer.md',
+    'intuition-reviewer.md',
+    'intuition-synthesizer.md'
+  ];
+
+  agentsToRemove.forEach(agentFile => {
+    const agentDest = path.join(claudeAgentsDir, agentFile);
+    if (fs.existsSync(agentDest)) {
+      fs.rmSync(agentDest, { force: true });
+      log(`\u2713 Removed ${agentFile} agent from ${agentDest}`);
+    }
+  });
+
   // Clean up empty .claude/skills directory if it's empty
   if (fs.existsSync(claudeSkillsDir)) {
     const remaining = fs.readdirSync(claudeSkillsDir);

package/skills/intuition-assemble/SKILL.md

@@ -46,21 +46,25 @@ Scan three tiers in priority order. Deduplicate by `name` — first found wins.
 
 1. Glob `.claude/specialists/*/*.specialist.md` (project-level)
 2. Glob `~/.claude/specialists/*/*.specialist.md` (user-level, expand `~` via Bash)
-3. Determine the Intuition package root: run `node -e "console.log(require.resolve('@tgoodington/intuition/package.json'))"` via Bash, extract the directory. Glob `{package_root}/specialists/*/*.specialist.md`.
+3. Framework-bundled specialists — try in order, stop at first success:
+   a. **Plugin path**: Glob `${CLAUDE_PLUGIN_ROOT}/specialists/*/*.specialist.md`. If `${CLAUDE_PLUGIN_ROOT}` is empty or the glob returns nothing, fall through.
+   b. **npm path**: Run `node -e "console.log(require.resolve('@tgoodington/intuition/package.json'))"` via Bash, extract the directory. Glob `{package_root}/specialists/*/*.specialist.md`.
+   c. **Fallback**: Glob `node_modules/@tgoodington/intuition/specialists/*/*.specialist.md` relative to project root.
 
-For each profile found: read the YAML frontmatter, extract `name` and `domain_tags`. Build a specialists list.
+For each profile found: read ONLY the YAML frontmatter using `Read` with `limit: 30` (frontmatter is typically under 25 lines). Extract `name` and `domain_tags`. Do NOT read the full profile body — the Stage 1/2 protocols are not needed for matching. Build a specialists list.
 
 If zero specialists found after all three tiers, HALT with this message:
 "No specialist profiles found. Install specialist profiles in one of these locations:
 - `.claude/specialists/` (project-level)
 - `~/.claude/specialists/` (user-level)
-- Or ensure `@tgoodington/intuition` is installed with its bundled specialists."
+- Install the Intuition plugin: `/plugin install intuition`
+- Or install via npm: `npm install -g @tgoodington/intuition`"
 
 ### Step 3: Scan Producer Registry
 
-Same three-tier pattern using `producers/` directories and `*.producer.md` files. Extract `name` and `output_formats` from each. Deduplicate by name with same priority (first found wins).
+Same three-tier pattern as Step 2, using `producers/` directories and `*.producer.md` files. Tier 3 uses the same resolution order (plugin path → npm path → fallback). Read ONLY the YAML frontmatter using `Read` with `limit: 30`. Extract `name` and `output_formats` from each. Do NOT read the full profile body. Deduplicate by name with same priority (first found wins).
 
-If zero producers found, HALT with the same pattern message referencing producer directories.
+If zero producers found, HALT with the same pattern message referencing producer directories and install methods.
 
 ### Step 4: Team Assembly (Inline Matching)
 
@@ -128,7 +132,7 @@ If the outline has no format constraints and no Section 3 technology decisions a
 ### Step 5: Prerequisite Checking
 
 For each producer in `producer_assignments`:
-1. Read the full producer profile from the registry
+1. Read the producer profile frontmatter from the registry (the `tooling` field is within the frontmatter, already read in Step 3)
 2. Check `tooling.{output_format}.required` array
 3. For each required tool, run Bash to verify availability (e.g., `python --version`, `which pandoc`)
 4. Record results in `prerequisite_check` (format: `"producer/format": "PASS — tool version found"` or `"FAIL — tool not found"`)
@@ -319,7 +323,7 @@ Set on root: `last_handoff` → current ISO timestamp, `last_handoff_transition`
 
 - **Zero specialists found**: Halt at Step 2 with install instructions.
 - **Zero producers found**: Halt at Step 3 with install instructions.
-- **Package root resolution fails**: Fallback to scanning `node_modules/@tgoodington/intuition/` relative to project root.
+- **Framework-bundled resolution fails**: Tier 3 tries plugin path, then npm resolution, then local node_modules. If all three fail, Tiers 1 and 2 may still have results.
 - **All tasks unmatched**: Present the full unmatched list at Step 6. If user chooses to create specialists, write the request file and route to agent-advisor. Do not silently skip everything.
 - **User rejects team**: Allow adjustments, re-present. Do not write anything until approved.
 - **Prerequisites missing**: Halt with exact install commands. Do not proceed to team confirmation.

package/skills/intuition-build/SKILL.md

@@ -149,8 +149,8 @@ For each task per `team_assignment.json` execution order (parallelize tasks with
    - Project: `.claude/producers/{producer-name}/{producer-name}.producer.md`
    - User: `~/.claude/producers/{producer-name}/{producer-name}.producer.md`
    - Framework-shipped: scan the `producers/` directory at the package root
-4. Construct the delegation prompt using the producer profile as system instructions and the blueprint as task context. Only include non-test output files in the delegation.
-5. Spawn the producer as a Task subagent using the model declared in the producer profile.
+4. Construct the delegation prompt using the producer profile as system instructions. Direct the subagent to READ the blueprint from disk (do NOT inject blueprint content into the prompt — this avoids duplicating large files in both parent and subagent contexts). Only include non-test output files in the delegation.
+5. Spawn the producer as an `intuition-code-writer` agent (or appropriate producer-specific agent if one exists). Use the model declared in the producer profile.
 
 **Producer delegation format:**
 ```
@@ -174,25 +174,27 @@ When building on a branch, add to subagent prompts:
 
 ## STEP 5: THREE-LAYER REVIEW CHAIN
 
-After a producer completes each deliverable, execute all three review layers in sequence.
+After producers complete deliverables, execute all three review layers. **Batch deliverables from the same specialist** into a single review subagent (up to 3 deliverables per review — if a specialist has more than 3, split into multiple batches). This reduces subagent spawn overhead.
 
 ### Layer 1: Domain Specialist Review
 
 1. Identify the specialist that authored the blueprint (from blueprint YAML frontmatter `specialist` field).
-2. Load that specialist's profile from the registry (same scan order as producers: project → user → framework).
-3. Extract the Review Protocol section from the specialist profile body.
-4. Spawn a review subagent with adversarial framing. Use the `reviewer_model` declared in the specialist profile's YAML frontmatter.
+2. Locate that specialist's profile path in the registry (same scan order as producers: project → user → framework).
+3. Spawn an `intuition-reviewer` agent with adversarial framing. Use the `reviewer_model` declared in the specialist profile's YAML frontmatter. If this specialist produced multiple deliverables, include ALL of them (up to 3) in a single review agent.
 
 **Specialist review delegation format:**
 ```
-You are a [specialist display_name] reviewing a deliverable produced from your blueprint. Your job is to FIND PROBLEMS — not to approve.
+You are a [specialist display_name] reviewing deliverables produced from your blueprint. Your job is to FIND PROBLEMS — not to approve.
 
-[Specialist Review Protocol section content]
+Read your review protocol from: [specialist profile path] — find the ## Review Protocol section.
 
 Blueprint: Read {context_path}/blueprints/{specialist-name}.md
-Deliverable: Read [produced output file paths]
+Deliverables: Read each of these files:
+- [produced output file path 1]
+- [produced output file path 2]
+- ...
 
-Does this deliverable accurately capture what the blueprint specified? Are the domain-specific requirements met? Check every review criterion. Return: PASS + summary OR FAIL + specific issues list with blueprint section references.
+For EACH deliverable: does it accurately capture what the blueprint specified? Are the domain-specific requirements met? Check every review criterion. Return per deliverable: PASS + summary OR FAIL + specific issues list with blueprint section references.
 ```
 
 - If FAIL → send feedback back to the producer (re-delegate with specific issues). Do NOT proceed to Layer 2.
@@ -222,14 +224,15 @@ Log all deviations (additions and omissions) in the build report's "Deviations f
 ### Layer 3: Mandatory Cross-Cutting Reviewers
 
 1. Check the specialist profile's `mandatory_reviewers` field in its YAML frontmatter.
-2. For EACH mandatory reviewer listed: load their specialist profile, extract their Review Protocol, spawn a review subagent using their `reviewer_model`.
-3. **Security Expert is ALWAYS mandatory** — even if `mandatory_reviewers` is empty. Spawn a Security Expert review for every deliverable that produces code, configuration, or scripts.
+2. For EACH mandatory reviewer listed: locate their specialist profile, spawn an `intuition-reviewer` agent using their `reviewer_model`.
+3. **Security Expert is ALWAYS mandatory** — even if `mandatory_reviewers` is empty. Spawn a Security Expert `intuition-reviewer` agent for every deliverable that produces code, configuration, or scripts.
+4. **Batch cross-cutting reviews** the same way as Layer 1: include up to 3 deliverables per review agent. If all code deliverables in the current execution phase share the same cross-cutting reviewer, batch them into one review call.
 
 **Cross-cutting review delegation format:**
 ```
 You are a [reviewer display_name] performing a cross-cutting review. Your job is to FIND PROBLEMS in your area of expertise.
 
-[Reviewer's Review Protocol section content]
+Read your review protocol from: [reviewer profile path] — find the ## Review Protocol section.
 
 Deliverable: Read [produced output file paths]
 Blueprint: Read {context_path}/blueprints/{specialist-name}.md (for context only)
@@ -348,7 +351,7 @@ Present a concise version: task count, pass/fail status, files produced count, r
 
 After reporting results:
 
-**8a. Extract to memory.** Spawn a haiku Task subagent: "Read `{context_path}/build_report.md`. Then read `docs/project_notes/key_facts.md`, `docs/project_notes/issues.md`, and `docs/project_notes/bugs.md`. Append only NEW entries: lessons/deviations → `key_facts.md`, completed work → `issues.md`, bugs found → `bugs.md`. Do not duplicate. Preserve existing formatting." Run in background.
+**8a. Extract to memory (inline).** Review the build report you just wrote. For any notable deviations or lessons learned, read `docs/project_notes/key_facts.md` and use Edit to append concise entries (2-3 lines each) if not already present. For any bugs found during review cycles, read `docs/project_notes/bugs.md` and append. Do NOT spawn a subagent — write directly.
 
 **8b. Determine next phase.** Read `{context_path}/team_assignment.json`. Check if any `producer_assignments` entry has `producer == "code-writer"`.
 

package/skills/intuition-debugger/SKILL.md

@@ -191,7 +191,7 @@ Execute the investigation protocol for the classified category. This is NOT a ch
 - Compare against implementation — does code match outline?
 - The answer determines where the fix belongs (code, plan, or discovery).
 
-**For large dependency graphs:** Launch a Research/Explorer subagent (haiku):
+**For large dependency graphs:** Launch an `intuition-researcher` agent:
 ```
 Task: "Map all imports and usages of [module/function] across the codebase.
 Report: file paths, line numbers, how each usage depends on this module.
@@ -259,8 +259,8 @@ Do NOT proceed to Step 8 without explicit user confirmation.
 | Scenario | Action |
 |----------|--------|
 | Trivial (1-3 lines, single file) | Debugger MAY fix directly |
-| Moderate (multiple lines, single file) | Delegate to Code Writer (sonnet) |
-| Complex (multiple files) | Delegate to Code Writer (sonnet) with full causal chain context |
+| Moderate (multiple lines, single file) | Delegate to `intuition-code-writer` agent |
+| Complex (multiple files) | Delegate to `intuition-code-writer` agent with full causal chain context |
 | Cross-context | Delegate with BOTH contexts' implementation guides referenced |
 
 **Subagent prompt template:**
@@ -295,8 +295,8 @@ ALWAYS populate dependent files and interfaces. Never omit context from subagent
 After the subagent returns:
 
 1. **Review the changes** — Read modified files. Confirm the fix addresses the ROOT CAUSE, not just the symptom.
-2. **Run tests** — Launch Test Runner (haiku) if test infrastructure exists.
-3. **Impact check** — Launch Impact Analyst (haiku):
+2. **Run tests** — Launch `intuition-researcher` agent if test infrastructure exists.
+3. **Impact check** — Launch `intuition-researcher` agent:
    ```
    "Read [dependent files]. Verify compatibility with changes to [modified files].
    Report broken imports, changed interfaces, or behavioral mismatches. Under 400 words."
@@ -365,12 +365,10 @@ After reporting (and optional git commit), ask: "Is there another issue to inves
 
 # SUBAGENT TABLE
 
-| Agent | Model | When to Use |
-|-------|-------|-------------|
-| **Code Writer** | sonnet | Implementing fixes — moderate to complex changes |
-| **Research/Explorer** | haiku | Mapping dependencies, cross-context analysis, profiling setup |
-| **Test Runner** | haiku | Running tests after fixes to verify correctness |
-| **Impact Analyst** | haiku | Verifying dependent code is compatible after changes |
+| Agent | Definition | When to Use |
+|-------|-----------|-------------|
+| `intuition-code-writer` | sonnet, acceptEdits | Implementing fixes — moderate to complex changes |
+| `intuition-researcher` | haiku, dontAsk | Mapping dependencies, cross-context analysis, test running, impact analysis |
 
 ---
 

package/skills/intuition-design/SKILL.md

@@ -125,10 +125,10 @@ From the design brief, extract:
 
 Create the directory `{context_path}/.design_research/[item_name]/` if it does not exist.
 
-**Agent 1 — Existing Work Scan** (subagent_type: Explore, model: haiku):
+**Agent 1 — Existing Work Scan** (subagent_type: `intuition-researcher`):
 Prompt: "Search the project for existing work related to [item description]. Look for: prior documentation, existing implementations, reference material, patterns that inform this design. Check docs/, src/, and any relevant directories. Report findings in under 400 words. Facts only."
 
-**Agent 2 — Context Mapping** (subagent_type: Explore, model: haiku):
+**Agent 2 — Context Mapping** (subagent_type: `intuition-researcher`):
 Prompt: "Map the context surrounding [item description]. What already exists that this design must work with or within? What are the boundaries and integration points? Check the codebase structure, existing docs, and configuration. Report in under 400 words. Facts only."
 
 When both return, combine results and write to `{context_path}/.design_research/[item_name]/context.md`.
@@ -156,7 +156,7 @@ Domain-adaptive focus questions:
 
 Each turn: 2-4 sentences of analysis referencing research findings, then ONE question via AskUserQuestion with 2-4 options.
 
-**Research triggers:** If an element definition requires investigating existing patterns or prior art, launch a targeted haiku agent. WAIT for results before continuing the dialogue.
+**Research triggers:** If an element definition requires investigating existing patterns or prior art, launch a targeted `intuition-researcher` agent. WAIT for results before continuing the dialogue.
 
 # PHASE 3: CONNECTIONS (1-2 turns) [ECD: C]
 
@@ -184,7 +184,7 @@ Domain-adaptive focus questions:
 
 This phase gets the most turns because dynamics design often reveals new elements or connection needs. If a gap appears, loop back briefly to address it.
 
-**Research triggers:** For complex design questions requiring deeper analysis, launch a sonnet agent (subagent_type: general-purpose, model: sonnet) for trade-off analysis. Limit: 1 at a time, 600-word responses. WAIT for results before continuing the dialogue.
+**Research triggers:** For complex design questions requiring deeper analysis, launch an `intuition-researcher` agent (model override: sonnet) for trade-off analysis. Limit: 1 at a time, 600-word responses. WAIT for results before continuing the dialogue.
 
 # PHASE 5: FORMALIZATION (1 turn)
 
@@ -354,12 +354,12 @@ Working files in `.design_research/` enable resuming interrupted design sessions
 
 ## Context Research (launched in Phase 1)
 
-Launch 2 haiku Explore agents in parallel via Task tool. See Phase 1, Step 2 for prompt templates. Write combined results to `.design_research/[item_name]/context.md`.
+Launch 2 `intuition-researcher` agents in parallel via Task tool. See Phase 1, Step 2 for prompt templates. Write combined results to `.design_research/[item_name]/context.md`.
 
 ## Targeted Research (launched on demand in Phases 2-4)
 
-- Use haiku Explore agents for fact-gathering (e.g., "What patterns exist in the project for this kind of thing?")
-- Use sonnet general-purpose agents for trade-off analysis (e.g., "Compare approach X and Y given the existing context")
+- Use `intuition-researcher` agents for fact-gathering (e.g., "What patterns exist in the project for this kind of thing?")
+- Use `intuition-researcher` agents (model override: sonnet) for trade-off analysis (e.g., "Compare approach X and Y given the existing context")
 - Each prompt MUST specify the design question and a 400-word limit (600 for sonnet)
 - Write results to `.design_research/[item_name]/options_[topic].md`
 - NEVER launch more than 2 agents simultaneously

package/skills/intuition-detail/SKILL.md

@@ -93,7 +93,7 @@ Ensure the `{context_path}/scratch/` directory exists (create via Bash `mkdir -p
 
 ### Light Tasks (single-pass bypass)
 
-Spawn an opus Task subagent that combines exploration AND specification in one pass:
+Spawn an `intuition-synthesizer` agent that combines exploration AND specification in one pass:
 - **System prompt**: Stage 1 Protocol text + Stage 2 Protocol text (concatenated with a separator)
 - **Task context**: plan tasks, research patterns from profile frontmatter, prior blueprints, outline Section 10 context
 - **Output instruction**: "Research the project, then produce the complete blueprint directly. No user gate — use your best judgment for all decisions. Write to `{context_path}/blueprints/{specialist-name}.md`."
@@ -104,7 +104,7 @@ Ensure the `{context_path}/blueprints/` directory exists. After the subagent ret
 
 #### Stage 1a: Research Planning
 
-Spawn an opus Task subagent. The system prompt combines a research-planning framing (owned by this skill) with the specialist's domain expertise (from the profile):
+Spawn an `intuition-synthesizer` agent (model override: sonnet). The system prompt combines a research-planning framing (owned by this skill) with the specialist's domain expertise (from the profile):
 
 - **System prompt**: Construct by concatenating:
   1. **Framing (detail skill provides this):**
@@ -148,7 +148,7 @@ After 1a returns, write the specialist's research plan output to `{context_path}
 
 Parse the specialist's research plan output. Enforce the depth-based research cap: Deep tasks allow 3 entries max, Standard tasks allow 2. If the specialist's plan contains more entries than the cap, take ONLY the first {cap} entries and log a warning to the user: "Research plan had {N} items, capped at {cap} per depth policy."
 
-For each `### R{N}:` entry (up to the cap), spawn a haiku Task subagent (subagent_type: `Explore`):
+For each `### R{N}:` entry (up to the cap), spawn an `intuition-researcher` agent:
 - **Task**: the natural language description from the research plan entry
 - **Instruction suffix**: "Search the project codebase thoroughly. Report: file paths found, key patterns observed, relevant code snippets, and any constraints or conventions discovered. Be specific — include exact paths, field names, and data types."
 
@@ -159,7 +159,7 @@ If any research agent finds nothing relevant, note this — the specialist needs
 #### Stage 1c: Analysis and Synthesis (Resume 1a or Fresh)
 
 **Normal flow:** Resume the Stage 1a specialist subagent using the saved agent ID.
-**Crash recovery flow (no agent ID):** Spawn a fresh opus Task subagent. Provide the specialist's Stage 1 Exploration Protocol as system prompt, and include the saved research plan from `{context_path}/scratch/{specialist-name}-research-plan.md` as additional context so the fresh agent understands what was asked for.
+**Crash recovery flow (no agent ID):** Spawn a fresh `intuition-synthesizer` agent. Provide the specialist's Stage 1 Exploration Protocol as system prompt, and include the saved research plan from `{context_path}/scratch/{specialist-name}-research-plan.md` as additional context so the fresh agent understands what was asked for.
 
 In either case, provide this prompt (the synthesis framing is owned by this skill, not the specialist):
 
@@ -335,14 +335,16 @@ Mark these decisions with `"classified_by": "detail"` in decisions.json.
 
 ## STEP 7: STAGE 2 — SPECIFICATION SUBAGENT
 
-Spawn a FRESH opus Task subagent (do NOT resume Stage 1):
+Spawn a FRESH `intuition-synthesizer` agent (do NOT resume Stage 1):
 - **System prompt**: the specialist's Stage 2 Specification Protocol text (extracted in Step 3)
 - **Injected context**:
   - Full contents of `{context_path}/scratch/{specialist-name}-stage1.md`
   - Full contents of `{context_path}/scratch/{specialist-name}-decisions.json`
   - Plan tasks with acceptance criteria
   - Prior blueprint contents (if any — read each path and include full text)
-- **Output instruction**: "Produce the complete blueprint in the universal envelope format (9 sections: Task Reference, Research Findings, Approach, Decisions Made, Deliverable Specification, Acceptance Mapping, Integration Points, Open Items, Producer Handoff). Write to `{context_path}/blueprints/{specialist-name}.md`. Every design choice must trace to Stage 1 research, a user decision from decisions.json, or a named domain standard. Ungrounded choices go in the Open Items section."
+- **Output instruction**: "Produce the complete blueprint in the universal envelope format (9 sections: Task Reference, Research Findings, Approach, Decisions Made, Deliverable Specification, Acceptance Mapping, Integration Points, Open Items, Producer Handoff). Write to `{context_path}/blueprints/{specialist-name}.md`. Every design choice must trace to Stage 1 research, a user decision from decisions.json, or a named domain standard. Ungrounded choices go in the Open Items section.
+
+     IMPORTANT — Testing boundary: Do NOT specify test files or test deliverables in Producer Handoff (Section 9). Testing is handled by a dedicated test phase, not by producers. If you have domain-specific testing knowledge (edge cases, critical paths, failure modes, boundary conditions), include it in the Approach section (Section 3) under a '### Testability Notes' subheading. This gives the test phase domain context without prescribing test files."
 
 Ensure the `{context_path}/blueprints/` directory exists (create via Bash `mkdir -p` if needed).
 
@@ -370,7 +372,9 @@ After a blueprint passes the traceability check:
 
 **8b. Update specialist state.** Read `.project-memory-state.json`. In `workflow.detail.specialists`, mark the completed specialist: `status → "completed"`, `stage → "done"`, `blueprint_path → "{context_path}/blueprints/{specialist-name}.md"`. Write back.
 
-**8c. Extract to memory.** Spawn a haiku Task subagent: "Read `{context_path}/blueprints/{specialist-name}.md`. Then read `docs/project_notes/decisions.md` and `docs/project_notes/key_facts.md`. Append only NEW entries: decisions from the blueprint's Decisions Made section → `decisions.md` as ADRs, domain facts from Research Findings → `key_facts.md`. Do not duplicate. Preserve existing formatting." Run in background.
+**8c. Extract to memory (inline).** Read the just-written blueprint's Decisions Made section (Section 4). For each decision, read `docs/project_notes/decisions.md` and use Edit to append a new ADR entry if one doesn't already exist. For key domain facts from the blueprint's Research Findings (Section 2), read `docs/project_notes/key_facts.md` and append if not present. Keep entries concise (2-3 lines each). Do NOT spawn a subagent — write directly.
+
+**8c-ii. Extract testability notes.** If the blueprint's Approach section (Section 3) contains a `### Testability Notes` subheading, extract its contents and append to `{context_path}/test_advisory.md` (create if it doesn't exist). Format: `## {Specialist Display Name}\n{testability notes content}\n`. This gives the test phase a compact file instead of needing to read all blueprints.
 
 **8d. Check for next specialist.** Read `{context_path}/team_assignment.json`. Read current state.
 
@@ -398,11 +402,11 @@ If the COMPLETED specialist was Deep depth, recommend: "Context is heavy — con
 
 Triggers when Step 8d finds no remaining specialists.
 
-**9a. Conflict detection.** Spawn a haiku Task subagent: "Read all blueprint files in `{context_path}/blueprints/`. Compare for: contradictory decisions, overlapping file modifications with conflicting changes, inconsistent interface assumptions, and duplicated work. Write findings to `{context_path}/blueprint-conflicts.md`. If no conflicts, write 'No conflicts detected.'" Wait for completion. If conflicts found, present to user via AskUserQuestion and resolve before continuing.
+**9a. Conflict detection.** Spawn an `intuition-researcher` agent: "Read all blueprint files in `{context_path}/blueprints/`. Compare for: contradictory decisions, overlapping file modifications with conflicting changes, inconsistent interface assumptions, and duplicated work. Write findings to `{context_path}/blueprint-conflicts.md`. If no conflicts, write 'No conflicts detected.'" Wait for completion. If conflicts found, present to user via AskUserQuestion and resolve before continuing.
 
 **9b. Vision review.** Skip this step if only 1 specialist completed (no cross-specialist seams to check).
 
-For multi-specialist projects, spawn a sonnet Task subagent:
+For multi-specialist projects, spawn an `intuition-reviewer` agent:
 
 "Read these files:
 1. `{context_path}/prompt_brief.md` — extract Commander's Intent (desired end state, non-negotiables, boundaries) and Success Criteria

package/skills/intuition-engineer/SKILL.md

@@ -101,7 +101,7 @@ Options:
 
 ## STEP 2: FAN-OUT RESEARCH
 
-For each task (or group of related tasks), launch a haiku research subagent via the Task tool (subagent_type: Explore, model: haiku).
+For each task (or group of related tasks), launch an `intuition-researcher` agent via the Task tool.
 
 When constructing each prompt, replace bracketed placeholders with actual values from the outline. If the task has known file paths, use the "Known Files" variant. If files are marked TBD, use the "TBD Files" variant.
 

package/skills/intuition-outline/SKILL.md

@@ -97,9 +97,11 @@ From the prompt brief, extract: core problem, success criteria, stakeholders, co
 
 Create the directory `{context_path}/.outline_research/` if it does not exist.
 
-Launch 2 sonnet research agents in parallel using the Task tool:
+**Resume check:** If `{context_path}/.outline_research/orientation.md` already exists AND `{context_path}/.outline_research/decisions_log.md` exists with at least one entry, skip the research agents — read the existing orientation.md and proceed to Step 3. This avoids re-spending tokens on research that hasn't changed.
 
-**Agent 1 — Codebase Topology** (subagent_type: Explore, model: sonnet):
+Launch 2 `intuition-researcher` agents in parallel using the Task tool (both calls in a single response):
+
+**Agent 1 — Codebase Topology** (subagent_type: `intuition-researcher`):
 Prompt:
 "The project root is the current working directory. Analyze the codebase structure by following these steps in order:
 
@@ -122,7 +124,7 @@ Report on:
 
 Under 500 words. Facts only, no speculation."
 
-**Agent 2 — Pattern Extraction** (subagent_type: Explore, model: sonnet):
+**Agent 2 — Pattern Extraction** (subagent_type: `intuition-researcher`):
 Prompt:
 "The project root is the current working directory. Analyze codebase patterns by following these steps:
 
@@ -154,7 +156,7 @@ When `active_context` is NOT trunk:
 3. Read parent's outline.md and any design specs at `{parent_path}/design_spec_*.md`.
 4. Launch a THIRD orientation research agent alongside the existing two:
 
-**Agent 3 — Parent Intersection Analysis** (subagent_type: Explore, model: sonnet):
+**Agent 3 — Parent Intersection Analysis** (subagent_type: `intuition-researcher`):
 Prompt:
 "The project root is the current working directory. Compare two workflow artifacts:
 
@@ -201,7 +203,7 @@ When actors are sufficiently mapped (user has confirmed or adjusted), transition
 Based on the scope revealed by the prompt brief and actors discussion, recommend a outline depth tier:
 
 - **Lightweight** (1-4 tasks): Focused scope, few unknowns. Outline includes: Objective, Discovery Summary, Task Sequence, Execution Notes.
-- **Standard** (5-10 tasks): Moderate complexity. Adds: Technology Decisions, Testing Strategy, Risks & Mitigations.
+- **Standard** (5-10 tasks): Moderate complexity. Adds: Technology Decisions, Risks & Mitigations.
 - **Comprehensive** (10+ tasks): Broad scope, multiple components. All sections including Component Architecture and Interface Contracts.
 
 Present your recommendation with reasoning via AskUserQuestion. Options: the three tiers (with your recommendation marked). The user may agree or pick a different tier.
@@ -255,8 +257,8 @@ For each major decision domain identified from the prompt brief, orientation res
 
 1. **Identify** the decision needed. State it clearly.
 2. **Research** (when needed): Launch 1-2 targeted research agents via Task tool.
-   - Use haiku (subagent_type: Explore) for straightforward fact-gathering.
-   - Use sonnet (subagent_type: general-purpose) for trade-off analysis against the existing codebase.
+   - Use `intuition-researcher` for straightforward fact-gathering.
+   - Use `intuition-researcher` (model override: sonnet) for trade-off analysis against the existing codebase.
    - Each agent prompt MUST reference the specific decision domain, return under 400 words.
    - Write results to `{context_path}/.outline_research/decision_[domain].md` (snake_case).
    - NEVER launch more than 2 agents simultaneously.
@@ -354,7 +356,7 @@ After writing `outline.md`:
 
 **1. Update state:** Read `.project-memory-state.json`. Target the active context object (trunk or branch). Set: `status` → `"outline"`, `workflow.outline.completed` → `true`, `workflow.outline.completed_at` → current ISO timestamp, `workflow.outline.approved` → `true`. Set on root: `last_handoff` → current ISO timestamp, `last_handoff_transition` → `"outline_complete"`. Write back.
 
-**2. Extract to memory:** Spawn a haiku Task subagent (subagent_type: Explore): "Read `{context_path}/outline.md` and `{context_path}/.outline_research/decisions_log.md`. Then read `docs/project_notes/decisions.md` and `docs/project_notes/issues.md`. Append only NEW entries: architectural decisions → `decisions.md` as ADRs, risks and dependencies → `issues.md`. Do not duplicate existing entries. Preserve existing formatting." Run in background — do not wait for completion.
+**2. Extract to memory (inline).** Read `{context_path}/.outline_research/decisions_log.md`. For each locked decision, read `docs/project_notes/decisions.md` and use Edit to append a new ADR entry if one doesn't already exist for that decision. For each risk identified during dialogue, read `docs/project_notes/issues.md` and use Edit to append if not already present. Keep entries concise (2-3 lines each). Do NOT spawn a subagent for this — write directly.
 
 **3. Fast Track Assessment (v9 only):**
 
@@ -405,8 +407,8 @@ If fast track declined OR conditions not met, continue to step 4.
 ## Scope Scaling
 
 - **Lightweight**: Sections 1, 2, 6, 6.5, 10
-- **Standard**: Sections 1, 2, 3, 6, 6.5, 7, 8, 10
-- **Comprehensive**: All sections (1-10, including 6.5)
+- **Standard**: Sections 1, 2, 3, 6, 6.5, 8, 10
+- **Comprehensive**: All sections (1-6.5, 8-10)
 
 Section 6.5 (Detail Assessment) is ALWAYS included regardless of tier.
 Section 2.5 is Parent Context — included for ALL tiers when on a branch.
@@ -482,8 +484,7 @@ Depth controls specialist invocation:
 
 **Acceptance criteria rule:** If a criterion can only be satisfied ONE way, it is over-specified. Criteria describe outcomes ("users can reset passwords via email"), not implementations ("add a resetPassword() method that calls sendEmail()"). The engineer and build phases decide the code-level HOW.
 
-### 7. Testing Strategy (Standard+, when code is produced)
-Test types required. Which tasks need tests (reference task numbers). Critical test scenarios. Infrastructure needed.
+**No test tasks.** Do NOT create tasks for writing tests (e.g., "Write unit tests for the API layer"). Testing is a dedicated phase (`/intuition-test`), not a task. The test phase discovers infrastructure, designs strategy, and creates tests independently. Outline tasks describe what gets built — verification is the test phase's job.
 
 ### 8. Risks & Mitigations (Standard+)
 
@@ -605,14 +606,14 @@ If any check fails, fix it before presenting.
 
 ## Tier 1: Orientation (launched in Phase 1)
 
-Launch 2 sonnet Explore agents in parallel via Task tool. See Phase 1, Step 2 for prompt templates. Write combined results to `{context_path}/.outline_research/orientation.md`.
+Launch 2 `intuition-researcher` agents in parallel via Task tool. See Phase 1, Step 2 for prompt templates. Write combined results to `{context_path}/.outline_research/orientation.md`.
 
 ## Tier 2: Decision Research (launched on demand in Phase 3)
 
 Launch 1-2 agents per decision domain when dialogue reveals unknowns needing investigation.
 
-- Use haiku Explore agents for fact-gathering (e.g., "What testing framework does this project use?").
-- Use sonnet general-purpose agents for trade-off analysis (e.g., "Compare approaches X and Y given the current architecture").
+- Use `intuition-researcher` agents for fact-gathering (e.g., "What testing framework does this project use?").
+- Use `intuition-researcher` agents (model override: sonnet) for trade-off analysis (e.g., "Compare approaches X and Y given the current architecture").
 - Each prompt MUST specify the decision domain and a 400-word limit.
 - Reference specific files or directories when possible.
 - Write results to `{context_path}/.outline_research/decision_[domain].md`.

package/skills/intuition-prompt/SKILL.md

@@ -327,12 +327,11 @@ You do NOT launch research subagents by default. Research fires ONLY in this sce
 - "Are there compliance requirements for Z?"
 - "What do other teams typically use for this?"
 
-**Action:** Launch ONE targeted Task call:
+**Action:** Launch ONE targeted `intuition-researcher` agent:
 
 ```
 Description: "Research [specific question]"
-Subagent type: Explore
-Model: haiku
+Subagent type: intuition-researcher
 Prompt: "Research [specific question from the user].
 Context: [what the user is building].
 Search the web and local codebase for relevant information.

package/skills/intuition-test/SKILL.md

@@ -24,6 +24,7 @@ These are non-negotiable. Violating any of these means the protocol has failed.
 8. You MUST write `{context_path}/test_report.md` before routing to handoff.
 9. You MUST run the Exit Protocol after writing the test report. NEVER route to `/intuition-handoff`.
 10. You MUST update `.project-memory-state.json` as part of the Exit Protocol.
+11. You MUST NOT use `run_in_background` for subagents in Steps 2 and 5. All research and test-creation agents MUST complete before their next step begins.
 
 ## CONTEXT PATH RESOLUTION
 
@@ -39,7 +40,7 @@ On startup, before reading any files:
 
 ```
 Step 1: Read context (state, build_report, blueprints, decisions, outline)
-Step 2: Analyze test infrastructure (2 parallel haiku Explore agents)
+Step 2: Analyze test infrastructure (2 parallel intuition-researcher agents)
 Step 3: Design test strategy (self-contained domain reasoning)
 Step 4: Confirm test plan with user
 Step 5: Create tests (delegate to sonnet code-writer subagents)
@@ -63,11 +64,11 @@ Check for existing artifacts before starting. Use `{context_path}/scratch/test_s
 Read these files:
 
 1. `{context_path}/build_report.md` — REQUIRED. Extract: files modified, task results, deviations from blueprints, decision compliance notes.
-3. `{context_path}/outline.md` — acceptance criteria per task.
-4. ALL files matching `{context_path}/blueprints/*.md` — specialist blueprints with deliverable specifications.
-5. `{context_path}/team_assignment.json` — producer assignments (identify code-writer tasks).
-6. ALL files matching `{context_path}/scratch/*-decisions.json` — decision tiers and chosen options per specialist.
-7. `docs/project_notes/decisions.md` — project-level ADRs.
+2. `{context_path}/outline.md` — acceptance criteria per task.
+3. `{context_path}/test_advisory.md` — compact testability notes extracted by the detail phase (one section per specialist). Read this INSTEAD of all blueprints. If this file does not exist (older workflows), fall back to reading `{context_path}/blueprints/*.md` and extracting Testability Notes from each Approach section.
+4. `{context_path}/team_assignment.json` — producer assignments (identify code-writer tasks).
+5. ALL files matching `{context_path}/scratch/*-decisions.json` — decision tiers and chosen options per specialist.
+6. `docs/project_notes/decisions.md` — project-level ADRs.
 
 From build_report.md, extract:
 - **Files modified** — the scope boundary for testing and fixes
@@ -76,19 +77,18 @@ From build_report.md, extract:
 - **Decision compliance** — any flagged decision issues
 - **Test Deliverables Deferred** — test specs/files that specialists recommended but build skipped (if this section exists)
 
-From blueprints, extract any test recommendations:
-- Test cases specialists suggested in their blueprints
-- Edge cases or coverage areas they flagged
-- Test-related deliverables from Producer Handoff sections
+From test_advisory.md (or blueprints as fallback), extract domain test knowledge:
+- Edge cases, critical paths, failure modes, and boundary conditions flagged by specialists
+- Any test-relevant domain insights
 
 From decisions files, build a decision index:
 - Map each `[USER]` decision to its chosen option
 - Map each `[SPEC]` decision to its chosen option and rationale
 - This index is used in Step 6 for fix boundary checking
 
-## STEP 2: RESEARCH (2 Parallel Haiku Explore Agents)
+## STEP 2: RESEARCH (2 Parallel Research Agents)
 
-Spawn two haiku Explore agents in parallel (both Task calls in a single response):
+Spawn two `intuition-researcher` agents in parallel (both Task calls in a single response). Do NOT use `run_in_background` — you MUST wait for both agents to return before proceeding to Step 3:
 
 **Agent 1 — Test Infrastructure:**
 "Search the project for test infrastructure. Find: test framework and runner (jest, vitest, mocha, pytest, etc.), test configuration files, existing test directories and naming conventions, mock/fixture patterns, test utility helpers, CI test commands, coverage configuration and thresholds. Report exact paths and configuration values."
@@ -157,11 +157,11 @@ Tests that only exercise isolated helper functions satisfy unit coverage but do
 
 ### Specialist Test Recommendations
 
-Before finalizing the test plan, review specialist test recommendations from two sources:
-- **Blueprint test recommendations**: Test cases, edge cases, and coverage areas that specialists flagged in their blueprints
-- **Deferred test deliverables**: Test specs/files from build_report.md's "Test Deliverables Deferred" section (and/or test_brief.md's "Specialist Test Recommendations" section)
+Before finalizing the test plan, review specialist domain knowledge from blueprints:
+- **Testability Notes**: Edge cases, critical paths, failure modes, and boundary conditions from each blueprint's Approach section (Section 3, `### Testability Notes` subheading)
+- **Deferred test deliverables**: Any test specs from build_report.md's "Test Deliverables Deferred" section (legacy — older blueprints may still include test files in Producer Handoff)
 
-Specialists have domain expertise about what should be tested. Incorporate relevant recommendations into your test plan, but you are not bound to follow them exactly. You own the test strategy — use specialist input as advisory, not prescriptive.
+Specialists have domain expertise about what should be tested. Incorporate their testability insights into your test plan, but you own the test strategy — use specialist input as advisory, not prescriptive.
 
 ### Output
 
@@ -203,9 +203,9 @@ Options:
 
 ## STEP 5: CREATE TESTS
 
-Delegate test creation to sonnet Task subagents. Parallelize independent test files (multiple Task calls in a single response).
+Delegate test creation to `intuition-code-writer` agents. Parallelize independent test files (multiple Task calls in a single response). Do NOT use `run_in_background` — you MUST wait for ALL subagents to return before proceeding to Step 6.
 
-For each test file, spawn a sonnet subagent:
+For each test file, spawn an `intuition-code-writer` agent:
 
 ```
 You are a test writer. Create a test file following these specifications exactly.
@@ -224,7 +224,7 @@ You are a test writer. Create a test file following these specifications exactly
 Write the complete test file to the specified path. Follow the project's existing test style exactly. Do NOT add test infrastructure (no new packages, no config changes).
 ```
 
-After all subagents return, verify each test file was written. If any failed, retry once with error context.
+SYNCHRONIZATION GATE: After all subagents return, verify each test file exists on disk using Glob. If any file is missing, retry that subagent once (foreground) with error context. Do NOT proceed to Step 6 until every planned test file is confirmed on disk.
 
 ## STEP 6: RUN TESTS + FIX CYCLE
 
@@ -244,9 +244,9 @@ For each failure, classify:
 
 | Classification | Action |
 |---|---|
-| **Test bug** (wrong assertion, incorrect mock, import error) | Fix autonomously — haiku Task subagent |
-| **Implementation bug, trivial** (off-by-one, missing null check, typo — 1-3 lines) | Fix directly — haiku Task subagent |
-| **Implementation bug, moderate** (logic error, missing handler — contained to one file) | Fix — sonnet Task subagent with full diagnosis |
+| **Test bug** (wrong assertion, incorrect mock, import error) | Fix autonomously — `intuition-code-writer` agent |
+| **Implementation bug, trivial** (off-by-one, missing null check, typo — 1-3 lines) | Fix directly — `intuition-code-writer` agent |
+| **Implementation bug, moderate** (logic error, missing handler — contained to one file) | Fix — `intuition-code-writer` agent with full diagnosis |
 | **Implementation bug, complex** (multi-file structural issue) | Escalate to user |
 | **Fix would violate [USER] decision** | STOP — escalate to user immediately |
 | **Fix would violate [SPEC] decision** | Note the conflict, proceed with fix (specialist had authority) |
@@ -327,7 +327,7 @@ Write `{context_path}/test_report.md`:
 
 ## STEP 8: EXIT PROTOCOL
 
-**8a. Extract to memory.** Spawn a haiku Task subagent: "Read `{context_path}/test_report.md`. Then read `docs/project_notes/key_facts.md`, `docs/project_notes/issues.md`, and `docs/project_notes/bugs.md`. Append only NEW entries: test coverage insights → `key_facts.md`, implementation fixes → `bugs.md`, escalated issues → `issues.md`. Do not duplicate. Preserve existing formatting." Run in background.
+**8a. Extract to memory (inline).** Review the test report you just wrote. For test coverage insights, read `docs/project_notes/key_facts.md` and use Edit to append concise entries (2-3 lines each) if not already present. For implementation fixes applied, read `docs/project_notes/bugs.md` and append. For escalated issues, read `docs/project_notes/issues.md` and append. Do NOT spawn a subagent — write directly.
 
 **8b. Update state.** Read `.project-memory-state.json`. Target active context. Set: `status` → `"complete"`, `workflow.test.completed` → `true`, `workflow.test.completed_at` → current ISO timestamp, `workflow.build.completed` → `true`, `workflow.build.completed_at` → current ISO timestamp (if not already set). Set on root: `last_handoff` → current ISO timestamp, `last_handoff_transition` → `"test_to_complete"`. Write back.