@tgoodington/intuition 11.0.1 → 11.1.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tgoodington/intuition",
-  "version": "11.0.1",
+  "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.
 
@@ -51,7 +51,7 @@ 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, present each group individually for user review
-Phase 4:   Spec writing — producer-ready specs per task
+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]
 ```
@@ -196,52 +196,25 @@ Wait for the user to confirm or request changes before proceeding to the next gr
 
 This is the primary user interaction loop of the design phase. Each group gets the user's full attention.
 
-## PHASE 4: SPEC WRITING
+## PHASE 4: TASK ENRICHMENT
 
-After designing each slice group, write a spec for each task within the group.
+After designing each slice group, enrich each task in `{context_path}/tasks.json` with design fields.
 
-### Spec Format
+### Fields Added by Design
 
-Write one spec file per task to `{context_path}/specs/`:
+For each task, add these fields to the task object:
 
-File: `{context_path}/specs/T{N}-{task-title-slug}.md`
+- **`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.
 
-```markdown
-# Spec: [Task Title]
+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)
 
-## Task Reference
-- **Task ID**: T[N]
-- **Experience Slice**: ES-[N]: [title]
-- **Domain**: [from outline]
-
-## What to Build
-[Clear description of what the producer creates. Not pseudocode — a description of the deliverable and its behavior.]
-
-## Technical Approach
-[Technology, patterns, file structure. Enough for a producer to start coding without guessing.]
-
-## Acceptance Criteria
-[Carried from outline, potentially refined with technical specifics]
-1. [criterion]
-2. [criterion]
-
-## Interfaces
-[How this task's output connects to other tasks. What it receives, what it produces, what format.]
-
-## Files
-[Specific file paths to create or modify]
-
-## Dependencies
-[What must exist before this task can be built — other tasks, libraries, APIs]
-
-## Decisions Made
-[Technical decisions resolved during design, with rationale. Traced to user input or brief constraints.]
-
-## Notes for Producer
-[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.
+After enrichment, each task object should contain everything a producer needs. No ambiguity, no open questions.
 
 ## PHASE 5: USER REVIEW
 
@@ -252,7 +225,7 @@ Present a compact summary via AskUserQuestion:
 ```
 Question: "Design complete — all [N] groups reviewed.
 
-Tasks specced: [T1, T2, ..., TN]
+Tasks enriched: [T1, T2, ..., TN]
 Decisions made: [count] ([count] surfaced to you, [count] resolved autonomously)
 Project map updated: [key additions]
 
