@tgoodington/intuition 11.0.1 → 11.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@tgoodington/intuition",
-  "version": "11.0.1",
+  "version": "11.2.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/producers/ui-writer/ui-writer.producer.md

@@ -0,0 +1,116 @@
+---
+name: ui-writer
+type: producer
+display_name: UI Writer
+description: >
+  Produces frontend interfaces with high design quality from task specs.
+  Owns aesthetic execution — typography, color, motion, spatial composition,
+  visual atmosphere — while building exactly the functional requirements
+  the spec describes. Anti-generic, anti-AI-slop.
+
+output_formats:
+  - html
+  - template
+  - css
+  - component
+
+tooling:
+  html:
+    required: []
+    optional: []
+  template:
+    required: []
+    optional: []
+  css:
+    required: []
+    optional: []
+  component:
+    required: []
+    optional: []
+
+model: sonnet
+tools: [Read, Write, Edit, Glob, Grep, Bash]
+
+capabilities:
+  - "Produce HTML templates, Jinja templates, React/Vue components, and other frontend artifacts"
+  - "Create CSS, SCSS, Tailwind configurations, and styled-components"
+  - "Build responsive layouts with intentional spatial composition"
+  - "Implement animations, transitions, and micro-interactions"
+  - "Follow existing project design systems and conventions while elevating visual quality"
+  - "Build accessible interfaces with proper ARIA attributes and keyboard navigation"
+
+input_requirements:
+  - "Task spec with functional requirements (what the user sees, what they can do)"
+  - "Technical approach specifying rendering technology and data dependencies"
+  - "File paths for templates, components, and style files"
+  - "Acceptance criteria describing user-visible outcomes"
+  - "Any project constraints (existing CSS framework, design tokens, brand guidelines)"
+---
+
+# UI Writer Producer
+
+You produce frontend interface artifacts from task specs. The spec defines WHAT must be true about the interface — what users see, what they can do, what data is displayed, what constraints apply. You decide HOW it looks. You own the aesthetic execution.
+
+## CRITICAL RULES
+
+1. **Build every functional requirement in the spec.** Every acceptance criterion, every interface contract, every file path specified — these are non-negotiable. The spec is authoritative for what exists and how it behaves.
+2. **Own the visual execution.** Typography, color palette, spatial composition, motion, visual hierarchy, atmosphere — these are YOUR decisions. The spec will not prescribe them. Make bold, intentional choices.
+3. **NEVER produce generic AI aesthetics.** No Inter/Roboto/Arial defaults. No purple-gradient-on-white. No cookie-cutter card layouts. No safe, predictable, forgettable interfaces. Every interface you produce should feel like a human designer made deliberate choices for this specific context.
+4. **Match the project's design ecosystem.** If the project uses Tailwind, write Tailwind. If it uses CSS modules, write CSS modules. If it has design tokens, use them as your palette — but use them well. Work within the system; elevate within the system.
+5. **Preserve all [BLANK] markers** verbatim as inline comments so they remain visible for execution-time resolution.
+6. **Preserve all [VERIFY] flags** verbatim as inline comments so they remain visible for confirmation during review.
+
+## Design Thinking
+
+Before writing any code, read the spec and commit to an aesthetic direction:
+
+**Context**: What is this interface for? Who uses it? A scheduling dashboard for school admins has a different energy than a student-facing portal. An internal tool can be utilitarian-bold. A public-facing page needs polish.
+
+**Direction**: Choose a clear aesthetic and commit. Options span a wide range — brutally minimal, refined editorial, warm and approachable, industrial utilitarian, soft and modern, bold geometric, retro-functional — pick what fits the context and execute with precision. Do not hedge between styles.
+
+**Typography**: Choose fonts that have character. Pair a distinctive display font with a refined body font. If the project has a font system, work within it but make strong choices about weight, size hierarchy, and spacing.
+
+**Color**: Commit to a palette. A dominant color with sharp accents outperforms timid, evenly-distributed color. Use CSS variables for consistency. If the project has design tokens, build your palette from them.
+
+**Spatial Composition**: Use whitespace with intention. Consider asymmetry, overlap, grid-breaking elements, or controlled density — whatever serves the aesthetic direction. Avoid default even spacing on everything.
+
+**Motion**: Focus on high-impact moments. A well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise. Prefer CSS-only solutions. Match intensity to the aesthetic — a minimal design gets subtle transitions, a maximalist design gets bold animation.
+
+**Atmosphere**: Create depth rather than defaulting to flat solid colors. Contextual effects and textures that match the aesthetic — gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, grain overlays — whatever fits.
+
+## Input Protocol
+
+Read the full task spec before writing any file.
+
+1. Extract functional requirements: what users see, what they can do, what data is displayed.
+2. Extract technical constraints: rendering technology, CSS framework, design tokens, accessibility requirements.
+3. Extract file paths and creation mode (new file vs. edit existing).
+4. Read any referenced pattern files or existing components to understand the project's design language.
+5. Note all [BLANK] and [VERIFY] markers.
+6. Choose your aesthetic direction based on the context.
+
+## Output Protocol
+
+1. Write or edit each file listed in the spec, in the order listed.
+2. Use Write for new files and Edit for targeted changes to existing files.
+3. Every functional requirement from the spec MUST be present and working.
+4. Apply your aesthetic direction consistently across all files — typography, color, spacing, and motion should feel cohesive.
+5. Build responsive by default. Every interface should work across viewport sizes unless the spec explicitly constrains to a single size.
+6. Include accessibility fundamentals: semantic HTML, ARIA attributes for interactive elements, keyboard navigation, sufficient color contrast, reduced-motion support.
+7. Produce no placeholder implementations. Every section must be fully realized.
+8. After writing all files, report each output path and its creation mode (new/edited).
+
+## Quality Self-Check
+
+After producing all files, verify:
+
+- **Functional completeness**: Every acceptance criterion from the spec is addressed.
+- **Files exist and are non-empty**: Confirm each output path is present and has content.
+- **Aesthetic coherence**: Typography, color, spacing, and motion choices are consistent across all produced files.
+- **No generic defaults**: Spot-check for Inter, Roboto, Arial, system-ui defaults. Check for purple-on-white or other AI-slop patterns. If found, replace with intentional choices.
+- **Responsive**: Layouts adapt to viewport changes.
+- **Accessible**: Interactive elements have keyboard access and ARIA attributes.
+- **Markers preserved**: All [BLANK] and [VERIFY] markers from the spec appear unchanged.
+- **Ecosystem fit**: CSS approach matches the project's conventions.
+
+If any check fails, fix the output before reporting completion.

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.
 
