@tgoodington/intuition 7.1.0 → 8.0.1

package/skills/intuition-plan/SKILL.md

@@ -94,17 +94,51 @@ From the discovery brief, extract: core problem, success criteria, stakeholders,
 
 ## Step 2: Launch orientation research
 
-Create the directory `docs/project_notes/.planning_research/` if it does not exist.
+Create the directory `{context_path}/.planning_research/` if it does not exist.
 
-Launch 2 haiku research agents in parallel using the Task tool:
+Launch 2 sonnet research agents in parallel using the Task tool:
 
-**Agent 1 — Codebase Topology** (subagent_type: Explore, model: haiku):
-Prompt: "Analyze this project's codebase structure. Report on: (1) top-level directory structure, (2) key modules and responsibilities, (3) entry points, (4) test infrastructure, (5) build system. Use Glob, Grep, Read to explore. Under 500 words. Facts only."
+**Agent 1 — Codebase Topology** (subagent_type: Explore, model: sonnet):
+Prompt:
+"The project root is the current working directory. Analyze the codebase structure by following these steps in order:
 
-**Agent 2 — Pattern Extraction** (subagent_type: Explore, model: haiku):
-Prompt: "Analyze this project's codebase for patterns. Report on: (1) architectural patterns in use, (2) coding conventions, (3) existing abstractions, (4) dependency patterns between modules. Use Glob, Grep, Read to explore. Under 500 words. Facts only."
+1. Run Glob('*') to list all top-level files and directories.
+2. Read package.json (or equivalent manifest) for project metadata, scripts, and dependencies.
+3. Read any README.md or CLAUDE.md at the project root.
+4. For each top-level source directory, run Glob('{dir}/*') to map one level of contents.
+5. Grep for common entry points: 'main', 'index', 'app', 'server' in source files.
+6. Check for test infrastructure: Glob('**/*.test.*') or Glob('**/*.spec.*') or Glob('**/test/**').
+7. Check for build config: Glob('**/tsconfig*') or Glob('**/webpack*') or Glob('**/vite*') or similar.
 
-When both return, combine results and write to `docs/project_notes/.planning_research/orientation.md`.
+Report on:
+(1) Top-level directory structure with purpose of each directory
+(2) Key modules and their responsibilities
+(3) Entry points
+(4) Test infrastructure (framework, location, patterns)
+(5) Build system and tooling
+
+Under 500 words. Facts only, no speculation."
+
+**Agent 2 — Pattern Extraction** (subagent_type: Explore, model: sonnet):
+Prompt:
+"The project root is the current working directory. Analyze codebase patterns by following these steps:
+
+1. Read 3-5 representative source files from different directories to identify coding style.
+2. Grep for 'export' or 'module.exports' to understand module boundaries.
+3. Grep for 'import' or 'require' to map dependency patterns between modules.
+4. Grep for error handling patterns: 'catch', 'throw', 'Error', 'try'.
+5. Grep for common abstractions: 'class', 'interface', 'type', 'abstract', 'base'.
+6. Check for configuration patterns: Glob('**/*.config.*') or Glob('**/.{eslint,prettier}*').
+
+Report on:
+(1) Architectural patterns in use (MVC, event-driven, plugin system, etc.)
+(2) Coding conventions (naming, file organization, export style)
+(3) Existing abstractions and base classes/utilities
+(4) Dependency patterns between modules (which modules depend on which)
+
+Under 500 words. Facts only, no speculation."
+
+When both return, combine results and write to `{context_path}/.planning_research/orientation.md`.
 
 ## BRANCH-AWARE INTAKE (Branch Only)
 
@@ -117,8 +151,23 @@ When `active_context` is NOT trunk:
 3. Read parent's plan.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: haiku):
-Prompt: "Compare the discovery brief at {context_path}/discovery_brief.md with the plan at {parent_path}/plan.md. Identify: (1) Shared files/components that both touch, (2) Decisions in the parent plan that constrain this branch, (3) Potential conflicts or dependencies, (4) Patterns from parent that should be reused. Under 500 words. Facts only."
+**Agent 3 — Parent Intersection Analysis** (subagent_type: Explore, model: sonnet):
+Prompt:
+"The project root is the current working directory. Compare two workflow artifacts:
+
+1. Read the discovery brief at {context_path}/discovery_brief.md.
+2. Read the parent plan at {parent_path}/plan.md.
+3. For each file path mentioned in the parent plan's tasks, check if the discovery brief references the same files or components.
+4. Extract all technology decisions from the parent plan (Section 3 if it exists).
+5. Identify acceptance criteria in the parent plan that touch the same areas as the discovery brief.
+
+Report on:
+(1) Shared files/components that both parent plan and this branch's discovery brief touch
+(2) Decisions in the parent plan that constrain this branch
+(3) Potential conflicts or dependencies between parent and branch work
+(4) Patterns from parent implementation that this branch should reuse
+
+Under 500 words. Facts only, no speculation."
 
 Write results to `{context_path}/.planning_research/parent_intersection.md`.
 
@@ -304,10 +353,9 @@ Ordered list forming a valid dependency DAG. Each task:
   [minimum 2 per task]
 - **Dependencies**: [Task numbers] or "None"
 - **Files**: [Specific paths when known] or "TBD — [component area]"
-- **Implementation Latitude**: [What Execute gets to decide — patterns, error handling, internal structure, approach]
 ```
 
-**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()"). Execute and its engineers decide the code-level HOW.
+**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.
@@ -326,20 +374,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. Planning Context for Execute (always)
-Context and considerations for the execution phase — NOT instructions. Execute owns all implementation decisions.
+### 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 — Execute decides)
-- **Parallelization Opportunities**: Which tasks touch independent surfaces (Execute validates and decides)
-- **Engineering Questions**: Open implementation questions Execute must resolve during its Engineering Assessment (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 Execute must respect (performance targets, API contracts, backward compatibility)
-- **Risk Context**: What could go wrong and why — Execute decides mitigation strategy
+- **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. Execute produces an `implementation_guide.md` documenting its engineering decisions before delegating work.
+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. The Implementation Latitude field on each task explicitly marks what Execute gets to decide.
+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.
 
@@ -394,8 +442,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+)
-- [ ] Planning Context for Execute includes engineering questions, not prescriptive instructions
-- [ ] Every task has an Implementation Latitude field identifying what Execute decides
+- [ ] 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)
 
@@ -405,7 +452,7 @@ If any check fails, fix it before presenting.
 
 ## Tier 1: Orientation (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 `docs/project_notes/.planning_research/orientation.md`.
+Launch 2 sonnet Explore agents in parallel via Task tool. See Phase 1, Step 2 for prompt templates. Write combined results to `{context_path}/.planning_research/orientation.md`.
 
 ## Tier 2: Decision Research (launched on demand in Phase 3)
 

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:**
 
@@ -299,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]
@@ -323,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
@@ -381,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