@tgoodington/intuition 7.0.0 → 8.0.0

package/skills/intuition-handoff/SKILL.md

@@ -2,8 +2,8 @@
 name: intuition-handoff
 description: Universal phase transition orchestrator. Processes phase outputs, updates project memory, generates fresh briefs for next agent. Manages the design loop for multi-item design cycles.
 model: haiku
-tools: Read, Write, Glob, Grep, AskUserQuestion
-allowed-tools: Read, Write, Glob, Grep
+tools: Read, Write, Glob, Grep, AskUserQuestion, Bash
+allowed-tools: Read, Write, Glob, Grep, Bash
 ---
 
 # Handoff - Phase Transition Orchestrator Protocol
@@ -23,8 +23,8 @@ These are non-negotiable. Violating any of these means the protocol has failed.
 7. You MUST NOT evaluate or critique phase outputs. Process and document, never judge.
 8. You MUST NOT skip the user profile merge step during prompt→planning transitions.
 9. You MUST suggest the correct next skill after completing the transition.
-10. You MUST NOT modify discovery_brief.md, plan.md, design_spec_*.md, or other phase output files — they are read-only inputs.
-11. You MUST manage the design loop: track which items are designed, route to next item or to execute when all are done.
+10. You MUST NOT modify discovery_brief.md, plan.md, design_spec_*.md, code_specs.md, or other phase output files — they are read-only inputs.
+11. You MUST manage the design loop: track which items are designed, route to next item or to engineer when all are done.
 
 ## CONTEXT PATH RESOLUTION
 
@@ -62,42 +62,47 @@ After resolving context_path and context_workflow, determine:
 ```
 IF context_workflow.status == "prompt" AND workflow.prompt.completed == true
    AND workflow.planning.started == false:
-   → TRANSITION: Prompt → Planning
+   → TRANSITION: Prompt → Planning (Transition 1)
 
 IF context_workflow.status == "planning" AND workflow.planning.completed == true
-   AND workflow.design.started == false:
-   → TRANSITION: Planning → Design (initial setup)
+   AND workflow.design.started == false AND workflow.engineering.started == false:
+   → TRANSITION: Planning → Design (Transition 2) OR Planning → Engineer (Transition 2B)
 
 IF context_workflow.status == "design":
    → Check workflow.design.items array
    → IF current item just completed AND more items remain:
-      → TRANSITION: Design → Design (next item)
+      → TRANSITION: Design → Design (Transition 3)
    → IF all items completed:
-      → TRANSITION: Design → Execution
+      → TRANSITION: Design → Engineer (Transition 4)
 
-IF context_workflow.status == "executing" AND workflow.execution.completed == true:
-   → TRANSITION: Execution → Complete
+IF context_workflow.status == "engineering" AND workflow.engineering.completed == true
+   AND workflow.build.started == false:
+   → TRANSITION: Engineer → Build (Transition 5)
+
+IF context_workflow.status == "building" AND workflow.build.completed == true:
+   → TRANSITION: Build → Complete (Transition 6)
 
 IF no clear transition detected:
    → ASK USER: "Which phase just completed?" (use AskUserQuestion)
 ```
 
