@tgoodington/intuition 8.1.3 → 9.2.0

package/skills/intuition-handoff/references/handoff_core.md

@@ -18,7 +18,7 @@ As part of every handoff, extract user profile learnings and update the global u
 
 ### Discovery → Planning Handoff (User Profile Focus)
 
-**From discovery_output.json**, extract `user_profile_learnings`:
+**From prompt_output.json**, extract `user_profile_learnings`:
 
 ```json
 {
@@ -37,7 +37,7 @@ As part of every handoff, extract user profile learnings and update the global u
 
 **Update `.claude/USER_PROFILE.json`:**
 1. Read existing `.claude/USER_PROFILE.json` (may be empty initially)
-2. Merge in new learnings from `discovery_output.json`:
+2. Merge in new learnings from `prompt_output.json`:
    - If a field is `null` in profile and has value in learnings, add it
    - If field is populated in profile, only overwrite if discovery_confidence is "high"
    - Always update `metadata.last_updated` timestamp
@@ -96,7 +96,7 @@ Check `.project-memory-state.json` to determine current state:
       "started": true,
       "completed": true,
       "completed_at": "2025-02-02T...",
-      "output_files": ["discovery_brief.md", "discovery_output.json"]
+      "output_files": ["prompt_brief.md", "prompt_output.json"]
     },
     "planning": {
       "started": false,
@@ -111,10 +111,10 @@ Check `.project-memory-state.json` to determine current state:
 ### Step 1: Read Outputs
 
 ```
-discovery_brief.md
+prompt_brief.md
   └─ Human-readable summary of discovery
 