@@ -266,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
@@ -285,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
 ```
 
@@ -294,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
 

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

@@ -0,0 +1,251 @@
+---
+name: intuition-enuncia-initialize
+description: Set up project memory infrastructure for the Enuncia pipeline with workflow state tracking, memory files, project map, and configuration templates.
+model: haiku
+tools: Read, Write, Glob, Grep, Bash, AskUserQuestion
+allowed-tools: Read, Write, Glob, Grep, Bash
+---
+
+# Initialize - Enuncia Pipeline Setup Protocol
+
+You create the `docs/project_notes/` directory structure, initialize memory files from templates, create the Enuncia workflow state file, set up the project map scaffold, and create project configuration files. You run once per project to set up infrastructure, then hand off to the workflow skills.
+
+## CRITICAL RULES
+
+1. You MUST check install location before doing anything else — enforce global install.
+2. You MUST check if `docs/project_notes/` already exists before creating anything.
+3. You MUST use template files from `references/` directory. Read each template with the Read tool, then Write to the target path.
+4. You MUST create `.project-memory-state.json` using the Enuncia schema from `references/state_template.json`.
+5. You MUST auto-create all configuration files (CLAUDE.md, INTUITION.md, settings, profile) if they do not exist. Do NOT ask — just create them.
+6. You MUST NOT overwrite existing files. If a file already exists, skip it silently.
+7. You MUST NOT invoke other skills. You only set up infrastructure.
+8. You MUST report what was created at the end.
+
+## PROTOCOL: COMPLETE FLOW
+
+```
+Step 0: Check install location — enforce global install
+Step 1: Detect existing setup
+Step 2: Create memory directory and files from templates
+Step 3: Create .project-memory-state.json with Enuncia schema
+Step 4: Update CLAUDE.md with Enuncia workflow protocols
+Step 4.5: Create INTUITION.md framework overview
+Step 5: Create configuration files (settings, user profile)
+Step 6: Report completion and suggest next step
+```
+
+## STEP 0: ENFORCE GLOBAL INSTALL
+
+Before anything else, check whether `@tgoodington/intuition` is installed locally (project-level) vs globally.
+
+Run these checks using Bash:
+
+```
+Local:  npm list @tgoodington/intuition --depth=0 2>&1
+Global: npm list -g @tgoodington/intuition --depth=0 2>&1
+```
+
+Apply this logic:
+
+```
+IF local install found AND global install found:
+  → Uninstall local: npm uninstall @tgoodington/intuition
+  → Notify: "Removed local install. Using global install."
+
+IF local install found AND no global install:
+  → Uninstall local: npm uninstall @tgoodington/intuition
+  → Install global: npm install -g @tgoodington/intuition
+  → Notify: "Moved install from local to global."
+
+IF no local install AND global install found:
+  → Proceed (correct setup)
+
+IF neither found:
+  → Warn: "Package not found. Install with: npm install -g @tgoodington/intuition"
+  → STOP
+```
+
+## STEP 1: DETECT EXISTING SETUP
+
+Check if `docs/project_notes/` exists.
+
+```
+IF docs/project_notes/ exists:
+  → Check which files already exist
+  → Ask user: "Project memory already exists. What would you like to do?"
+    Options:
+    - "Skip existing files, only create missing ones" (Recommended)
+    - "Overwrite everything with fresh templates"
+    - "Cancel — nothing to do"
+
+IF docs/project_notes/ does NOT exist:
+  → Proceed with full setup
+```
+
+Also check if CLAUDE.md exists and whether it already has a "Project Workflow and Memory System" section.
+
+## STEP 2: CREATE MEMORY FILES
+
+Create the directory structure and initialize memory files:
+
+```
+docs/
+└── project_notes/
+    ├── trunk/
+    ├── branches/
+    ├── project_map.md
+    ├── bugs.md
+    ├── decisions.md
+    ├── key_facts.md
+    ├── issues.md
+    └── .project-memory-state.json
+```
+
+Create `docs/project_notes/trunk/` and `docs/project_notes/branches/` as empty directories. Write a `.gitkeep` placeholder to each so they are tracked by git.
+
+For each file, use the Read tool to read the template, then use Write to create the target:
+
+| Template Source | Target File |
+|----------------|-------------|
+| `references/bugs_template.md` | `docs/project_notes/bugs.md` |
+| `references/decisions_template.md` | `docs/project_notes/decisions.md` |
+| `references/key_facts_template.md` | `docs/project_notes/key_facts.md` |
+| `references/issues_template.md` | `docs/project_notes/issues.md` |
+| `references/project_map_template.md` | `docs/project_notes/project_map.md` |
+
+The project map template is a scaffold — compose and design fill it with real content during the workflow.
+
+Do NOT create workflow output files (discovery_brief.md, tasks.json, etc.). Those are created by their respective skills.
+
+## STEP 3: CREATE STATE FILE
+
+Read `references/state_template.json` and write to `docs/project_notes/.project-memory-state.json`.
+
+The state file uses the Enuncia v11 schema:
+
+```json
+{
+  "initialized": true,
+  "version": "11.0",
+  "pipeline": "enuncia",
+  "active_context": "trunk",
+  "trunk": {
+    "status": "none",
+    "workflow": {
+      "discovery": {
+        "started": false,
+        "completed": false,
+        "completed_at": null
+      },
+      "compose": {
+        "started": false,
+        "completed": false,
+        "completed_at": null
+      },
+      "design": {
+        "started": false,
+        "completed": false,
+        "completed_at": null
+      },
+      "execute": {
+        "started": false,
+        "completed": false,
+        "completed_at": null
+      },
+      "verify": {
+        "started": false,
+        "completed": false,
+        "completed_at": null
+      }
+    }
+  },
+  "branches": {},
+  "last_handoff": null,
+  "last_handoff_transition": null
+}
+```
+
+## STEP 4: UPDATE CLAUDE.MD
+
+Read `references/claude_template.md` for the Enuncia workflow protocol content.
+
+```
+IF CLAUDE.md does NOT exist:
+  → Create CLAUDE.md with the template content
+
+IF CLAUDE.md exists BUT has no "Project Workflow and Memory System" section:
+  → Append the template content to the end of the file
+
+IF CLAUDE.md exists AND already has the section:
+  → Skip (do not overwrite)
+```
+
+## STEP 4.5: CREATE INTUITION.MD
+
+Read `references/intuition_readme_template.md` and write to `INTUITION.md` at the project root.
+
+```
+IF INTUITION.md does NOT exist:
+  → Create it from template
+
+IF INTUITION.md already exists:
+  → Skip
+```
+
+## STEP 5: CREATE CONFIGURATION FILES
+
+Auto-create each file if it does not exist. Do NOT ask — just create. If a file already exists, skip it silently.
+
+### 5A: Claude Code Settings
+
+- Read `references/settings_template.json`
+- If `.claude/settings.local.json` does not exist: create from template
+- If `.claude/settings.local.json` exists: skip
+
+### 5B: User Profile
+
+- Read `references/user_profile_template.json`
+- If `.claude/USER_PROFILE.json` does not exist: create from template
+- If `.claude/USER_PROFILE.json` exists: skip
+
+## STEP 6: REPORT COMPLETION
+
+Present a concise summary of what was created vs skipped:
+
+```
+Enuncia pipeline initialized!
+
+Created:
+- [list each file that was created]
+
+Skipped (already existed):
+- [list each file that was skipped, if any]
+
+Next step: Run /intuition-enuncia-discovery to start defining your project,
+or /intuition-enuncia-start to check project status.
+```
+
+## EDGE CASES
+
+- **Partial setup exists**: Check each file individually. Only create missing files.
+- **CLAUDE.md has custom content**: Append the workflow section. Do not replace the entire file.
+- **Git-tracked project**: Memory files in `docs/project_notes/` are safe to commit. Settings in `.claude/` are typically gitignored.
+- **Classic pipeline state exists**: If `.project-memory-state.json` exists with a non-enuncia pipeline, warn the user: "This project has an existing classic pipeline state. Overwriting will reset workflow tracking. Proceed?" Only overwrite if confirmed.
+
+## REFERENCE FILES
+
+These template files are in the `references/` directory. Use Read tool to access them:
+
+**Memory file templates** (Step 2):
+- `bugs_template.md`, `decisions_template.md`, `key_facts_template.md`, `issues_template.md`, `project_map_template.md`
+
+**State template** (Step 3):
+- `state_template.json` — Enuncia v11 workflow state
+
+**Framework overview** (Step 4.5):
+- `intuition_readme_template.md`
+
+**Configuration templates** (Steps 4-5):
+- `claude_template.md` — Enuncia memory protocols for CLAUDE.md
+- `settings_template.json` — pre-authorized tools for Claude Code
+- `user_profile_template.json` — cross-project user context