-## STATE SCHEMA (v4.0)
+## STATE SCHEMA (v5.0)
 
 This is the authoritative schema for `.project-memory-state.json`:
 
 ```json
 {
   "initialized": true,
-  "version": "4.0",
+  "version": "5.0",
   "active_context": "trunk",
   "trunk": {
-    "status": "none | prompt | planning | design | executing | complete",
+    "status": "none | prompt | planning | design | engineering | building | complete",
     "workflow": {
       "prompt": { "started": false, "completed": false, "started_at": null, "completed_at": null, "output_files": [] },
       "planning": { "started": false, "completed": false, "completed_at": null, "approved": false },
       "design": { "started": false, "completed": false, "completed_at": null, "items": [], "current_item": null },
-      "execution": { "started": false, "completed": false, "completed_at": null }
+      "engineering": { "started": false, "completed": false, "completed_at": null },
+      "build": { "started": false, "completed": false, "completed_at": null }
     }
   },
   "branches": {},
@@ -108,7 +113,7 @@ This is the authoritative schema for `.project-memory-state.json`:
 
 ### Branch Entry Schema
 
-Each branch in `branches` has: `display_name`, `created_from`, `created_at`, `purpose`, `status`, and a `workflow` object identical to trunk's workflow structure.
+Each branch in `branches` has: `display_name`, `created_from`, `created_at`, `purpose`, `status`, and a `workflow` object identical to trunk's workflow structure (including `engineering` and `build` phases).
 
 ### Design Items Schema
 
@@ -141,11 +146,30 @@ Triggered when start routes to handoff with branch creation intent. User has pro
    - `created_at`: ISO timestamp
    - `purpose`: user-provided sentence
    - `status`: "none"
-   - `workflow`: identical structure to trunk's workflow (all false/null/empty)
+   - `workflow`: identical structure to trunk's workflow (all false/null/empty — including `engineering` and `build` phases)
 4. **Set `active_context`** to the new branch key.
 5. **Write updated state**. Set `last_handoff_transition` to "branch_creation".
 6. **Route user**: "Branch **[display_name]** created. Run `/intuition-prompt` to define what this branch will accomplish."
 
+## V4 STATE MIGRATION
+
+Fires automatically when handoff detects a v4.0 state before processing any transition.
+
+### Detection
+
+`version == "4.0"` OR (state has `execution` phase in workflow but no `engineering` phase).
+
+### Migration Steps
+
+1. For trunk and every branch, transform the workflow object:
+   - Rename `execution` → `build` (preserve all field values)
+   - Add `engineering: { "started": false, "completed": false, "completed_at": null }` before `build`
+   - If a context has `status == "executing"`, change to `status = "building"`
+2. Set `version: "5.0"`
+3. Preserve all other fields unchanged.
+4. Write updated state.
+5. Report to user: "Migrated state from v4.0 to v5.0 (added engineering phase, renamed execution → build)." Then continue with the original transition.
+
 ## V3 STATE MIGRATION
 
 Fires automatically when handoff detects a v3.0 state before processing any transition.
@@ -166,10 +190,11 @@ Fires automatically when handoff detects a v3.0 state before processing any tran
    - Wrap existing `status` and `workflow` into a `trunk` object
    - Add `active_context: "trunk"`
    - Add `branches: {}`
-   - Set `version: "4.0"`
+   - Transform workflow: rename `execution` → `build`, add `engineering` phase
+   - Set `version: "5.0"`
    - Preserve all other top-level fields (`initialized`, `last_handoff`, `last_handoff_transition`)
 4. Write updated state.
-5. Report to user: list which files were migrated and confirm v4.0 upgrade. Then continue with the original transition.
+5. Report to user: list which files were migrated and confirm v5.0 upgrade. Then continue with the original transition.
 
 Leave shared files (`key_facts.md`, `decisions.md`, `issues.md`, `bugs.md`) at `docs/project_notes/` — do NOT move them.
 
@@ -239,9 +264,9 @@ From the plan: new architectural decisions → `docs/project_notes/decisions.md`
 Use AskUserQuestion:
 - Header: "Design Items"
 - Question: List each flagged item with rationale
-- Options: "All recommended items need design" / "Some items — let me specify" / "None — skip design, go straight to execution"
+- Options: "All recommended items need design" / "Some items — let me specify" / "None — skip design, go straight to engineering"
 
-If "Some items," follow up. If "None," use Transition 4B.
+If "Some items," follow up. If "None," use Transition 2B.
 
 ### Generate Design Brief
 
@@ -262,6 +287,28 @@ Update active context: set `status` to `"design"`, mark `planning.completed = tr
 
 "Plan processed. Design brief prepared for **[First Item Name]**. Run `/intuition-design` to begin design exploration."
 