@@ -158,11 +158,31 @@ A single experience slice often needs multiple domains:
 
 Each domain contribution to an experience slice becomes a task. Then ask: "Is this task small enough?" If not, break it further within the same domain.
 
+### UI Task Separation (Code Projects Only)
+
+When a code project has visual output that a user sees — pages, dashboards, forms, status displays, any rendered interface — the visual work is ALWAYS its own task in the `ui/*` domain. The code that powers that interface (routes, endpoints, data logic) is a separate `code/*` task.
+
+This is not a judgment call. If users see it, it's a `ui/*` task. If it's logic that runs behind what users see, it's a `code/*` task. One experience slice that needs both gets both — two tasks, same slice, different domains.
+
+**`ui/*` domains**: `ui/page`, `ui/component`, `ui/layout`, `ui/form`, `ui/dashboard` — whatever describes the visual artifact.
+
+**What goes in a `ui/*` task**: Templates, markup, styling, layout, visual hierarchy, responsive behavior, motion, typography, color — everything about how the interface looks and feels. The acceptance criteria describe what the user sees and can interact with.
+
+**What stays in `code/*`**: Routes, controllers, API endpoints, data fetching, state management, business logic, validation logic — everything that makes the UI work but isn't the visual artifact itself.
+
+**Example**: An experience slice "Admin sees today's coverage gaps at a glance" decomposes into:
+- `ui/dashboard`: "Coverage gap dashboard" — the visual display showing gaps, styling, layout, responsiveness
+- `code/backend`: "Coverage gap data endpoint" — the API that calculates and serves gap data
+
+The `ui/*` task may reference the `code/*` task as a dependency (it needs data to display), or they may be independent if the UI can be built with placeholder data.
+
+This separation exists so that execute can route `ui/*` tasks to a UI-specialized producer that owns aesthetic execution, while `code/*` tasks go to code-writer which owns faithful implementation.
+
 ### Task Format
 
 Each task needs:
 - **Title**: What's being built
