idea-extraction

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: .agents/skills/prd-templates/references/fractal-node-index-template.md
3. CX files at every level. Template: .agents/skills/prd-templates/references/fractal-cx-template.md
4. Feature files are leaf nodes. Template: .agents/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: .agents/skills/prd-templates/references/ideation-index-template.md The top-level ideation-cx.md uses: .agents/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 us

---

*Content truncated.*