+## TRANSITION 2B: PLANNING → ENGINEER (Skip Design)
+
+Used when user confirms NO items need design.
+
+### Generate Engineering Brief
+
+Write `{context_path}engineering_brief.md` with these sections:
+- **Plan Summary** (1-2 paragraphs)
+- **Objective**
+- **Discovery Context** (brief reminder)
+- **Task Summary** (task list with brief descriptions)
+- **Known Risks** (with mitigations)
+- **References** (plan path, discovery path)
+
+### Update State
+
+Update active context: set `status` to `"engineering"`, mark `planning.completed = true` with timestamp and `approved = true`, set `design.started = false`, `design.completed = false`, `design.items = []`, set `engineering.started = true`.
+
+### Route User
+
+"Plan processed. No design items flagged. Engineering brief saved to `{context_path}engineering_brief.md`. Run `/intuition-engineer` to create code specs."
+
 ## TRANSITION 3: DESIGN → DESIGN (Next Item)
 
 ### Read Outputs
@@ -298,7 +345,7 @@ Update active context's `design.items`: mark completed item as `"completed"` wit
 
 "[Previous Item] design complete. Design brief updated for **[Next Item Name]** ([N] of [total], [remaining] remaining). Run `/intuition-design` to continue."
 
-## TRANSITION 4: DESIGN → EXECUTION
+## TRANSITION 4: DESIGN → ENGINEER
 
 Triggers when ALL design items have status `"completed"` or `"skipped"`.
 
@@ -311,55 +358,90 @@ Read: `{context_path}plan.md`
 
 From design specs: decisions → `docs/project_notes/decisions.md`, key facts → `docs/project_notes/key_facts.md`, design work → `docs/project_notes/issues.md`.
 
-### Generate Execution Brief
+### Generate Engineering Brief
 
-Write `{context_path}execution_brief.md` with these sections:
+Write `{context_path}engineering_brief.md` with these sections:
 - **Plan Summary** (1-2 paragraphs)
 - **Objective**
 - **Discovery Context** (brief reminder)
-- **Design Specifications** (list each spec with one-line summary; include: "Execute agents MUST read these specs before implementing flagged tasks.")
-- **Task Summary** (execution order, mark tasks with design specs)
-- **Quality Gates** (security review, tests, code review)
+- **Design Specifications** (list each spec with one-line summary; include: "Engineer MUST read these specs before creating code specs for flagged tasks.")
+- **Task Summary** (list tasks, mark tasks with design specs)
 - **Known Risks** (with mitigations)
 - **References** (plan path, discovery path, design spec paths)
 
 ### Update State
 
-Update active context: set `status` to `"executing"`, mark `design.completed = true` with timestamp, set `execution.started = true`.
+Update active context: set `status` to `"engineering"`, mark `design.completed = true` with timestamp, set `engineering.started = true`.
 
 ### Route User
 
-"All design specs processed. Execution brief saved to `{context_path}execution_brief.md`. Run `/intuition-execute` to begin implementation."
+"All design specs processed. Engineering brief saved to `{context_path}engineering_brief.md`. Run `/intuition-engineer` to create code specs."
 
-## TRANSITION 4B: PLANNING → EXECUTION (Skip Design)
+## TRANSITION 5: ENGINEER → BUILD
 
-Used when user confirms NO items need design.
+### Read Outputs
+
+Read: `{context_path}code_specs.md`
+Read: `{context_path}plan.md`
+
+### Extract and Structure
 
-### Generate Execution Brief
+From code specs: engineering decisions → `docs/project_notes/decisions.md`, key facts about implementation approach → `docs/project_notes/key_facts.md`.
 