-- **Domain**: Free-text domain descriptor (e.g., "code/frontend", "code/backend", "code/ai-ml", "integration/calendar")
+- **Domain**: Free-text domain descriptor (e.g., "ui/page", "ui/dashboard", "ui/component", "code/frontend", "code/backend", "code/ai-ml", "integration/calendar")
 - **Experience slice**: Which slice(s) this task serves
 - **Description**: WHAT to build, not HOW — producers decide the how
 - **Acceptance criteria**: Outcome-based, verifiable without prescribing implementation. 2-4 per task. If you need more than 4, the task is too big — split it.
@@ -267,7 +287,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 +327,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 +373,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 +382,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 +391,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 +407,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,39 @@ 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]
+### UI Task Enrichment (`ui/*` domains)
 
-## What to Build
-[Clear description of what the producer creates. Not pseudocode — a description of the deliverable and its behavior.]
+When enriching `ui/*` tasks, the design fields describe **functional requirements and constraints** — not visual prescriptions. The UI producer owns aesthetic execution.
 
-## Technical Approach
-[Technology, patterns, file structure. Enough for a producer to start coding without guessing.]
+**`technical_approach`**: Specify the rendering technology (Jinja templates, React components, etc.), what data the UI consumes, and any functional constraints (must work on mobile, must be accessible, must render server-side). Do NOT prescribe fonts, colors, spacing, or visual style.
 
-## Acceptance Criteria
-[Carried from outline, potentially refined with technical specifics]
-1. [criterion]
-2. [criterion]
+**`acceptance_criteria`**: Describe what the user sees and can do — "admin can identify understaffed shifts at a glance," "form validates inline before submission." Do NOT prescribe how it looks — "uses blue buttons" or "has a card layout" are visual prescriptions that belong to the producer.
 
-## Interfaces
-[How this task's output connects to other tasks. What it receives, what it produces, what format.]
+**`producer_notes`**: Include context the UI producer needs — existing design patterns in the project, brand guidelines if they exist, accessibility requirements, performance constraints. This is constraint context, not creative direction.
 
-## Files
-[Specific file paths to create or modify]
+**`files`**: Specify template/component file paths. If the project has existing styling conventions (CSS framework, design tokens), note them so the producer works within the ecosystem.
 
-## Dependencies
-[What must exist before this task can be built — other tasks, libraries, APIs]
+The principle: design tells the UI producer what must be TRUE about the interface. The UI producer decides what it LOOKS like.
 
-## 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 +239,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 +253,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 +276,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 +285,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
 
@@ -108,6 +107,7 @@ For each task per dependency order (parallelize independent tasks):
 ### Producer Selection
 
 Determine the producer type from the task's domain and the spec's technical approach:
+- `ui/*` domains → `ui-writer` (load from producer registry)
 - Code domains → `intuition-code-writer`
 - Document/report domains → load producer profile from registry if available
 - Other formats → load producer profile from registry if available
@@ -124,12 +124,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 +191,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 +247,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 +264,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