@tgoodington/intuition 11.0.0 → 11.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tgoodington/intuition",
-  "version": "11.0.0",
+  "version": "11.1.0",
   "description": "Domain-adaptive workflow system for Claude Code. Includes the Enuncia pipeline (discovery, compose, design, execute, verify) and the classic pipeline (prompt, outline, assemble, detail, build, test, implement).",
   "keywords": [
     "claude-code",

package/scripts/install-skills.js

@@ -60,6 +60,7 @@ const skills = [
   'intuition-detail',
   'intuition-implement',
   // Enuncia pipeline (v11)
+  'intuition-enuncia-initialize',
   'intuition-enuncia-start',
   'intuition-enuncia-discovery',
   'intuition-enuncia-compose',

package/skills/intuition-enuncia-compose/SKILL.md

@@ -27,7 +27,7 @@ You are a decomposition thinker. You see a vision and ask "what needs to be true
 5. You MUST NOT open a response with a compliment or filler.
 6. You MUST produce experience slices that are stakeholder-perspective-in, not component-out.
 7. You MUST decompose tasks until each one passes the producer-ready test (see SIZING CHECK). There is no "Deep" or "Standard" — every task should be light enough to build directly.
-8. You MUST write `outline.json`, `project_map.md`, and update state before routing.
+8. You MUST write `tasks.json`, `docs/project_notes/project_map.md`, and update state before routing.
 9. You MUST route to `/intuition-enuncia-design`. NEVER to `/intuition-enuncia-handoff`.
 10. You MUST reference the discovery brief's North Star when evaluating whether experience slices are complete — if a slice doesn't serve the North Star, it doesn't belong.
 
@@ -54,7 +54,7 @@ Phase 2:   Experience mapping — what needs to exist for each stakeholder
 Phase 3:   Task decomposition — producer-ready work packages
 Phase 3.5: Brief traceability check — verify outline delivers what the brief describes
 Phase 4:   User approval
-Phase 5:   Write outputs (outline.json, project_map.md, state update)
+Phase 5:   Write outputs (tasks.json, project_map.md, state update)
 ```
 
 ## PHASE 1: INTAKE
@@ -71,7 +71,7 @@ Read `{context_path}/discovery_brief.md`. Extract:
 
 Research is needed ONLY when ALL of these are true:
 - This is trunk (not a branch)
-- No `{context_path}/project_map.md` exists
+- No `docs/project_notes/project_map.md` exists
 - The project has an existing codebase (check: Glob for source files in common locations — `src/`, `app/`, `lib/`, `*.py`, `*.js`, `*.ts`, etc.)
 
 If all conditions are met, launch ONE `intuition-researcher` agent:
@@ -87,7 +87,7 @@ Under 500 words. Facts only."
 
 Write results to `{context_path}/.outline_research/orientation.md` for reference.
 
-**If this is a branch:** Read the parent's `project_map.md` instead of running research. The map IS the orientation.
+**If this is a branch:** Read `docs/project_notes/project_map.md` instead of running research. The map IS the orientation.
 
 **If this is greenfield (no existing codebase):** Skip research entirely. The map starts blank.
 
@@ -267,7 +267,7 @@ If changes needed, address them and re-present.
 
 ## PHASE 5: WRITE OUTPUTS
 
-### Write `{context_path}/outline.json`
+### Write `{context_path}/tasks.json`
 
 ```json
 {
@@ -307,9 +307,9 @@ If changes needed, address them and re-present.
 
 The `decisions` array on each task is optional — only include when decisions are clearly visible at the outline level. Most tasks will have an empty array.
 
-### Write `{context_path}/project_map.md`
+### Update `docs/project_notes/project_map.md`
 
-This is the first draft of the living project map. It starts rough and gets refined by specialists during detail.
+The project map scaffold was created by initialize. Fill in the sections with real content from the experience mapping and task decomposition.
 
 ```markdown
 # Project Map: [Project Title]
@@ -353,8 +353,8 @@ Set on target: `status` -> `"outline"`, `workflow.outline.completed` -> `true`,
 ### Route
 
 ```
-Outline saved to {context_path}outline.json
-Project map drafted at {context_path}project_map.md
+Outline saved to {context_path}tasks.json
+Project map drafted at docs/project_notes/project_map.md
 Run /clear then /intuition-enuncia-design
 ```
 
@@ -362,8 +362,8 @@ Run /clear then /intuition-enuncia-design
 
 When `active_context` is not trunk:
 
-1. Read the parent's `project_map.md` — this is your orientation instead of codebase research
-2. Read the parent's `outline.json` — understand the existing task structure
+1. Read `docs/project_notes/project_map.md` — this is your orientation instead of codebase research
+2. Read the parent's `tasks.json` — understand the existing task structure
 3. Read the branch's `discovery_brief.md` — understand what's changing
 
 The branch outline focuses on what's new or different. Experience slices may be:
@@ -371,7 +371,7 @@ The branch outline focuses on what's new or different. Experience slices may be:
 - **Modified**: Parent slice with changes for this branch
 - **New**: Something the branch adds that the parent doesn't have
 
-The branch `outline.json` is a complete document (not a diff) but includes a `parent_context` field:
+The branch `tasks.json` is a complete document (not a diff) but includes a `parent_context` field:
 
 ```json
 {
@@ -387,13 +387,13 @@ The branch `outline.json` is a complete document (not a diff) but includes a `pa
 }
 ```
 
-The branch `project_map.md` is a copy of the parent's map with the branch's changes applied. Update the Map History table with the branch entry.
+Update `docs/project_notes/project_map.md` with the branch's changes. Update the Map History table with the branch entry.
 
 Branch outlines should be faster — most of the experience mapping is inherited. Focus the conversation on what's new.
 
 ## RESUME LOGIC
 
-1. If `{context_path}/outline.json` exists: "An outline already exists. Revise it or start fresh?"
+1. If `{context_path}/tasks.json` exists: "An outline already exists. Revise it or start fresh?"
 2. If `{context_path}/.outline_research/` has interim artifacts: read them and continue from where the conversation left off.
 3. Otherwise, fresh start from Phase 1.
 

package/skills/intuition-enuncia-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: intuition-enuncia-design
-description: Technical design phase. Takes outline tasks grouped by experience slice, determines how they get built, writes producer-ready specs, and updates the project map with real architecture. The engineering brain between outline and build.
+description: Technical design phase. Takes tasks grouped by experience slice, determines how they get built, enriches tasks.json with design fields, and updates the project map with real architecture. The engineering brain between outline and build.
 model: opus
 tools: Read, Write, Glob, Grep, Task, AskUserQuestion, Bash
 allowed-tools: Read, Write, Glob, Grep, Task, Bash
@@ -21,13 +21,13 @@ You are the engineering brain. Outline decided what needs to exist. You decide h
 ## CRITICAL RULES
 
 1. You MUST read `.project-memory-state.json` and resolve context_path before anything else.
-2. You MUST read `{context_path}/discovery_brief.md` and `{context_path}/outline.json`. If either is missing, stop with instructions.
-3. You MUST read `{context_path}/project_map.md` if it exists.
+2. You MUST read `{context_path}/discovery_brief.md` and `{context_path}/tasks.json`. If either is missing, stop with instructions.
+3. You MUST read `docs/project_notes/project_map.md` if it exists.
 4. You MUST work at the experience-slice level, not task-by-task. Group related tasks, design the slice as a unit, then produce per-task specs.
 5. You MUST verify every technical decision serves the discovery brief's North Star. Speed vs accuracy tradeoffs, stakeholder experience impacts, and constraint compliance all check against the brief.
 6. You MUST surface decisions to the user based on the discovery brief's Decision Posture. Do not silently resolve decisions the user wants to weigh in on.
 7. During dialogue, you MUST ask questions as plain text. AskUserQuestion is ONLY for the final approval gate.
-8. You MUST write task specs to `{context_path}/specs/` and update `{context_path}/project_map.md`.
+8. You MUST enrich task objects in `{context_path}/tasks.json` with design fields and update `docs/project_notes/project_map.md`.
 9. You MUST route to `/intuition-enuncia-execute` after completion. NEVER to `/intuition-enuncia-handoff`.
 10. You MUST NOT write code. You write specs that describe what code to write. Producers write code.
 
@@ -50,9 +50,9 @@ You are the engineering brain. Outline decided what needs to exist. You decide h
 Phase 1:   Intake — read discovery brief, outline, project map
 Phase 2:   Slice grouping — organize tasks by experience slice
 Phase 2.5: Operational foundation — deployment, repo structure, dev workflow (code projects only)
-Phase 3:   Technical design — research + decisions per slice group
-Phase 4:   Spec writing — producer-ready specs per task
-Phase 5:   User review — surface decisions, confirm approach
+Phase 3:   Technical design — research + decisions per slice group, present each group individually for user review
+Phase 4:   Task enrichment — enrich tasks.json with design fields per task
+Phase 5:   Final confirmation — compact summary, approval gate
 Phase 6:   Write outputs — specs, updated map, state
 ```
 
@@ -60,8 +60,8 @@ Phase 6:   Write outputs — specs, updated map, state
 
 Read these files:
 - `{context_path}/discovery_brief.md` — REQUIRED. Extract North Star, decision posture, constraints, stakeholders.
-- `{context_path}/outline.json` — REQUIRED. Extract experience slices, tasks, acceptance criteria, dependencies.
-- `{context_path}/project_map.md` — if exists. Understand current component landscape.
+- `{context_path}/tasks.json` — REQUIRED. Extract experience slices, tasks, acceptance criteria, dependencies.
+- `docs/project_notes/project_map.md` — if exists. Understand current component landscape.
 
 ### Opening
 
@@ -70,7 +70,7 @@ Present a brief synthesis of what you're working with:
 ```
 The outline has [N] experience slices broken into [M] tasks across [domains listed].
 I'll work through these by slice — designing the technical approach for each group
-of related tasks, then writing specs producers can build from.
+of related tasks, then enriching each task in tasks.json with design fields producers can build from.
 
 [First observation or question about the technical landscape]
 ```
@@ -174,73 +174,60 @@ Before moving to specs, verify this group's design against the discovery brief:
 
 If something drifts, flag it to the user before proceeding.
 
-## PHASE 4: SPEC WRITING
+### 3e. Present Group for Review
 
-After designing each slice group, write a spec for each task within the group.
+After designing each group, present it to the user **before moving to the next group**. Do NOT batch all groups together. One group at a time keeps the review digestible.
 
-### Spec Format
+Present the group's design as plain text (not AskUserQuestion — that's reserved for the final gate):
 
-Write one spec file per task to `{context_path}/specs/`:
+```
+**Group [N] of [total]: [Group Name] ([slice refs])**
 
-File: `{context_path}/specs/T{N}-{task-title-slug}.md`
+[Technical approach — tables, data models, algorithms, whatever this group needs]
 
-```markdown
-# Spec: [Task Title]
+[Any decisions that need user input per decision posture]
 
-## Task Reference
-- **Task ID**: T[N]
-- **Experience Slice**: ES-[N]: [title]
-- **Domain**: [from outline]
+[Any questions about this group]
 
-## What to Build
-[Clear description of what the producer creates. Not pseudocode — a description of the deliverable and its behavior.]
+When you're good with this group, say so and I'll move to the next one.
+```
 
-## Technical Approach
-[Technology, patterns, file structure. Enough for a producer to start coding without guessing.]
+Wait for the user to confirm or request changes before proceeding to the next group. If the user asks for changes, revise and re-present the same group.
 
-## Acceptance Criteria
-[Carried from outline, potentially refined with technical specifics]
-1. [criterion]
-2. [criterion]
+This is the primary user interaction loop of the design phase. Each group gets the user's full attention.
 
-## Interfaces
-[How this task's output connects to other tasks. What it receives, what it produces, what format.]
+## PHASE 4: TASK ENRICHMENT
 
-## Files
-[Specific file paths to create or modify]
+After designing each slice group, enrich each task in `{context_path}/tasks.json` with design fields.
 
-## Dependencies
-[What must exist before this task can be built — other tasks, libraries, APIs]
+### Fields Added by Design
 
-## Decisions Made
-[Technical decisions resolved during design, with rationale. Traced to user input or brief constraints.]
+For each task, add these fields to the task object:
 
-## Notes for Producer
-[Anything the producer should know — gotchas, conventions to follow, things to avoid]
-```
+- **`technical_approach`**: Technology, patterns, file structure. Enough for a producer to start coding without guessing.
+- **`interfaces`**: How this task's output connects to other tasks. What it receives, what it produces, what format.
+- **`files`**: Array of objects `{ "path": "...", "purpose": "..." }` — specific file paths to create or modify, with a brief description of what each file does.
+- **`design_decisions`**: Array of objects `{ "decision": "...", "rationale": "..." }` — technical decisions resolved during design, traced to user input or brief constraints.
+- **`producer_notes`**: Anything the producer should know — gotchas, conventions to follow, things to avoid.
 
-Specs should be concise. A producer reads this and knows exactly what to build, in what files, using what approach, meeting what criteria. No ambiguity, no open questions.
-
-## PHASE 5: USER REVIEW
+Design may also refine existing fields:
+- **`acceptance_criteria`** — add technical specifics to the outcome-based criteria from compose
+- **`description`** — may be expanded with "what to build" detail (the deliverable and its behavior)
 
-After all slice groups are designed and specs are written, present a summary via AskUserQuestion:
+After enrichment, each task object should contain everything a producer needs. No ambiguity, no open questions.
 
-```
-Question: "Design complete. Here's the summary:
+## PHASE 5: USER REVIEW
 
-**[Slice Group 1 name]**
-[1-2 sentence technical approach]
-Tasks: [T1, T2, ...] — specs written
+Since each group was reviewed individually during Phase 3, this is a brief final confirmation — not a re-presentation. The user has already seen and approved every group.
 
-**[Slice Group 2 name]**
-[1-2 sentence technical approach]
-Tasks: [T3, T4, ...] — specs written
+Present a compact summary via AskUserQuestion:
 
-...
+```
+Question: "Design complete — all [N] groups reviewed.
 
-**Decisions made:** [count] — [count surfaced to you, count resolved autonomously]
-**Project map updated:** [list key additions]
-**Brief alignment:** All designs serve the North Star and respect constraints.
+Tasks enriched: [T1, T2, ..., TN]
+Decisions made: [count] ([count] surfaced to you, [count] resolved autonomously)
+Project map updated: [key additions]
 
 Ready for build?"
 
@@ -252,7 +239,11 @@ Options:
 
 ## PHASE 6: WRITE OUTPUTS
 
-### Update `{context_path}/project_map.md`
+### Write `{context_path}/tasks.json`
+
+Write the enriched `{context_path}/tasks.json` back to disk with all design fields added to each task object.
+
+### Update `docs/project_notes/project_map.md`
 
 Refine the map with real architecture from the design phase:
 - Add **Operational Foundation** section (for code projects): deployment model, repository structure, environment management, developer workflow — from Phase 2.5
@@ -271,8 +262,8 @@ Set: `status` → `"building"`, `workflow.outline.completed` → `true` (if not
 ### Route
 
 ```
-Specs written to {context_path}/specs/
-Project map updated at {context_path}/project_map.md
+Tasks enriched in {context_path}/tasks.json
+Project map updated at docs/project_notes/project_map.md
 Run /clear then /intuition-enuncia-execute
 ```
 
@@ -280,18 +271,18 @@ Run /clear then /intuition-enuncia-execute
 
 When `active_context` is not trunk:
 
-1. Read the parent's project map and specs — understand the existing technical architecture
-2. Read the branch's outline and discovery brief — understand what's changing
+1. Read `docs/project_notes/project_map.md` — understand the existing technical architecture
+2. Read the branch's tasks.json and discovery brief — understand what's changing
 3. Design only the tasks that are new or modified for this branch
-4. Inherited tasks don't need new specs — reference the parent's specs
-5. Update the branch's project map with branch-specific architecture changes
+4. Inherited tasks don't need enrichment — they retain their existing design fields
+5. Update `docs/project_notes/project_map.md` with branch-specific architecture changes
 
 Branch design should be faster — most technical decisions are inherited from the parent.
 
 ## RESUME LOGIC
 
-1. If `{context_path}/specs/` exists with spec files: check which tasks have specs and which don't. Resume from the first unspecified group.
-2. If no specs exist: fresh start from Phase 1.
+1. If `{context_path}/tasks.json` exists: check which tasks already have a `technical_approach` field and which don't. Resume from the first slice group with unenriched tasks.
+2. If no tasks have been enriched: fresh start from Phase 1.
 
 ## VOICE
 

package/skills/intuition-enuncia-execute/SKILL.md

@@ -19,14 +19,14 @@ Execute the design specs. Delegate production to the right producers, verify wha
 ## CRITICAL RULES
 
 1. You MUST read `.project-memory-state.json` and resolve `context_path` before reading any other files.
-2. You MUST read `{context_path}/discovery_brief.md`, `{context_path}/outline.json`, and all `{context_path}/specs/*.md`. If specs are missing, stop: "No specs found. Run `/intuition-enuncia-design` first."
+2. You MUST read `{context_path}/discovery_brief.md` and `{context_path}/tasks.json`. If tasks.json is missing or tasks lack design fields, stop: "No design specs found. Run `/intuition-enuncia-design` first."
 3. You MUST confirm the build plan with the user before delegating any work.
 4. You MUST delegate all production to subagents via the Task tool. NEVER produce deliverables yourself.
 5. You MUST run the two-layer review chain (builder verification + security) for every deliverable.
 6. You MUST verify every deliverable against the discovery brief's North Star — not just acceptance criteria.
 7. You MUST NOT make design decisions. Specs are your authority. If a spec is ambiguous, escalate — don't improvise.
 8. You MUST route to the next phase after completion. NEVER to `/intuition-enuncia-handoff`.
-9. You MUST update `{context_path}/project_map.md` if implementation reveals anything the map didn't capture.
+9. You MUST update `docs/project_notes/project_map.md` if implementation reveals anything the map didn't capture.
 
 **TOOL DISTINCTION:**
 - `TaskCreate / TaskUpdate / TaskList / TaskGet` = YOUR internal task board for tracking items.
@@ -60,17 +60,16 @@ Step 7: Route to next phase
 
 Read these files:
 1. `{context_path}/discovery_brief.md` — North Star, decision posture, constraints, stakeholders
-2. `{context_path}/outline.json` — experience slices, tasks, acceptance criteria, dependencies
-3. ALL files in `{context_path}/specs/*.md` — design specs with technical approach, interfaces, file paths
-4. `{context_path}/project_map.md` — component landscape, interactions, what exists vs what's new
+2. `{context_path}/tasks.json` — experience slices, tasks with design enrichment (technical approach, interfaces, file paths, decisions)
+3. `docs/project_notes/project_map.md` — component landscape, interactions, what exists vs what's new
 
-Validate: every task in `outline.json` has a corresponding spec in `specs/`. If any task lacks a spec, inform the user and ask whether to proceed with partial specs or run design first.
+Validate: every task in `tasks.json` has a `technical_approach` field (indicating design enrichment). If any task lacks a `technical_approach`, inform the user and ask whether to proceed with partial specs or run design first.
 
-From the specs, extract per task:
-- Technical approach and file paths
-- Acceptance criteria (refined from outline)
-- Interfaces and dependencies
-- Decisions made during design
+From each task object, extract:
+- `task.technical_approach` and `task.files`
+- `task.acceptance_criteria` (refined from compose)
+- `task.interfaces` and `task.dependencies`
+- `task.design_decisions`
 
 ## STEP 2: CONFIRM BUILD PLAN
 
@@ -99,7 +98,7 @@ Options:
 
 ## STEP 3: CREATE TASK BOARD
 
-Use TaskCreate for each task from the outline. Set dependencies via TaskUpdate with addBlockedBy. Tasks start `pending`, move to `in_progress` when delegated, `completed` when review passes.
+Use TaskCreate for each task from tasks.json. Set dependencies via TaskUpdate with addBlockedBy. Tasks start `pending`, move to `in_progress` when delegated, `completed` when review passes.
 
 ## STEP 4: DELEGATE TO PRODUCERS
 
@@ -124,12 +123,34 @@ If no matching producer profile is found, default to `intuition-code-writer` wit
 ```
 You are building a deliverable from a design spec. Follow the spec exactly.
 
-## Your Spec
-Read the spec at {context_path}/specs/T{N}-{slug}.md
-The spec contains: what to build, technical approach, file paths, acceptance criteria, and interfaces.
+## Your Task
+Task ID: T{N}
+Title: {task.title}
+Domain: {task.domain}
+
+## What to Build
+{task.description}
+
+## Technical Approach
+{task.technical_approach}
+
+## Files
+{task.files}
+
+## Acceptance Criteria
+{task.acceptance_criteria}
+
+## Interfaces
+{task.interfaces}
+
+## Design Decisions
+{task.design_decisions}
+
+## Producer Notes
+{task.producer_notes}
 
 ## Project Context
-Read {context_path}/project_map.md for how this piece connects to the rest of the project.
+Read docs/project_notes/project_map.md for how this piece connects to the rest of the project.
 Read {context_path}/discovery_brief.md for the project's North Star and constraints.
 
 ## Rules
@@ -169,7 +190,7 @@ For every deliverable that produces code, configuration, or scripts, spawn an `i
 You are a security reviewer. Your job is to FIND PROBLEMS.
 
 Deliverable: Read [produced file paths]
-Spec: Read {context_path}/specs/T{N}-{slug}.md (for context)
+Spec: Review against the task spec in {context_path}/tasks.json, task {task.id}
 
 Check for: injection vulnerabilities, authentication/authorization gaps, secrets in code, unsafe data handling, dependency risks, configuration weaknesses.
 
@@ -225,7 +246,7 @@ Non-code deliverables (documents, spreadsheets, etc.) skip security review.
 }
 ```
 
-### Update `{context_path}/project_map.md`
+### Update `docs/project_notes/project_map.md`
 
 If implementation revealed anything not in the map — new components, changed interactions, unexpected dependencies — update the map. Add a Map History entry for the build phase.
 
@@ -242,9 +263,9 @@ Present a concise summary to the user: task count, pass/fail, files produced, an
 ## BRANCH MODE
 
 When building on a branch:
-- Read the parent's project map for architectural context
+- Read `docs/project_notes/project_map.md` for architectural context
 - Add branch-awareness to producer prompts (compatibility with parent)
-- Update the branch's project map, not the parent's
+- Update `docs/project_notes/project_map.md`
 
 ## PARALLEL EXECUTION