-Same format as Transition 4 but without the "Design Specifications" section. Write to `{context_path}execution_brief.md`.
+### Generate Build Brief
+
+Write `{context_path}build_brief.md` with these sections:
+- **Plan Summary** (1-2 paragraphs)
+- **Objective**
+- **Code Specs Summary** (task count, key engineering decisions — 1 line each)
+- **Required User Steps** (from code_specs.md — things the user must do manually)
+- **Quality Gates** (security review, tests, code review)
+- **Known Risks** (from code specs risk notes)
+- **References** (plan path, code_specs path, design spec paths if any)
 
 ### Update State
 
-Update active context: set `status` to `"executing"`, mark `planning.completed = true` with timestamp and `approved = true`, set `design.started = false`, `design.completed = false`, `design.items = []`, set `execution.started = true`.
+Update active context: set `status` to `"building"`, mark `engineering.completed = true` with timestamp, set `build.started = true`.
 
 ### Route User
 
-"Plan processed. No design items flagged. Execution brief saved to `{context_path}execution_brief.md`. Run `/intuition-execute` to begin implementation."
+"Code specs processed. Build brief saved to `{context_path}build_brief.md`. Run `/intuition-build` to begin implementation."
 
-## TRANSITION 5: EXECUTION → COMPLETE
+## TRANSITION 6: BUILD → COMPLETE
 
 ### Read Outputs
 
-Read execution results from `{context_path}` for any reports the execution phase produced.
+Read build results from `{context_path}` for any reports the build phase produced.
 
 ### Extract and Structure
 
 Bugs found → `docs/project_notes/bugs.md`, lessons learned → `docs/project_notes/key_facts.md`, work completed → `docs/project_notes/issues.md`.
 
+### Git Commit Offer
+
+Check if a `.git` directory exists at the project root (use Bash: `test -d .git && echo "yes" || echo "no"`).
+
+If git repo exists, use AskUserQuestion:
+```
+Question: "Build complete. Would you like to commit the changes?"
+Header: "Git Commit"
+Options:
+- "Yes — commit and push"
+- "Yes — commit only (no push)"
+- "No — skip git"
+```
+
+If user approves commit:
+1. Run `git status` to see changed files
+2. Run `git add [specific files from build report]` — only add files that were part of the build
+3. Run `git commit` with a descriptive message summarizing the build
+4. If user chose push: run `git push`
+
+If no git repo or user skips: proceed without git operations.
+
 ### Update State
 
-Update active context: set `status` to `"complete"`, mark `execution.completed = true` with timestamp.
+Update active context: set `status` to `"complete"`, mark `build.completed = true` with timestamp.
 
 ### Route User
 
@@ -382,9 +464,10 @@ All shared memory files live at `docs/project_notes/` (never context_path).
 - **New constraints from planning**: Update key_facts.md, create ADR if architectural.
 - **Interrupted handoff**: Check what's updated, continue from there, don't duplicate.
 - **Corrupted state**: Infer phase from existing files. Ask user to confirm.
-- **Design item skipped mid-loop**: Mark as `"skipped"`, proceed to next. Note in execution brief.
-- **No Design Recommendations in plan**: Present tasks to user, ask if any need design. If none, use 4B.
+- **Design item skipped mid-loop**: Mark as `"skipped"`, proceed to next. Note in engineering brief.
+- **No Design Recommendations in plan**: Present tasks to user, ask if any need design. If none, use 2B.
 - **Plan revision after design started**: Alert user. Ask whether to continue or re-evaluate.
+- **Missing code_specs.md at Transition 5**: Tell user to run `/intuition-engineer` first.
 
 ## VOICE
 

package/skills/intuition-initialize/references/claude_template.md

@@ -7,12 +7,12 @@ This project uses a four-phase workflow coordinated by the Intuition system, wit
 The Intuition workflow uses a trunk-and-branch model:
 - **Trunk**: The first prompt→plan→design→execute cycle. Represents the core vision.
 - **Branches**: Subsequent cycles that build on, extend, or diverge from trunk or other branches.
