cfsa-antigravity 3.0.2 → 3.1.0

package/template/.codex/skills/idea-extraction/SKILL.md

@@ -0,0 +1,644 @@
+---
+name: idea-extraction
+description: "Exhaustive idea extraction through recursive breadth-before-depth exploration with Deep Think protocol and fractal structure. Use during /ideate to transform raw ideas into comprehensive, structured ideation output. Writes to a fractal folder hierarchy — every node has an index, CX file, and children."
+---
+
+# Idea Extraction — Exhaustion Engine
+
+## Philosophy
+
+> This pipeline does not build MVPs. It does not produce shallow specs. It does not
+> create technical debt by rushing past the ideation phase. The ideation phase is where
+> the entire downstream pipeline gets its DNA — if the ideation is shallow, every spec,
+> every architecture decision, every line of code downstream will be shallow too.
+
+This skill is an **exhaustion engine** designed to extract every ounce of product vision
+from the user. Your job is not to collect answers. Your job is to **generate new thinking**
+in the user by asking questions they haven't considered, exploring edges they haven't
+mapped, and helping them make decisions they haven't faced yet.
+
+The **Deep Think Protocol** is the core mechanism: at every step, you actively reason
+about what *should* exist based on domain knowledge, industry patterns, and cross-domain
+interactions — then present hypotheses to the user for confirmation or rejection.
+
+---
+
+## Fractal Structure Protocol
+
+This skill writes directly to the `.memory/wiki/specs/ideation/` folder using a **fractal pattern** — every node in the tree (surface, domain, sub-domain) follows the same structure:
+
+```
+{node}/
+├── {node}-index.md       ← what's in this node, child listing, Role Matrix
+├── {node}-cx.md          ← cross-cuts connecting this node's children
+├── child-01/             ← same pattern repeats (if child is complex)
+└── 01.01.01-feature.md   ← leaf node = .md file, not a folder
+```
+
+**Key rules:**
+
+1. **Always folders.** Every domain, sub-domain, and even single-surface projects use folders — no flat files. One universal pattern, no exceptions.
+2. **Indexes at every level.** Template: `.codex/skills/prd-templates/references/fractal-node-index-template.md`
+3. **CX files at every level.** Template: `.codex/skills/prd-templates/references/fractal-cx-template.md`
+4. **Feature files are leaf nodes.** Template: `.codex/skills/prd-templates/references/fractal-feature-template.md`
+5. **Depth is reactive.** The structure grows during exploration — never pre-scaffolded beyond what's discovered.
+6. **Soft limit at 4 levels.** If creating a level 5+ node, pause and ask the user: "This is getting unusually deep — should I promote a parent to reduce nesting, or is this depth justified?"
+
+### Super-Index
+
+The top-level `ideation-index.md` uses a different template: `.codex/skills/prd-templates/references/ideation-index-template.md`
+The top-level `ideation-cx.md` uses: `.codex/skills/prd-templates/references/ideation-crosscut-template.md`
+
+### Numbering Convention
+
+Numbers are hierarchical and dot-separated within a surface:
+
+```
+{domain}.{sub-domain}.{sub-sub}.{feature}
+  01    .    01     .   02   .    03
+```
+
+- Folders use number prefix: `01.03.02-ai-assistant/`
+- Feature files use full number: `01.03.02.03-parts-recommendation.md`
+- Cross-surface references prefix with surface: `web/02.01.03`, `desktop/01.03.02`
+- Numbers are stable once assigned — never renumber
+
+---
+
+## Structural Classification Protocol
+
+> **This classification must happen BEFORE any domain files are written.**
+> It determines the folder layout for the entire ideation phase. The classification
+> is performed in `ideate-extract` (Step 1.3) and recorded in `ideation-index.md`.
+
+### Four Project Shapes
+
+| Shape | Signals | Folder Structure |
+|---|---|---|
+| **Single-surface** | One platform, one audience, "make me a website" | Domains are top-level children of `ideation/` (no `surfaces/` folder) |
+| **Multi-surface-shared** | 2+ platforms, same stack, >80% shared logic | Domains at top level with surface annotations in feature files |
+| **Multi-product (hub-and-spoke)** | 2+ platforms, one is clearly the central platform/API. Others consume from it. | `surfaces/` with hub surface owning shared domains. Spokes reference hub via CX. |
+| **Multi-product (peer)** | 2+ platforms, no clear primary. Each is equally independent. | `surfaces/` with `shared/` folder as a peer for truly cross-surface domains. |
+
+### Detection: When to Ask vs When to Detect
+
+| Input Mode | How Structure Is Determined |
+|---|---|
+| **Interview** (verbal / no input) | Ask the user directly — see Interview Questions below |
+| **Document** (rich / thin) | Scan for surface signals — see Detection Signals below |
+| **One-liner** | Infer from the description — "make me a website" = single surface, skip the question |
+
+### Interview Questions (asked early, before domain exploration)
+
+When the input doesn't make the project shape obvious, ask these questions
+**immediately after the opening problem statement question** — before any domain
+exploration or file creation:
+
+1. **"Who are the distinct user types or audiences?"**
+   - Single audience → likely single-surface
+   - Multiple distinct audiences → likely multi-product
+
+2. **"What platforms or surfaces does this need to live on?"** (web, mobile, desktop, API, CLI)
+   - One platform → single-surface
+   - Multiple platforms, same stack → multi-surface-shared
+   - Multiple platforms, different stacks or exclusive features → multi-product
+
+3. **"Is there a primary platform that the other surfaces depend on — like a central API or web platform? Or are all surfaces independent peers?"** _(only if multi-product)_
+   - Yes, one primary → hub-and-spoke
+   - No, all independent → peer
+
+### Detection Signals (for document input)
+
+When processing a document, scan for these signals before creating any domain files:
+
+| Signal | Example | Classification |
+|---|---|---|
+| Distinct platform names in section headings | "Consumer Web Platform", "Shop Software (Tauri)" | Multi-product |
+| Different tech stacks mentioned per surface | "Astro/React for web", "Rust/Tauri for desktop" | Multi-product |
+| One surface described as "the platform" or "the API" | "Desktop app calls the platform API" | Hub-and-spoke |
+| All surfaces access a central database through one API | "Everything goes through the web platform's proxy" | Hub-and-spoke |
+| Surfaces described as equally independent | "Web and mobile are separate apps with separate backends" | Peer |
+| Single platform implied | "The website will...", "Users visit the app and..." | Single-surface |
+
+### Hub-and-Spoke Implications
+
+When hub-and-spoke is identified:
+
+- **The hub surface owns shared API/data domains.** Device History, Payments, Certification — these live INSIDE the hub surface's domain tree, not in a separate `shared/` folder.
+- **Spoke surfaces reference hub domains via CX.** Desktop's CX files say "Feature X consumes web/domain/feature via API."
+- **Spoke surfaces own their operational domains.** A domain belongs on the surface where it is **primarily experienced and operated**, not where the data lives. POS is a desktop domain even though it calls the hub's Stripe API. Inventory is a desktop domain even though it syncs to the hub's database.
+- **Proportionality check**: The hub may have more domains than any single spoke, but spokes must reflect the FULL experience their users have. If a spoke user's daily workflow involves 10+ distinct capabilities, 2-3 domains is a red flag — re-examine whether concepts were incorrectly collapsed into the hub.
+
+### Peer Mode Implications
+
+When peer mode is identified:
+
+- **Shared domains live in `shared/`.** `shared/` is treated as a peer node with the same fractal pattern.
+- **Each surface owns only its exclusive features.**
+- **Surface CX files reference `shared/` domains.** Both surfaces point to shared, rather than one owning it.
+
+### Classification Persistence
+
+The classification is recorded in `ideation-index.md` under `## Structural Classification`.
+All downstream steps read this section to determine where to place new nodes.
+
+---
+
+## Node Classification Gate
+
+> **RUN THIS GATE before creating ANY new node** — domain, sub-domain, or feature.
+
+```
+"I discovered [thing]. What is it?"
+     │
+     ▼
+Does it belong to an EXISTING domain or sub-domain?
+     │
+    YES ──► Does it have 2+ distinct capabilities that interact with each other?
+     │            │
+     │           YES ──► It's a SUB-DOMAIN ──► create folder inside existing parent
+     │            │
+     │           NO ──► It's a FEATURE ──► create .md file inside existing parent
+     │
+    NO ──► (Surface Placement — three questions)
+              │
+              Q1: "Where is this PRIMARILY experienced/operated?"
+              │    (Which surface's user interacts with this most?)
+              │
+              Q1a: "Does this concept have a DIFFERENT primary surface
+              │     for initial setup vs. day-to-day operation?"
+              │     (e.g., discovered on web, used daily on mobile)
+              │     │
+              │     YES ──► SPLIT: setup surface owns data/API domain,
+              │     │        daily-operation surface gets its own operational domain
+              │     │        Both are real domains — connect via CX
+              │     NO  ──► proceed with single primary surface from Q1
+              │
+              Q2: "Which hub APIs does it consume?"
+              │    (What data/services does it call from the hub?)
+              │
+              ├── Primarily experienced on a SPOKE surface
+              │     ──► It's a SPOKE DOMAIN ──► create in that spoke surface
+              │     ──► Log hub API dependencies in CX (Q2 answer)
+              │
+              ├── Primarily experienced on the HUB surface
+              │     ──► It's a HUB DOMAIN ──► create in hub surface
+              │
+              ├── No primary surface (pure API/data layer, no direct user interaction)
+              │     ──► It's a HUB DOMAIN (infrastructure) ──► create in hub
+              │
+              ├── Setup and daily-operation on DIFFERENT surfaces
+              │     ──► BOTH surfaces get domains ──► connect via CX
+              │     (e.g., Consumer Accounts: web owns signup/config,
+              │      mobile owns daily device management/messaging)
+              │
+              └── Equally used across multiple surfaces (rare)
+                    ──► It's a shared domain ──► create in shared/ (peer) or hub (hub-and-spoke)
+
+**WHEN UNCERTAIN: Ask the user.** Never assume placement.
+```
+
+> **Key principle**: A domain belongs where it is PRIMARILY USED, not where the data lives.
+> POS is a desktop domain even though payments go through the hub's Stripe API.
+> Inventory is a desktop domain even though stock data is in the hub's database.
+> The hub API dependency is logged as a CX reference, not as a classification signal.
+
+### Sub-Domain vs Feature Test
+
+The key question: **"Does this thing have its own internal features that interact with each other?"**
+
+| Example | Internal Features? | Classification |
+|---------|-------------------|----------------|
+| AI Assistant | Yes: task generation, guided workflow, parts recommendation, test tracking — these interact | **Sub-domain** (folder) |
+| Print Receipt | No: it does one thing | **Feature** (file) |
+| Inventory Manager | Yes: stock tracking, reorder alerts, supplier integration | **Sub-domain** or **Domain** depending on scope |
+| Password Reset | No: single flow with edge cases | **Feature** (file) |
+
+### Anti-Patterns
+
+| ❌ Wrong | ✅ Right |
+|----------|---------|
+| Creating "Print Receipt" as a new domain | Recognizing it's a feature within POS/Payments |
+| Classifying POS as a hub domain because it calls Stripe | Classifying POS as a desktop domain because the shop tech primarily operates it there |
+| Creating a domain for every feature mentioned | Grouping related features under their parent domain/sub-domain |
+| Pre-creating 4 levels of empty folders | Creating depth reactively as complexity is discovered |
+| Putting a shared domain in `shared/` when hub-and-spoke is active | Putting it inside the hub surface, with CX references from spokes |
+| Using source document headings as the domain map | Extracting concepts from the content and classifying each through the gate |
+| Creating a domain folder for every heading in the source | Only creating domain folders for concepts that pass the gate as true domains |
+| Collapsing a rich multi-system area into a single domain | Recognizing 2+ interacting capabilities = sub-domain or promoted domain |
+| Creating "Data Architecture" or "Tech Stack" as product domains | Noting architectural concerns for `/create-prd` — they are not product domains |
+| Creating folders before presenting the classification to the user | Always presenting the classification table and getting user confirmation first |
+| Classifying everything that touches the hub API as a hub domain | Using the "primarily experienced" test — hub API usage = CX, not classification |
+
+---
+
+## Reactive Depth Protocol
+
+### Depth Grows from Exploration
+
+The structure is NEVER pre-scaffolded. It grows as the agent explores:
+
+| Discovery Event | Action |
+|----------------|--------|
+| New surface identified | Create surface folder + surface index + surface CX |
+| New domain identified | Run Classification Gate. Create domain folder + index + CX inside correct parent |
+| New sub-area with 2+ interacting capabilities | Promote to sub-domain: create folder + index + CX |
+| New sub-area with single capability | Create as feature file (.md) inside current parent |
+| Feature explored and found to have internal complexity | Promote: convert .md to folder (see below) |
+
+### Promotion: Feature → Sub-Domain
+
+During drilling, a feature might reveal internal complexity that warrants promotion:
+
+1. Agent discovers the feature has 2+ interacting capabilities
+2. Agent asks: "This feature has enough internal complexity to be its own sub-domain. Should I promote it?"
+3. If confirmed:
+   - Create `{number}-{slug}/` folder
+   - Create index and CX files inside
+   - Split content from the old feature file into child feature files
+   - Update parent index
+4. Numbering stays the same — the feature number becomes the sub-domain number
+
+### Exhaustion Check (Leaf-Node Model)
+
+Exhaustion is checked at the **leaves** — whatever the deepest items are in each branch:
+
+- **Old model**: "All domains at DEEP"
+- **New model**: "All LEAF NODES at DEEP or EXHAUSTED"
+
+Status propagation rules:
+- All children `[EXHAUSTED]` → node is `[EXHAUSTED]`
+- All children `[DEEP]`+ → node is `[DEEP]`
+- Any child below `[DEEP]` → node stays at its current status
+
+---
+
+## Role Integration
+
+### Global Persona Definitions
+
+Personas are defined ONCE in `meta/personas.md`. This file is the single source of truth.
+
+### Where Persona Info Appears
+
+| Location | What's There | Template |
+|----------|-------------|----------|
+| `meta/personas.md` | Full persona definitions (6 fields each) | Single source of truth |
+| Index files → Role Matrix | Grid of children × personas with access icons | `fractal-node-index-template.md` |
+| Feature files → Role Lens | Per-feature access level + specific behavior | `fractal-feature-template.md` |
+| CX files → Role scoping | Which roles are affected by each cross-cut | `fractal-cx-template.md` |
+
+### Anti-Duplication Rule
+
+- **NEVER** redefine a persona outside `meta/personas.md`
+- **ALWAYS** reference personas by their short name
+- If a new persona is discovered → add to `meta/personas.md` FIRST, then reference
+
+---
+
+## Input-Adaptive Modes
+
+Before starting, classify what the user has provided and select the right mode.
+
+### Extraction Mode — Rich Input
+
+**Trigger:** User provides substantial existing material (>5KB, detailed docs, chat logs).
+
+**The job:** Don't lose information. Organize, validate, and fill gaps.
+
+> **CRITICAL**: Extraction mode uses the SAME interview question framework as Interview mode.
+> The document is the interviewee. The only difference is that the document provides answers
+> silently (the agent reads them) instead of interactively (the agent asks the user). Every
+> answer extracted from the document must cite where in the document it came from. Every
+> question the document doesn't answer becomes a real interview question for the user in Phase 2.
+>
+> **The source document's organization is a hint, not the truth.** Headings, section numbers,
+> and document structure tell you where to LOOK for concepts. They do NOT tell you what those
+> concepts ARE (domain, sub-domain, feature, cross-cut, or not-a-product-domain). The Node
+> Classification Gate determines what each concept is. NEVER mirror source headings as domains.
+>
+> **Document surface signals ARE classification input.** When a concept appears WITHIN a
+> surface-specific section of the document (e.g., "Shop Software", "Mobile App", "Desktop"),
+> that is a strong signal for surface placement. The section heading doesn't dictate the
+> domain NAME, but it DOES inform which surface the concept is primarily experienced on.
+> Use this as input to the "primarily experienced" question in the classification gate.
+
+**Process — Phase 1: Interview the Document** (silent — no user interaction)
+
+1. Read/ingest every document provided
+2. **Run Structural Classification** — determine project shape before creating any files
+3. **BLOCKING GATE — Extract concepts, not headings.** Read the entire document and identify every concept — a capability, system, feature, workflow, cross-cutting concern, or architectural note. For each concept, record:
+   - Concept name (what it is, in your words — not the source heading)
+   - Source location (line numbers or section reference — this is the citation)
+   - What the document says about it (summary of the content)
+   - How many distinct interacting capabilities it contains (the sub-domain test)
+   - Which surface section of the document it appeared in (if any) — this is a surface placement signal
+   - Whether it is cross-cutting (affects multiple domains regardless of surface)
+   Do NOT use source document headings as concept names unless they happen to be accurate after classification. The concept name must reflect what the thing actually IS after gate analysis.
+4. **BLOCKING GATE — Classify every concept.** Run the Node Classification Gate on EACH extracted concept individually. For each concept, answer the gate questions explicitly:
+   - "Does it belong to an EXISTING domain?" → if YES, it's a sub-domain or feature of that domain
+   - "Does it have 2+ distinct capabilities that interact with each other?" → if YES, it's a sub-domain (folder); if NO, it's a feature (file)
+   - "Where is this PRIMARILY experienced/operated?" → determines surface placement
+   - "Which hub APIs does it consume?" → logged as CX, NOT as classification signal
+   - "Is it an architectural concern, not a product domain?" → note for `/create-prd`, do NOT create a domain
+   - "Is it a cross-cutting concern?" → log in CX files, do NOT create a domain
+   Produce a **classification table**:
+
+   | Concept | Source Location | Gate Result | Primary Surface | Also Used On | Reasoning |
+   |---------|----------------|-------------|----------------|-------------|----------|
+   | Inventory System | lines 982–1017 (§Shop Software) | Sub-domain of Shop Operations | Desktop | Web (read-only dashboard) | 4+ interacting capabilities, primarily operated by shop tech at the counter |
+   | POS / Payments | lines 1018–1050 (§Shop Software) | Domain in Desktop | Desktop | Hub (Stripe API) | Shop tech runs transactions at register; hub provides payment processing API |
+   | In-Platform Messaging | lines 759–788 | Feature of Consumer Platform | Web | Mobile | Single capability with role-based routing, no internal sub-features |
+   | Data Architecture | lines 1261–1282 | NOT a product domain | — | — | Architectural concern — database selection, sync strategy → note for /create-prd |
+   | Analytics & Insights | lines 730–758 | Cross-cutting concern | — | All surfaces | Three tiers serving all domains, no exclusive features of its own |
+
+5. **BLOCKING GATE — Build proposed domain map.** From the classification table, group concepts into a proposed domain hierarchy:
+   - Only concepts classified as **domain** become domain folders
+   - Concepts classified as **sub-domain** nest inside their parent domain
+   - Concepts classified as **feature** become leaf files inside their parent
+   - Concepts classified as **cross-cut** go in the appropriate CX files
+   - Concepts classified as **not-a-product-domain** are noted in `meta/constraints.md` for `/create-prd`
+
+5.5. **BLOCKING GATE — Surface Distribution Audit.** Before presenting to the user, verify the classification didn't starve any spoke:
+
+   For each spoke surface:
+   1. List all concepts the document describes within that surface's sections
+   2. Count how many were classified as spoke domains vs. hub domains
+   3. For each hub-classified concept that appeared in a spoke section: **re-run the "primarily experienced" test** including Q1a (setup vs daily-operation). If the concept is primarily operated on the spoke — or daily-operated on the spoke even if set up elsewhere — reclassify it as a spoke domain with hub CX
+   4. **HARD GATE — not advisory**: If a spoke has fewer than 5 domains AND the document dedicates 100+ lines to that spoke → **STOP. The classification IS wrong.** You MUST re-run the daily-operation test (Q1 + Q1a) on EVERY hub-classified concept from that spoke's sections before proceeding. You may NOT write "PROPORTIONAL ✅" and continue — the gate condition is met, re-examination is mandatory. Only after re-examination may you proceed, and you must document which concepts were re-examined and why each retained or changed its classification
+
+5.6. **Spoke Persona Walk-Through.** For each spoke surface, identify its primary persona(s) and mentally walk through their daily workflow:
+   - "If I'm a [persona] sitting at the [surface], what are ALL the things I do in a typical day?"
+   - Enumerate every distinct workflow: each workflow with 2+ interacting capabilities is a candidate spoke domain
+   - Cross-reference against the classification table: any daily workflow capability that was classified as hub is suspect
+   - Reclassify as needed — the walk-through is the final validation before presenting to user
+
+6. **Identify gaps** — interview questions the document doesn't answer. These become Phase 2 interview questions.
+
+**Process — Phase 2: Present and Interview the User**
+
+7. **BLOCKING GATE — Present classification and get confirmation.** Show the user:
+   - The classification table (every concept, its source, its gate result, and reasoning)
+   - The proposed domain map (the folder hierarchy that would be created)
+   - The gap list (questions the document didn't answer)
+   Ask: "Here's how I classified your content. Does this look right?" **Wait for user confirmation or corrections. Do NOT create any folders until the user confirms.**
+8. **Apply corrections** — if the user reclassifies any concept, update the table and domain map
+9. **Create fractal folder structure** from the CONFIRMED domain map and seed with content from the source document
+10. **Interview the user for gaps** — switch to Interview Mode for every gap identified in step 6. Use the same Deep Think questions, same exhaustion protocol, targeted at what the document didn't cover.
+11. Run Deep Think: "Based on your content, I would also expect [X] and [Y]. Are those relevant?"
+
+**Enforcement rules:**
+- Do NOT create any domain folders before Step 9 (after user confirmation in Step 7)
+- Do NOT mirror source document headings as domains — they are hints for finding concepts, not the classification itself
+- Every concept in the classification table MUST show which gate questions were asked and how they were answered
+- If a concept's classification is uncertain, present it to the user in Phase 2 with your best guess and reasoning — do not silently guess
+
+### Expansion Mode — Thin Input
+
+**Trigger:** Brief notes, rough sketch, short PRD (<5KB, structured but shallow).
+
+**Process:**
+1. Read input and identify domain boundaries
+2. Create fractal folder structure per Classification Gate
+3. For each domain, identify the depth level
+4. Start with shallowest domains, ask targeted deepening questions
+5. Run Deep Think at each level to identify gaps
+6. Update domain indexes and feature files as you go
+
+### Interview Mode — No Input / One-Liner
+
+**Trigger:** No file input. User describes idea verbally.
+
+**Process:**
+1. Start: "In one sentence, what problem does this solve and for whom?"
+2. **Run Structural Classification** — ask the 2-3 interview questions immediately
+3. From the problem statement, identify key nouns → initial domains
+4. Create fractal folder structure per Classification Gate
+5. Run the Recursive Domain Exhaustion Protocol
+6. Use decision classification rule to route questions
+7. Don't stop until Deep Think generates zero new hypotheses
+
+---
+
+## Deep Think Protocol
+
+> **This is the core behavioral change.** At every step of ideation, you actively reason
+> about what should exist — you don't just record what the user says.
+
+### The Protocol
+
+At **every step** — domain discovery, breadth mapping, vertical drilling — pause and
+ask yourself these four questions before moving on:
+
+1. **What have I captured so far in this domain/sub-area?**
+2. **What would a domain expert expect to see here that hasn't been surfaced?**
+3. **What should exist here because of interactions with other domains?**
+4. **What common failure modes or edge cases are missing?**
+
+### Presenting Hypotheses
+
+> "Based on [reasoning], I think [X] might be relevant here. For example, in similar
+> systems, [concrete example]. Is this something your product needs?"
+
+**Outcomes:**
+- **CONFIRMED** → Add to the domain/feature file. Drill into it.
+- **REJECTED** → Note the rejection with reason in the Deep Think table.
+- **DEFERRED** → Note as an open question with owner and target stage.
+
+### Tracking
+
+Record all hypotheses in each feature file's Deep Think Annotations table (see `fractal-feature-template.md`).
+
+### Exhaustion Signal
+
+The ideation process is complete for a feature when:
+1. Deep Think generates **zero new hypotheses** after a full pass
+2. The user confirms "nothing else" for that feature
+3. Both conditions must be true simultaneously → mark as `[EXHAUSTED]`
+
+---
+
+## Recursive Domain Exhaustion Protocol
+
+### Level 0 — Global Domain Map
+
+**Goal:** Identify ALL domains before exploring ANY of them.
+
+1. List all domains from user input
+2. **Deep Think:** "What domains would a domain expert expect?"
+3. Run **Node Classification Gate** for each domain — determine placement
+4. Create fractal folder for each: `{number}-{slug}/` + index + CX
+5. Update `ideation-index.md` with the complete structure map
+6. Note preliminary cross-cuts in global CX + relevant domain CX files
+7. **Gate:** User confirms domain list before proceeding
+
+### Level 1 — Domain Breadth Sweep
+
+**Goal:** For each domain, map ALL children before drilling ANY.
+
+For each domain (dependency order — foundational first):
+1. List all sub-areas/capabilities
+2. **Deep Think:** "What sub-areas would an expert expect in this domain?"
+3. Run **Node Classification Gate** for each — sub-domain (folder) or feature (file)?
+4. Create children: sub-domain folders or feature files as classified
+5. Update domain index (Children table + Role Matrix)
+6. Note cross-cuts in domain CX file
+7. **NEW DOMAINS DISCOVERED?** → Loop to Level 0
+8. **Gate:** User confirms breadth maps before drilling
+9. Mark domain status as `[BREADTH]`
+
+### Level 2+ — Vertical Drilling
+
+**Goal:** Drill each child to implementation depth. Deep Think at every step.
+
+For each feature file / sub-domain:
+1. Apply the Exhaustion Questions
+2. **Deep Think** per feature
+3. Write results to feature files (behavior, edge cases, states, Role Lens)
+4. Cross-cuts with evidence → add to parent's CX file
+5. **Feature reveals 2+ interacting capabilities?** → Run Promotion protocol
+6. **NEW DOMAINS DISCOVERED?** → Loop to Level 0
+7. When Deep Think yields zero hypotheses AND user confirms → mark `[EXHAUSTED]`
+
+---
+
+## Exhaustion Questions
+
+### For Every Entity
+- What are its attributes/fields?
+- What are its possible states?
+- What triggers each state transition?
+- What's the full lifecycle (creation → active use → archival/deletion)?
+- Who can create, read, update, delete it?
+- What happens when it's referenced by other entities and gets deleted?
+
+### For Every Feature
+- What does the user see when they first encounter this feature?
+- What's the happy path interaction flow (step by step)?
+- What happens when it fails? What error does the user see?
+- What happens on partial failure?
+- What permissions are required? What happens without them?
+- Does it have different states (loading, empty, populated, error)?
+- How does it interact with other features?
+- What edge cases exist?
+
+### For Every User Type
+- What's their primary workflow?
+- What's the worst thing they could intentionally do?
+- What's the worst thing they could accidentally do?
+- What do they see that other user types don't?
+- What can they do that other user types can't?
+- What's their tolerance for complexity?
+
+### For Every Integration / External System
+- What happens when it's unavailable?
+- What's the expected latency? What if 10x slower?
+- What data format does it use?
+- What rate limits exist?
+- What happens when the external system changes its API?
+
+---
+
+## Cross-Cut Watch Protocol
+
+Cross-cut detection is **always-on** regardless of mode or level. During all active exploration:
+
+- After each sub-feature: "Does this depend on or affect any other domain?"
+- After each edge case: "Which other parts need to know about this failure mode?"
+- After each state transition: "Does this trigger anything in another domain?"
+
+When a cross-cut is identified, log it to the appropriate CX file:
+
+| Discovery Level | Where to Log | Confidence |
+|----------------|-------------|------------|
+| During domain mapping | Parent node's CX file + global `ideation-cx.md` (if cross-surface) | Low |
+| During breadth sweep | Domain CX file | Medium |
+| During drilling | Sub-domain CX file or feature's cross-cut notes | High |
+
+### CX Decision Gate (Mandatory — NOT skippable)
+
+> **This is the enforcement mechanism for the Cross-Cut Watch Protocol.**
+> "Always-on" means there is a hard gate, not a suggestion.
+
+**After ANY of these trigger events, STOP and run this gate before moving to the next item:**
+
+| Trigger Event | Example |
+|---------------|---------|
+| Open question (OQ) resolved | User decides hiring fee model = shop pays |
+| Deep Think hypothesis confirmed | Agent proposed AI parts ordering, user confirmed |
+| User makes any product decision | User chooses freemium over paid-only |
+| Feature deepened reveals dependency | Certification tracking needs data from Training domain |
+| Edge case identified with cross-domain impact | Payment failure in domain A must notify domain B |
+
+**Gate questions** (answer all three):
+
+1. **New dependency?** — Does this decision create a dependency on another domain?
+2. **Modified cross-cut?** — Does it change an existing CX entry?
+3. **Cross-domain state/permissions/triggers?** — Does it affect state, permissions, or trigger chains in another domain?
+
+**If YES to any** → update the relevant CX file(s) **immediately**, before moving to the next item. Write the CX entry with:
+- Source domain and feature
+- Target domain(s) affected
+- Nature of the cross-cut (data dependency, trigger chain, permission, state)
+- Confidence level based on discovery context
+
+**If NO to all** → proceed. No logging needed for clean passes.
+
+> [!CAUTION]
+> **The gate is the point.** The most common failure mode is resolving an OQ, writing the decision to the feature file, and moving on without checking CX. The hiring fee model affects Payments, Supplier Integration, Analytics, and Consumer Platform visibility — 6 cross-domain connections that would be silently lost without this gate.
+
+### Cross-Cut Synthesis Questions
+
+For each confirmed cross-cut (CX entry with High confidence), answer all five synthesis questions per the `fractal-cx-template.md`:
+
+1. **Shared state conflict** — Who owns the entity? Merge strategy?
+2. **Trigger chain** — Does A trigger B? Rollback if B fails? Sync/async?
+3. **Permission intersection** — Does permission in A affect B?
+4. **Notification fan-out** — Does an event in A notify actors in B?
+5. **State transition conflict** — Can A and B race? Consistency impact?
+
+---
+
+## Decision Routing During Extraction
+
+| Decision Type | During Ideation | Example |
+|---|---|---|
+| **Product** | Ask the user. It's their product. | "Should free users be able to...?" |
+| **Architecture** | Note for `/create-prd`. Don't burden the user. | "Should we use SQL or NoSQL?" |
+| **Implementation** | Note for later. Don't even mention it. | "How should we name the routes?" |
+
+**Exception:** If the user brings up architecture or implementation, engage. Don't refuse — just don't initiate it.
+
+---
+
+## Breadth Before Depth
+
+### No Premature Drilling
+Complete the breadth map of all children within a node **before drilling any single child**.
+
+### No Premature Compilation
+Don't start writing the vision summary until:
+- All leaf nodes are at least `[DEEP]`
+- Every Must Have feature explored to ≥Level 2
+- Deep Think yields zero new hypotheses across ALL domains
+- User has confirmed the coverage map
+
+### Challenge Weak Answers
+When the user gives a one-sentence answer to a complex question, don't accept it. Probe.
+
+### Summarize and Validate
+After every 5-6 questions, pause and summarize to prevent drift.
+
+### Progress Transparency
+Be transparent: "We've explored [N] of [M] domains to DEEP level. [Domain X] is still at BREADTH."
+
+---
+
+## What This Skill Does NOT Do
+
+- **Does not make product decisions** — It extracts them from the user
+- **Does not explore architecture** — That's `/create-prd`'s job
+- **Does not replace brainstorming** — Brainstorming is lightweight; this is heavyweight extraction
+- **Does not produce the vision document** — `ideate-validate` compiles the summary
+- **Does not rush** — The entire downstream pipeline depends on the depth produced here
+- **Does not prescribe shard boundaries** — That's `/decompose-architecture`'s job