-discovery_output.json
+prompt_output.json
   └─ Structured data for handoff:
      {
        "key_facts_to_add": [...],
@@ -127,11 +127,11 @@ discovery_output.json
 
 ### Step 2: Extract and Structure Findings
 
-From `discovery_output.json`, extract:
+From `prompt_output.json`, extract:
 
 **Key Facts** (for key_facts.md):
 ```
-Example from discovery_output.json:
+Example from prompt_output.json:
 {
   "category": "User Base",
   "fact": "Scaling to support 10,000 concurrent users",
@@ -165,7 +165,7 @@ if they represent architectural choices.
 
 **Suggested Decisions** (for decisions.md):
 ```
-discovery_output.json might suggest:
+prompt_output.json might suggest:
 {
   "suggested_decisions": [
     {
@@ -223,7 +223,7 @@ operations, with write operations on primary instance.
 **Update issues.md:**
 - Log the discovery work completed
 - Format: Date - Brief description - Status
-- Include discovery_brief.md link
+- Include prompt_brief.md link
 
 Example:
 ```markdown
@@ -232,7 +232,7 @@ Example:
 - **Status**: Completed
 - **Description**: Explored user base growth, authentication patterns,
   scalability needs
-- **Discovery Brief**: docs/project_notes/discovery_brief.md
+- **Discovery Brief**: docs/project_notes/prompt_brief.md
 - **Key Findings**:
   - Must scale to 10k concurrent users
   - Prefer JWT-based auth
@@ -271,7 +271,7 @@ Create a brief that synthesizes discovery for planning. Structure:
 - Risk: [Y] - Should be explored during planning
 
 ## References
-- Discovery Brief: docs/project_notes/discovery_brief.md
+- Discovery Brief: docs/project_notes/prompt_brief.md
 - Relevant Decisions: ADR-001, ADR-002
 
 ## Notes for Planner
@@ -406,7 +406,7 @@ Create a brief for execution. Structure:
 
 ## References
 - Full Plan: docs/project_notes/plan.md
-- Discovery Brief: docs/project_notes/discovery_brief.md
+- Discovery Brief: docs/project_notes/prompt_brief.md
 - Relevant Decisions: ADR-001, ADR-002, ...
 
 ## Notes for Executor
@@ -485,7 +485,7 @@ implementation."
 **Consequences:**
 [Benefits and trade-offs]
 
-**Discovered During**: Discovery phase (discovery_brief.md)
+**Discovered During**: Discovery phase (prompt_brief.md)
 **Confidence**: High/Medium/Low
 ```
 
@@ -506,12 +506,12 @@ implementation."
 
 ## Edge Cases
 
-### What if discovery_output.json doesn't exist?
+### What if prompt_output.json doesn't exist?
 
 ```
-1. Check if discovery_brief.md exists
+1. Check if prompt_brief.md exists
 2. If yes: Read brief manually and extract key insights
-3. Summarize into a simple discovery_output.json structure
+3. Summarize into a simple prompt_output.json structure
 4. Proceed with handoff
 5. Note: Less structured, but handoff still works
 ```

package/skills/intuition-initialize/SKILL.md

@@ -15,7 +15,7 @@ You create the `docs/project_notes/` directory structure, initialize memory file
 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 for all initial content. Read each template with the Read tool, then Write to the target path.
-4. You MUST create `.project-memory-state.json` using the v5.0 schema from `references/state_template.json`. Do NOT use older schemas.
+4. You MUST create `.project-memory-state.json` using the v7.0 schema from `references/state_template.json`. Do NOT use older schemas.
 5. You MUST auto-create all configuration files (CLAUDE.md, INTUITION.md, AGENTS.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.
@@ -27,7 +27,7 @@ You create the `docs/project_notes/` directory structure, initialize memory file
 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 v5.0 schema
+Step 3: Create .project-memory-state.json with v7.0 schema
 Step 4: Update CLAUDE.md with workflow protocols
 Step 4.5: Create INTUITION.md framework overview
 Step 5: Create configuration files (AGENTS.md, settings, user profile)
@@ -111,18 +111,18 @@ For each file, use the Read tool to read the template, then use Write to create
 | `references/key_facts_template.md` | `docs/project_notes/key_facts.md` |
 | `references/issues_template.md` | `docs/project_notes/issues.md` |
 
-Do NOT create workflow output files (discovery_brief.md, plan.md, etc.). Those are created by their respective skills.
+Do NOT create workflow output files (prompt_brief.md, plan.md, 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 v5.0 schema:
+The state file uses the v7.0 schema:
 
 ```json
 {
   "initialized": true,
-  "version": "5.0",
+  "version": "7.0",
   "active_context": "trunk",
   "trunk": {
     "status": "none",
@@ -156,6 +156,21 @@ The state file uses the v5.0 schema:
         "started": false,
         "completed": false,
         "completed_at": null
+      },
+      "test": {
+        "started": false,
+        "completed": false,
+        "completed_at": null,
+        "skipped": false
+      },
+      "detail": {
+        "started": false,
+        "completed": false,
+        "completed_at": null,
+        "team_assignment": null,
+        "specialists": [],
+        "current_specialist": null,
+        "execution_phase": 1
       }
     }
   },

package/skills/intuition-initialize/references/state_template.json

@@ -1,6 +1,6 @@
 {
   "initialized": true,
-  "version": "5.0",
+  "version": "7.0",
   "active_context": "trunk",
   "trunk": {
     "status": "none",
@@ -34,6 +34,21 @@
         "started": false,
         "completed": false,
         "completed_at": null
+      },
+      "test": {
+        "started": false,
+        "completed": false,
+        "completed_at": null,
+        "skipped": false
+      },
+      "detail": {
+        "started": false,
+        "completed": false,
+        "completed_at": null,
+        "team_assignment": null,
+        "specialists": [],
+        "current_specialist": null,
+        "execution_phase": 1
       }
     }
   },

package/skills/intuition-plan/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: intuition-plan
-description: Strategic architect. Reads discovery brief, engages in interactive dialogue to map stakeholders, explore components, evaluate options, synthesize an executable blueprint, and flag tasks requiring design exploration.
+description: Strategic architect. Reads prompt brief, engages in interactive dialogue to map stakeholders, explore components, evaluate options, synthesize an executable blueprint, and flag tasks requiring design exploration.
 model: opus
 tools: Read, Write, Glob, Grep, Task, AskUserQuestion, Bash, WebFetch
 allowed-tools: Read, Write, Glob, Grep, Task, Bash, WebFetch
@@ -11,8 +11,8 @@ allowed-tools: Read, Write, Glob, Grep, Task, Bash, WebFetch
 These are non-negotiable. Violating any of these means the protocol has failed.
 
 1. You MUST read `.project-memory-state.json` on startup to determine `active_context` and resolve `context_path`. Use context_path for ALL file reads and writes.
-2. You MUST read `{context_path}/discovery_brief.md` before planning. If missing, stop and tell the user to run `/intuition-prompt`.
-3. You MUST launch orientation research agents during Intake, after reading the discovery brief but BEFORE your first AskUserQuestion.
+2. You MUST read `{context_path}/prompt_brief.md` before planning. If missing, stop and tell the user to run `/intuition-prompt`.
+3. You MUST launch orientation research agents during Intake, after reading the prompt brief but BEFORE your first AskUserQuestion.
 4. You MUST use ARCH coverage tracking. Homestretch only unlocks when Actors, Reach, and Choices are sufficiently explored.
 5. You MUST ask exactly ONE question per turn via AskUserQuestion. For decisional questions, present 2-3 options with trade-offs. For informational questions (gathering facts, confirming understanding), present relevant options but trade-off analysis is not required.
 6. You MUST get explicit user approval before saving the plan.
@@ -21,10 +21,10 @@ These are non-negotiable. Violating any of these means the protocol has failed.
 9. You MUST write interim artifacts to `{context_path}/.planning_research/` for context management.
 10. You MUST validate against the Executable Plan Checklist before presenting the draft plan.
 11. You MUST present 2-4 sentences of analysis BEFORE every question. Show your reasoning.
-12. You MUST NOT modify `discovery_brief.md` or `planning_brief.md`.
+12. You MUST NOT modify `prompt_brief.md` or `planning_brief.md`.
 13. You MUST NOT manage `.project-memory-state.json` — handoff owns state transitions.
 14. You MUST treat user input as suggestions unless explicitly stated as requirements. Evaluate critically and propose alternatives when warranted.
-15. You MUST assess every task for design readiness and include a "Design Recommendations" section in the plan. Flag any task where execution cannot proceed without further design exploration (see DESIGN READINESS ASSESSMENT below).
+15. You MUST assess every task for readiness and include a Detail Assessment (Section 6.5) classifying every task by domain and depth.
 16. When planning on a branch, you MUST read the parent context's plan.md and include a Parent Context section (Section 2.5). Inherited architectural decisions from the parent are binding unless the user explicitly overrides them.
 17. You MUST NEVER proceed past a research agent launch until its results have returned and been incorporated into your analysis. Do NOT draft options, present findings, or write any output document while a research agent is still running.
 
@@ -66,7 +66,7 @@ Phase 1:   INTAKE           (1 turn)     Read context, launch research, greet, b
 Phase 2:   ACTORS & SCOPE   (1-2 turns)  Map stakeholders, identify tensions [ARCH: A]
 Phase 2.5: DEPTH SELECTION  (1 turn)     User chooses planning depth tier
 Phase 3:   REACH & CHOICES  (variable)   Scope components, resolve decisions [ARCH: R + C]
-Phase 4:   HOMESTRETCH      (1-2 turns)  Draft blueprint, validate, present [ARCH: H]
+Phase 4:   HOMESTRETCH      (1-3 turns)  Draft blueprint, validate, present, decision review [ARCH: H]
 Phase 5:   FORMALIZATION    (1 turn)     Save plan.md, route to handoff
 ```
 
@@ -87,11 +87,11 @@ This phase is exactly 1 turn. Execute all of the following before your first use
 ## Step 1: Read inputs
 
 Read these files:
-- `{context_path}/discovery_brief.md` — REQUIRED. If missing, stop immediately: "No discovery brief found. Run `/intuition-prompt` first."
+- `{context_path}/prompt_brief.md` — REQUIRED. If missing, stop immediately: "No prompt brief found. Run `/intuition-prompt` first."
 - `{context_path}/planning_brief.md` — optional, may contain handoff context.
 - `.claude/USER_PROFILE.json` — optional, for tailoring communication style.
 
-From the discovery brief, extract: core problem, success criteria, stakeholders, constraints, scope, assumptions, and research insights.
+From the prompt brief, extract: core problem, success criteria, stakeholders, constraints, scope, assumptions, research insights, commander's intent, and decision posture.
 
 ## Step 2: Launch orientation research
 
@@ -156,14 +156,14 @@ When `active_context` is NOT trunk:
 Prompt:
 "The project root is the current working directory. Compare two workflow artifacts:
 
-1. Read the discovery brief at {context_path}/discovery_brief.md.
+1. Read the prompt brief at {context_path}/prompt_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.
+3. For each file path mentioned in the parent plan's tasks, check if the prompt 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.
+5. Identify acceptance criteria in the parent plan that touch the same areas as the prompt brief.
 
 Report on:
-(1) Shared files/components that both parent plan and this branch's discovery brief touch
+(1) Shared files/components that both parent plan and this branch's prompt 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
@@ -176,7 +176,7 @@ Write results to `{context_path}/.planning_research/parent_intersection.md`.
 
 In a single message:
 1. Introduce your role as the planning architect in one sentence.
-2. Summarize your understanding of the discovery brief in 3-4 sentences.
+2. Summarize your understanding of the prompt brief in 3-4 sentences.
 3. Present the stakeholders you identified from the brief and orientation research.
 4. Ask your first question via AskUserQuestion — about stakeholders. Are these the right actors? Who is missing?
 
@@ -186,7 +186,7 @@ This is the only turn in Phase 1.
 
 Goal: Map all stakeholders and identify tensions between their needs.
 
-- Present stakeholders identified from the discovery brief and orientation research.
+- Present stakeholders identified from the prompt brief and orientation research.
 - Ask the user to confirm, adjust, or expand the list.
 - Push back if the stakeholder list seems incomplete. If the project affects end users but no end-user perspective is listed, say so.
 - Identify tensions between stakeholder needs (e.g., "Engineering wants speed but QA needs coverage — we'll need to balance that").
@@ -196,7 +196,7 @@ When actors are sufficiently mapped (user has confirmed or adjusted), transition
 
 # PHASE 2.5: DEPTH SELECTION (1 turn)
 
-Based on the scope revealed by the discovery brief and actors discussion, recommend a planning depth tier:
+Based on the scope revealed by the prompt brief and actors discussion, recommend a planning depth tier:
 
 - **Lightweight** (1-4 tasks): Focused scope, few unknowns. Plan includes: Objective, Discovery Summary, Task Sequence, Execution Notes.
 - **Standard** (5-10 tasks): Moderate complexity. Adds: Technology Decisions, Testing Strategy, Risks & Mitigations.
@@ -213,7 +213,28 @@ The selected tier governs:
 
 Goal: Identify what the plan touches (Reach) and resolve every major decision (Choices).
 
-For each major decision domain identified from the discovery brief, orientation research, and dialogue:
+## Decision Boundary Test
+
+Before presenting any decision question to the user, apply this gate:
+
+1. **Does this decision change the task breakdown?** If removing one option would add, remove, or fundamentally restructure tasks — it's plan-level. Resolve it here.
+2. **Does this decision ripple across multiple tasks?** If the answer constrains or reshapes work in 2+ tasks — it's plan-level. Resolve it here.
+
+If NEITHER condition is met, the decision is specialist-level. Do NOT resolve it during planning. Instead:
+- Note it as a `[USER]` or `[SPEC]` decision on the relevant task (using the 2x2 heuristic)
+- Add it to Section 10 as an open question tagged by domain
+- Move on to the next planning-level concern
+
+When in doubt, defer. A specialist with loaded domain expertise will make a better-informed decision than the planning phase can. Over-resolving during planning robs the detail phase of its purpose.
+
+**Examples:**
+- "Structured state model vs text-based manipulation" → changes how 3+ tasks are structured → **plan-level, resolve here**
+- "What happens when no valid path exists" → single task's error handling → **specialist-level, defer**
+- "How should output be formatted" → single task's rendering detail → **specialist-level, defer**
+
+3. **Explain for the creative director.** When presenting a plan-level decision, assume the user has zero domain background. Explain what each option means in plain language — what it does, what it costs, and why you recommend one. If you cannot explain the trade-off without jargon, you don't understand it well enough to ask yet.
+
+For each major decision domain identified from the prompt brief, orientation research, and dialogue:
 
 1. **Identify** the decision needed. State it clearly.
 2. **Research** (when needed): Launch 1-2 targeted research agents via Task tool.
@@ -281,6 +302,24 @@ Run the Executable Plan Checklist (below). Fix any failures before presenting.
 
 Present a summary: total tasks, key decisions that shaped the plan, judgment calls you made, notable risks. Ask via AskUserQuestion: "Does this plan look right?" Options: "Approve as-is" / "Needs changes".
 
+## Step 4b: Decision review
+
+After the user approves the plan content (Step 4), present all `[USER]` and `[SPEC]` decisions in a single summary and ask via AskUserQuestion:
+
+"Here are the decisions I'd surface to you during detail/build work. Want to reclassify any?"
+
+- Header: "Decisions"
+- Options:
+  - "Looks right"
+  - "I want to reclassify some"
+  - "Give me more control" — shifts all `[SPEC]` → `[USER]`
+  - "Give the team more autonomy" — shifts all `[USER]` on easy-to-reverse items → `[SPEC]`
+
+If they want to reclassify, address specific changes (1 turn max), then proceed.
+If no tasks have classified decisions, skip this step entirely.
+
+This is the ONE exception to "one question per turn" — it happens on a separate turn after plan approval.
+
 ## Step 5: Iterate
 
 If changes requested, make them and present again. Repeat until explicitly approved.
@@ -291,7 +330,7 @@ After explicit approval:
 
 1. Write the final plan to `{context_path}/plan.md`.
 2. Tell the user: "Plan saved to `{context_path}/plan.md`. Next step: Run `/intuition-handoff` to transition to the next phase."
-3. ALWAYS route to `/intuition-handoff`. NEVER suggest `/intuition-execute`.
+3. ALWAYS route to `/intuition-handoff`.
 
 # PLAN.MD OUTPUT FORMAT (Plan-Execute Contract v1.0)
 
@@ -301,7 +340,7 @@ After explicit approval:
 - **Standard**: Sections 1, 2, 3, 6, 6.5, 7, 8, 10
 - **Comprehensive**: All sections (1-10, including 6.5)
 
-Section 6.5 is Design Recommendations — ALWAYS included regardless of tier.
+Section 6.5 (Detail Assessment) is ALWAYS included regardless of tier.
 Section 2.5 is Parent Context — included for ALL tiers when on a branch.
 
 ## Section Specifications
@@ -349,16 +388,30 @@ Ordered list forming a valid dependency DAG. Each task:
 
 ```markdown
 ### Task [N]: [Title]
-- **Component**: [which architectural component]
+- **Domain**: [free-text domain descriptor — e.g., "code/backend", "legal/regulatory", "marketing/copy"]
+- **Depth**: Deep | Standard | Light
+- **Component**: [which architectural component or project area]
 - **Description**: [WHAT to do, not HOW — execution decides HOW]
 - **Acceptance Criteria**:
   1. [Outcome-based criterion — verifiable without prescribing implementation]
   2. [Outcome-based criterion]
   [minimum 2 per task]
 - **Dependencies**: [Task numbers] or "None"
+- **Decisions**: (include only when classified decision points exist)
+  - `[USER]` [decision description] — [one-line rationale]
+  - `[SPEC]` [decision description] — [one-line rationale]
 - **Files**: [Specific paths when known] or "TBD — [component area]"
 ```
 
+`[SILENT]` decisions are NOT listed — they are silent by definition. Omit the Decisions field entirely for tasks with no classified decision points (pure mechanical work).
+
+Domain and Depth are included for every task. Domain is a free-text descriptor — the plan does NOT reference specialist names. Team assembly matches domains to specialists later.
+
+Depth controls specialist invocation:
+- **Deep** — full exploration → user confirmation gate → specification. For novel territory, multiple valid approaches, or high-stakes decisions.
+- **Standard** — research → 1-2 confirmation questions → blueprint. For clear paths with a few key decisions.
+- **Light** — research → blueprint produced autonomously. For straightforward, pattern-following tasks.
+
 **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)
@@ -378,61 +431,84 @@ 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 Engineer (always)
-Context and considerations for the engineering phase — NOT instructions. Engineer owns all implementation decisions.
+### 10. Planning Context for Detail Phase (always)
 
-- **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
+- **Domain-Specific Considerations**: per-domain notes — legal constraints, brand guidelines, data quality issues, performance targets
+- **Cross-Domain Dependencies**: where specialist outputs must coordinate
+- **Sequencing Considerations**: what depends on what across domains
+- **Open Questions**: questions the detail phase must resolve, tagged by domain
+- **Constraints**: hard boundaries per domain
+- **Decision Policy**: summary of the user's posture (hands-on vs. delegator) and any global overrides from the decision review step
 
-## Architect-Engineer Boundary
+The planning phase decides WHAT. The detail and build phases decide HOW.
 
-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.
+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.
 
-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.
+# DETAIL READINESS ASSESSMENT
 
-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.
+After drafting the task sequence, assess every task for readiness.
 
-# DESIGN READINESS ASSESSMENT
+## Detail Assessment
 
-After drafting the task sequence, evaluate EVERY task for design readiness. A task is "ready for execution" if it is 95% clear — execution can fill in the remaining 5% without making design decisions.
+Every task gets a domain assignment and depth classification.
 
-## Flagging Criteria
+### Depth Classification Criteria
 
-Flag a task as **DESIGN REQUIRED** if ANY of these apply:
+Assign **Deep** depth if ANY of these apply:
+- Novel territory with no existing pattern to follow
+- Multiple valid approaches where the choice has lasting consequences
+- User-facing decisions requiring stakeholder input
+- Complex cross-domain interactions needing explicit definition
+- High-stakes decisions where getting it wrong is costly to reverse
 
-- **Novel territory**: No existing pattern in the project to follow. The implementation approach needs to be invented, not just applied.
-- **Multiple valid approaches**: There are 2+ reasonable ways to build this, and the choice has lasting consequences. Execution shouldn't make this call.
-- **User-facing decisions**: The task involves layout, creative direction, user experience, tone, or aesthetic choices the user should weigh in on.
-- **Complex interactions**: The task touches multiple components and the interfaces between them need explicit definition before implementation.
-- **Ambiguous scope**: The task description says WHAT but the HOW has genuine options that affect quality, performance, or maintainability.
+Assign **Standard** depth if:
+- The approach is mostly clear but has 1-2 key decisions
+- Existing patterns exist but need adaptation
+- Confirmation is needed but not deep exploration
 
-Do NOT flag tasks that are:
+Assign **Light** depth if:
 - Straightforward application of existing patterns
-- Mechanical wiring, boilerplate, or configuration
-- Well-understood implementations with clear precedent in the codebase
-- Simple enough that a competent engineer needs no design input
+- Mechanical or configuration-level work
+- Well-understood with clear precedent
 
-## Design Recommendations Output
+### Detail Assessment Output
 
-Include this section in the plan AFTER the Task Sequence (Section 6) and BEFORE Testing Strategy (Section 7):
+Include this section in the plan AFTER the Task Sequence (Section 6):
 
 ```markdown
-### Design Recommendations
+### 6.5 Detail Assessment
 
-| Task(s) | Item Name | Recommendation | Rationale |
-|---------|-----------|---------------|-----------|
-| Task 3, 4 | [Descriptive Name] | DESIGN REQUIRED | [Specific reason — what's unclear] |
-| Task 7 | [Descriptive Name] | DESIGN REQUIRED | [Specific reason] |
-| Task 1, 2 | [Name] | Ready for execution | [Why it's clear enough] |
-| Task 5, 6 | [Name] | Ready for execution | [Why it's clear enough] |
-
-**Design items group related tasks that share a design surface.** A single design session covers all tasks in the group. Items are named descriptively (e.g., "Behavior Tree AI System" not "Tasks 3-4").
+| Task(s) | Domain | Depth | Rationale |
+|---------|--------|-------|-----------|
+| Task 3, 4 | legal/regulatory | Deep — design exploration required | Novel regulatory territory, multiple valid approaches |
+| Task 7 | code/api | Standard — confirmation needed | Follows existing patterns, one key decision |
+| Task 1, 2 | code/frontend | Light — autonomous | Straightforward pattern application |
 ```
 
-When presenting the draft plan in Phase 4, explicitly call out which items you're recommending for design and why. The user confirms or adjusts during plan approval.
+When presenting the draft plan in Phase 4, explicitly call out the depth assignments and domain groupings. The user confirms or adjusts during plan approval.
+
+# DECISION CLASSIFICATION
+
+Use this reference during Phase 4 drafting to classify decision points in each task.
+
+## Tiers
+
+- `[USER]` — User decides. Surfaced during detail/build with full options.
+- `[SPEC]` — Specialist decides, user informed. Specialist picks and documents rationale.
+- `[SILENT]` — Team handles autonomously. No notification. Not listed in plan.
+
+## 2x2 Heuristic
+
+| | Hard to reverse | Easy to reverse |
+|---|---|---|
+| **Human-facing** | `[USER]` | `[USER]` |
+| **Internal** | `[SPEC]` | `[SILENT]` |
+
+## Classification Rules
+
+- Use **Commander's Intent** to determine "human-facing" — anything touching the desired end state, non-negotiables, or experiential qualities is human-facing. Without intent signals, default conservative (`[USER]`).
+- Use **Decision Posture Map** to override — areas marked "I decide" always get `[USER]`, areas marked "Team handles" can get `[SILENT]` even if human-facing + easy to reverse.
+- Cap: 2-3 classified decisions per task max. Only decisions where the tier assignment matters — not every micro-choice.
 
 # EXECUTABLE PLAN CHECKLIST
 
@@ -446,9 +522,13 @@ 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 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)
+- [ ] Planning Context for Detail Phase includes domain considerations, not prescriptive instructions
+- [ ] Detail Assessment (Section 6.5) included with every task assessed
+- [ ] Every task has Domain and Depth fields
+- [ ] Detail Assessment table (Section 6.5) covers every task
+- [ ] Section 10 includes domain-specific considerations and cross-domain dependencies
+- [ ] Tasks with decision points have Decisions field with `[USER]`/`[SPEC]` classifications
+- [ ] Decision classifications use Commander's Intent to determine human-facing boundary
 
 If any check fails, fix it before presenting.
 
@@ -478,4 +558,4 @@ Launch 1-2 agents per decision domain when dialogue reveals unknowns needing inv
 
 # DISCOVERY REVISION
 
-If `discovery_brief.md` has been updated after an existing `plan.md` was created, ask: "The discovery brief has been updated since the current plan. Would you like me to create a new plan based on the revised discovery?"
+If `prompt_brief.md` has been updated after an existing `plan.md` was created, ask: "The prompt brief has been updated since the current plan. Would you like me to create a new plan based on the revised discovery?"

package/skills/intuition-plan/references/magellan_core.md

@@ -33,7 +33,7 @@ Before planning, load the user's persistent profile:
 
 ```
 1. READ DISCOVERY
-   - Load discovery_brief.md from project memory
+   - Load prompt_brief.md from project memory
    - Understand problem, goals, users, motivations
    - Note scope boundaries and assumptions
    - Also read user_profile_learnings section for user context
@@ -77,7 +77,7 @@ Before planning, load the user's persistent profile:
 
 On activation, load from project memory:
 
-**discovery_brief.md** (`docs/project_notes/discovery_brief.md`):
+**prompt_brief.md** (`docs/project_notes/prompt_brief.md`):
 - Problem statement and context
 - Goals and success criteria
 - User personas and workflows
@@ -162,15 +162,15 @@ Create plans in this structure:
 
 ## Discovery Summary
 
-**Problem:** [From discovery_brief.md]
+**Problem:** [From prompt_brief.md]
 
-**Goals:** [From discovery_brief.md]
+**Goals:** [From prompt_brief.md]
 
-**Users:** [From discovery_brief.md]
+**Users:** [From prompt_brief.md]
 
-**Motivations:** [From discovery_brief.md]
+**Motivations:** [From prompt_brief.md]
 
-**Scope Boundaries:** [From discovery_brief.md]
+**Scope Boundaries:** [From prompt_brief.md]
 
 ---
 
@@ -280,7 +280,7 @@ Create plans in this structure:
 
 If discovery has been revised (user re-ran `/intuition-discovery`):
 
-1. **Detect revision** - Check discovery_brief.md timestamp vs. plan.md timestamp
+1. **Detect revision** - Check prompt_brief.md timestamp vs. plan.md timestamp
 2. **Notify user** - "I see the discovery brief has been updated. Would you like me to create a new plan based on the revised discovery?"
 3. **If yes** - Start fresh planning process with new discovery
 4. **If no** - Continue with existing plan

package/skills/intuition-plan/references/templates/plan_template.md

@@ -14,15 +14,15 @@
 
 ## Discovery Summary
 
-**Problem:** [From discovery_brief.md]
+**Problem:** [From prompt_brief.md]
 
-**Goals:** [From discovery_brief.md]
+**Goals:** [From prompt_brief.md]
 
-**Users:** [From discovery_brief.md]
+**Users:** [From prompt_brief.md]
 
-**Motivations:** [From discovery_brief.md]
+**Motivations:** [From prompt_brief.md]
 
-**Scope Boundaries:** [From discovery_brief.md]
+**Scope Boundaries:** [From prompt_brief.md]
 
 ---