-- **Engineer**: Post-execution troubleshooting with holistic codebase awareness.
+- **Debugger**: Post-execution diagnostic specialist for hard problems.
 
 All phases: `/intuition-prompt` → `/intuition-handoff` → `/intuition-plan` → `/intuition-handoff` →
 `[/intuition-design loop]` → `/intuition-handoff` → `/intuition-execute` → `/intuition-handoff` → complete
 
-After completion: `/intuition-start` to create branches or `/intuition-engineer` to troubleshoot.
+After completion: `/intuition-start` to create branches or `/intuition-debugger` to debug issues.
 
 ### Workflow Phases
 
@@ -54,7 +54,7 @@ The project follows a structured workflow with handoff transitions between phase
 
 **Recommended Flow**: Prompt → Handoff → Plan → Handoff → [Design Loop] → Handoff → Execute → Handoff → complete
 
-After completion, run `/intuition-start` to create a branch or invoke `/intuition-engineer` to troubleshoot.
+After completion, run `/intuition-start` to create a branch or invoke `/intuition-debugger` to debug issues.
 
 ### Memory Files
 
@@ -119,4 +119,4 @@ After completion, run `/intuition-start` to create a branch or invoke `/intuitio
 - "Execution brief is ready! Use `/intuition-execute` to kick off coordinated implementation."
 
 **When execution is complete:**
-- "Workflow cycle complete! Use `/intuition-start` to create a branch for new work, or `/intuition-engineer` to troubleshoot any issues."
+- "Workflow cycle complete! Use `/intuition-start` to create a branch for new work, or `/intuition-debugger` to debug any issues."

package/skills/intuition-initialize/references/intuition_readme_template.md

@@ -1,6 +1,6 @@
 # Intuition
 
-A trunk-and-branch workflow system for Claude Code. Turns rough ideas into structured plans, detailed designs, and executed implementations through guided dialogue. Supports iterative development through independent branch cycles and post-execution troubleshooting.
+A trunk-and-branch workflow system for Claude Code. Turns rough ideas into structured plans, detailed designs, and executed implementations through guided dialogue. Supports iterative development through independent branch cycles and post-execution debugging.
 
 ## Workflow
 
@@ -13,12 +13,12 @@ A trunk-and-branch workflow system for Claude Code. Turns rough ideas into struc
                                                         ↓
                                                /intuition-handoff  →  complete
                                                         ↓
-                              /intuition-start  →  create branch  or  /intuition-engineer
+                              /intuition-start  →  create branch  or  /intuition-debugger
 ```
 
 Run `/intuition-handoff` between every phase. It manages state, generates briefs, and routes you forward.
 
-The first prompt→execute cycle is the **trunk**. After trunk completes, create **branches** for new features or changes. Use `/intuition-engineer` to troubleshoot issues in any completed context.
+The first prompt→execute cycle is the **trunk**. After trunk completes, create **branches** for new features or changes. Use `/intuition-debugger` to investigate hard problems in any completed context.
 
 ## Skills
 
@@ -28,8 +28,8 @@ The first prompt→execute cycle is the **trunk**. After trunk completes, create
 | `/intuition-prompt` | Sharpens a rough idea into a planning-ready brief through focused Q&A |
 | `/intuition-plan` | Builds a strategic blueprint with tasks, decisions, and design flags |
 | `/intuition-design` | Elaborates flagged items through collaborative design exploration (ECD framework) |
-| `/intuition-execute` | Delegates implementation to specialized subagents and verifies quality |
-| `/intuition-engineer` | Holistic post-execution troubleshooter — diagnoses and fixes issues with full codebase awareness |
+| `/intuition-execute` | Tech lead orchestrator — engineering assessment, implementation guide, informed delegation |
+| `/intuition-debugger` | Expert debugger — diagnostic specialist for complex bugs, cross-context failures, performance issues |
 | `/intuition-handoff` | Processes phase outputs, updates memory, prepares the next phase |
 | `/intuition-initialize` | Sets up project memory (you already ran this) |
 
@@ -53,8 +53,8 @@ Not every project needs design. If the plan is clear enough, handoff skips strai
 
 10. `/intuition-start` — see project status and choose next step
     - **Create a branch** — start a new feature or change cycle, informed by trunk
-    - **Open the engineer** — diagnose and fix issues in any completed context
+    - **Open the debugger** — investigate hard problems in any completed context
 
-### Troubleshooting
+### Debugging
 
-Run `/intuition-engineer` at any time after a context is complete. It loads your workflow artifacts, investigates issues holistically, and delegates fixes to subagents.
+Run `/intuition-debugger` at any time after a context is complete. It classifies issues into diagnostic categories (causal chain, cross-context, emergent, performance, plan-was-wrong) and runs specialized investigation protocols.

package/skills/intuition-plan/SKILL.md

@@ -299,13 +299,15 @@ Ordered list forming a valid dependency DAG. Each task:
 - **Component**: [which architectural component]
 - **Description**: [WHAT to do, not HOW — execution decides HOW]
 - **Acceptance Criteria**:
-  1. [Measurable, objective criterion]
-  2. [Measurable, objective criterion]
+  1. [Outcome-based criterion — verifiable without prescribing implementation]
+  2. [Outcome-based criterion]
   [minimum 2 per task]
 - **Dependencies**: [Task numbers] or "None"
 - **Files**: [Specific paths when known] or "TBD — [component area]"
 ```
 
+**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.
 
@@ -323,18 +325,20 @@ Test types required. Which tasks need tests (reference task numbers). Critical t
 
 Every open question MUST have a Recommended Default. The execution phase uses the default unless the user provides direction. If you cannot write a reasonable default, the question is not ready to be left open — resolve it during dialogue.
 
-### 10. Execution Notes (always)
-- Recommended execution order (may differ from task numbering for parallelization)
-- Which tasks can run in parallel
-- Watch points (areas requiring caution)
-- Fallback strategies for high-risk tasks
-- Additional context not captured in tasks
+### 10. Planning Context for Engineer (always)
+Context and considerations for the engineering phase — NOT instructions. Engineer owns all implementation decisions.
+
+- **Sequencing Considerations**: Factors that affect task ordering (NOT a prescribed order — Engineer decides)
+- **Parallelization Opportunities**: Which tasks touch independent surfaces (Engineer validates and decides)
+- **Engineering Questions**: Open implementation questions Engineer must resolve during code spec creation (e.g., "How should error propagation work across Tasks 3-5?" / "Tasks 2 and 6 both touch the auth layer — shared abstraction or independent?")
+- **Constraints**: Hard boundaries Engineer must respect (performance targets, API contracts, backward compatibility)
+- **Risk Context**: What could go wrong and why — Engineer decides mitigation strategy
 
 ## Architect-Engineer Boundary
 
-The planning phase decides WHAT to build, WHERE it lives in the architecture, and WHY each decision was made. The execution phase decides HOW to build it at the code level — internal implementation, code patterns, file decomposition within components.
+The planning phase decides WHAT to build, WHERE it lives in the architecture, and WHY each decision was made. The engineering phase decides HOW to build it at the code level — internal implementation, code patterns, file decomposition within components. Engineer produces `code_specs.md` documenting its engineering decisions, then Build implements against those specs.
 
-Overlap resolution: Planning specifies public interfaces between components and known file paths. Execution owns everything internal to a component and determines paths for new files marked TBD.
+Overlap resolution: Planning specifies public interfaces between components and known file paths. Engineer owns everything internal to a component and determines paths for new files marked TBD.
 
 Interim artifacts in `.planning_research/` are working files for planning context management. They are NOT part of the plan-execute contract. Only `plan.md` crosses the handoff boundary.
 
@@ -389,7 +393,7 @@ Validate ALL before presenting the draft:
 - [ ] Technology decisions explicitly marked Locked or Recommended (Standard+)
 - [ ] Interface contracts provided where components interact (Comprehensive)
 - [ ] Risks have mitigations (Standard+)
-- [ ] Execution phase has enough context in Execution Notes to begin independently
+- [ ] Planning Context for Engineer includes engineering questions, not prescriptive instructions
 - [ ] Design Recommendations section included with every task assessed
 - [ ] Each DESIGN REQUIRED flag has a specific rationale (not generic)
 

package/skills/intuition-start/SKILL.md

@@ -76,14 +76,14 @@ IF state.version == "3.0" OR state.active_context is missing:
   → STOP phase detection
   → OUTPUT:
     "This project uses the v3.0 state schema, which is no longer compatible
-    with Intuition v7.0+. Run /intuition-handoff or /intuition-initialize
-    to upgrade to v4.0."
+    with Intuition v8.0+. Run /intuition-handoff or /intuition-initialize
+    to upgrade to v5.0."
   → END protocol here
 ```
 
 ## CONTEXT PATH RESOLUTION (Step 3)
 
-After confirming v4.0 schema:
+After confirming v4.0+ schema:
 
 ```
 active_context = state.active_context   (e.g. "trunk" or "feature-auth")
@@ -128,11 +128,17 @@ ELSE IF a context is in-progress (active_context has status not "complete"):
        AND context_workflow.workflow.design.completed == false:
     → PHASE: design_in_progress
 
-  ELSE IF context_workflow.workflow.execution.started == false:
-    → PHASE: ready_for_execution
+  ELSE IF context_workflow.workflow.engineering.started == false:
+    → PHASE: ready_for_engineering
 
-  ELSE IF context_workflow.workflow.execution.completed == false:
-    → PHASE: execution_in_progress
+  ELSE IF context_workflow.workflow.engineering.completed == false:
+    → PHASE: engineering_in_progress
+
+  ELSE IF context_workflow.workflow.build.started == false:
+    → PHASE: ready_for_build
+
+  ELSE IF context_workflow.workflow.build.completed == false:
+    → PHASE: build_in_progress
 
   ELSE:
     → PHASE: post_completion
@@ -140,12 +146,13 @@ ELSE IF a context is in-progress (active_context has status not "complete"):
 
 **"Any context is complete"** means: `state.trunk.status == "complete"` OR any entry in `state.branches` has `status == "complete"`.
 
-**"No context is in-progress"** means: `state.trunk.status` is not in `["prompt","planning","design","executing"]` AND no branch has status in those values.
+**"No context is in-progress"** means: `state.trunk.status` is not in `["prompt","planning","design","engineering","building"]` AND no branch has status in those values.
 
 If `.project-memory-state.json` exists but is corrupted or unreadable, infer phase from which files exist under `context_path`:
 - `{context_path}discovery_brief.md` exists → prompt complete
 - `{context_path}plan.md` exists → planning complete
 - `{context_path}design_spec_*.md` exist → design in progress or complete
+- `{context_path}code_specs.md` exists → engineering complete
 - Ask user to confirm if ambiguous.
 
 ## PHASE HANDLERS
@@ -178,7 +185,7 @@ Project Status:
 │   └── "[purpose]"
 ```
 
-Status labels: `none` → "Not started", `prompt` → "Prompting...", `planning` → "Planning...", `design` → "Designing...", `executing` → "Executing...", `complete` → "Complete"
+Status labels: `none` → "Not started", `prompt` → "Prompting...", `planning` → "Planning...", `design` → "Designing...", `engineering` → "Engineering...", `building` → "Building...", `complete` → "Complete"
 
 **If any context is in-progress:**
 
@@ -198,7 +205,7 @@ Question: "All current work is complete. What's next?"
 Header: "Next Step"
 Options:
 - "Create a new branch (new feature or change)"
-- "Troubleshoot an issue (/intuition-engineer)"
+- "Debug an issue (/intuition-debugger)"
 ```
 
 **If "Create a new branch":**
@@ -222,7 +229,9 @@ Pass along: branch name "[name]", purpose "[purpose]", parent "[parent]".
 **If "Troubleshoot":**
 
 ```
-Run /intuition-engineer to diagnose and fix issues in any completed context.
+Run /intuition-debugger to investigate and debug issues in any completed context.
+The debugger specializes in hard problems — causal chain bugs, cross-context failures,
+performance issues, and cases where the plan or design was wrong.
 ```
 
 ### Prompt In Progress
@@ -297,21 +306,59 @@ Design Queue:
 [If current item just completed]: Run /intuition-handoff to process the design and move to the next item.
 ```
 
-### Ready for Execution
+### Ready for Engineering
 
 Read and curate from:
-- `{context_path}plan.md` — extract objective, task count, approach
-- `{context_path}execution_brief.md` — reference location
+- `{context_path}plan.md` — extract objective, task count
+- `{context_path}engineering_brief.md` — reference location
 - `docs/project_notes/decisions.md` — relevant ADRs
 - `{context_path}design_spec_*.md` — list any design specs
 
 ```
-Welcome back! Your plan is approved and ready.
+Welcome back! Ready for engineering.
+
+Discovery: Complete
+Plan: Approved
+[If design specs exist]: Design: Complete ([N] specs)
+Engineering: Ready
+
+  - [N] tasks to spec
+  - Objective: [1 sentence]
+
+Engineering brief ready at: {context_path}engineering_brief.md
+
+Run /intuition-engineer to create code specs.
+```
+
+### Engineering In Progress
+
+```
+Welcome back! Engineering is in progress.
+
+Discovery: Complete
+Plan: Approved
+[If design specs exist]: Design: Complete
+Engineering: In progress
+
+Run /intuition-engineer to continue creating code specs.
+```
+
+### Ready for Build
+
+Read and curate from:
+- `{context_path}plan.md` — extract objective, task count, approach
+- `{context_path}code_specs.md` — reference location
+- `{context_path}build_brief.md` — reference location
+- `docs/project_notes/decisions.md` — relevant ADRs
+
+```
+Welcome back! Code specs are ready.
 
 Discovery: Complete
 Plan: Approved
 [If design specs exist]: Design: Complete ([N] specs)
-Execution: Ready
+Engineering: Complete
+Build: Ready
 
   - [N] tasks
   - Approach: [1 sentence]
@@ -321,24 +368,25 @@ Key context:
 - Problem: [1 sentence from discovery]
 - Main constraint: [most limiting]
 
-Execution brief ready at: {context_path}execution_brief.md
+Build brief ready at: {context_path}build_brief.md
 
-Run /intuition-execute to begin implementation.
+Run /intuition-build to begin implementation.
 ```
 
-### Execution In Progress
+### Build In Progress
 
-Read `{context_path}plan.md` for total tasks and any execution state available.
+Read `{context_path}plan.md` for total tasks and any build state available.
 
 ```
-Welcome back! Execution is in progress.
+Welcome back! Build is in progress.
 
 Discovery: Complete
 Plan: Approved
 [If design specs exist]: Design: Complete
-Execution: In progress
+Engineering: Complete
+Build: In progress
 
-Run /intuition-execute to continue.
+Run /intuition-build to continue.
 ```
 
 ## BRIEF CURATION RULES
@@ -379,6 +427,7 @@ You are curating information for the user, not dumping files. Follow these rules
 - **Old v2.0 state schema detected** (has `discovery` instead of `prompt`): Treat `discovery` fields as `prompt` fields. Suggest running `/intuition-initialize` to update to current schema.
 - **State file exists but active_context is null or missing**: Treat as v3.0 — output the upgrade warning and stop.
 - **Branch referenced in active_context but not found in branches map**: Report the inconsistency and suggest `/intuition-handoff` to reconcile state.
+- **v4.0 state detected** (has `execution` instead of `build`): Warn user: "State uses v4.0 schema. Run `/intuition-handoff` to migrate to v5.0."
 
 ## VOICE