cfsa-antigravity 1.0.0

package/template/.agent/workflows/evolve-feature.md

@@ -0,0 +1,56 @@
+---
+description: Add new features, requirements, or constraints mid-pipeline — classify the change, write it at the correct entry point, and cascade through downstream layers
+pipeline:
+  position: utility
+  stage: quality-gate
+  predecessors: [] # callable from any stage
+  successors: [] # returns to caller
+  skills: [resolve-ambiguity, technical-writer, brainstorming]
+  calls-bootstrap: false
+shards: [evolve-feature-classify, evolve-feature-cascade]
+---
+
+# Evolve Feature
+
+Add genuinely new features, requirements, or constraints to the pipeline after work has already begun — classify the change, write it at the correct entry point, and cascade additions through all downstream layers that have existing content.
+
+**Usage**: `/evolve-feature` — you'll be asked to describe what you want to add.
+
+**Optional**: `/evolve-feature @file` — provide a document describing the new feature.
+
+**When to use this**: Any time scope grows after pipeline work has begun — new features, new requirements on existing features, new technical constraints, or corrections to misunderstandings.
+
+**When NOT to use this**: If you're correcting downstream documents to match an already-locked decision — use `/propagate-decision` instead. If you're starting fresh — use `/ideate`.
+
+**Key distinction from `/propagate-decision`**: `/evolve-feature` adds genuinely new things that didn't exist before. `/propagate-decision` corrects documents that should have always reflected a locked decision.
+
+---
+
+## Shard Overview
+
+| # | Shard | What It Does |
+|---|-------|--------------|
+| 1 | [`evolve-feature-classify`](.agent/workflows/evolve-feature-classify.md) | Captures the new thing, classifies it, identifies the entry point document, writes new content, determines cascade scope |
+| 2 | [`evolve-feature-cascade`](.agent/workflows/evolve-feature-cascade.md) | Cascades through downstream layers, assesses implementation impact, runs consistency check, writes evolution record |
+
+---
+
+## Orchestration
+
+### Step A — Run `.agent/workflows/evolve-feature-classify.md`
+
+Captures the user's description of the new feature/requirement/constraint, classifies it into one of four categories, identifies the correct entry point document, writes the new content at the appropriate spec depth, and determines which downstream layers need updating.
+
+### Step B — Run `.agent/workflows/evolve-feature-cascade.md`
+
+Cascades the new content through each downstream layer with existing content (stopping at each layer for user approval), assesses implementation impact on phase plans, runs a consistency check, writes the evolution record, and proposes next steps.
+
+---
+
+## Key Principles
+
+- **Scope growth is normal** — The pipeline is designed to evolve. New features mid-pipeline are expected, not exceptional.
+- **Entry point matters** — The classification determines where new content enters the pipeline. Writing at the wrong layer creates inconsistency.
+- **Cascade is ordered** — Architecture → IA → BE → FE → Phase plan. Never skip a layer.
+- **User approval at each layer** — The user sees and approves additions at every layer before cascading further.
+- **Implementation impact is assessed** — If phase plans exist, the workflow determines whether existing slices need revisiting or new slices are needed.

package/template/.agent/workflows/ideate-discover.md

@@ -0,0 +1,144 @@
+---
+description: Domain mapping, problem exploration, and feature inventory for the ideate workflow
+parent: ideate
+shard: discover
+standalone: true
+position: 2
+pipeline:
+  position: 1.2
+  stage: vision
+  predecessors: [ideate-extract]
+  successors: [ideate-validate]
+  skills: [idea-extraction, resolve-ambiguity]
+  calls-bootstrap: false
+---
+
+// turbo-all
+
+# Ideate — Discover
+
+Map domains, explore the problem space, and build the feature inventory.
+
+**Prerequisite**: If invoked standalone, verify the user has already classified their input type (via `/ideate-extract` or by providing context). If not, prompt the user to run `/ideate-extract` first or describe what they want to build.
+
+---
+
+## 3. Domain mapping
+
+Read .agent/skills/idea-extraction/SKILL.md and follow its domain exhaustion methodology.
+
+Read the `## Expansion Mode` section from `docs/plans/ideation.md` and route accordingly. All findings are written to `ideation.md` in real time — not held in context.
+
+**Full Mode** (three-pass orchestration):
+
+- **Pass 1 — Horizontal Sweep**: Audit `ideation.md` for all domains present. Apply domain exhaustion protocol to identify missing domains. Add all confirmed domains with `[SURFACE]` marker. Do NOT drill yet. Present complete domain map to user and get confirmation before Pass 2.
+- **Pass 2 — Vertical Drilling**: For each domain (dependency order — foundational first), drill to Level 2-3 depth. Cross-cut watch active: after each sub-feature/edge case, ask "Does this touch any other domain?" If yes, immediately add to `## Cross-cutting Candidates` in `ideation.md` as `[Domain A] × [Domain B]: [connection]`. Do not stop to explore — flag and continue. Update depth markers as drilling progresses. Pause after each domain: "Here's what I captured. Anything missing?"
+- **Pass 3 — Cross-cutting Synthesis**: Present full candidates list. For each cross-cutting candidate pair, ask all five of these questions:
+
+  1. **Shared state conflict**: If both features write to the same entity, who wins on conflict? What is the merge/override strategy? Is there a canonical owner?
+  2. **Trigger chain**: Does completing Feature A automatically trigger Feature B? If yes, what are the rollback semantics if B fails mid-chain? Is this synchronous or async?
+  3. **Permission intersection**: Does a user's permission level in Domain A affect what they can do in Domain B? Are there permission escalation or restriction paths between domains?
+  4. **Notification fan-out**: Does an event in Domain A need to notify actors in Domain B? Who owns the notification contract? What happens if the notification fails?
+  5. **State transition conflict**: Can Features A and B be triggered simultaneously by the same user? What happens to data consistency if they race?
+
+  These five questions surface the failure modes most commonly discovered as production bugs when cross-cutting interactions are underspecified at the ideation phase. Document confirmed answers in `## Feature Interactions` in `ideation.md`. Discard rejected pairs with a one-line note explaining why they don't interact. Check for second-order cross-cuts.
+
+**Vertical Mode**: Focus on existing domains. Identify shallowest sub-topics. Drive to Level 2-3 depth. Cross-cut watch active — surface candidates list at end. Do not introduce new domains unless user requests.
+
+**Horizontal Mode**: Audit for missing domains. Present gap list. Add confirmed new domains with Level 1 exploration. Cross-cut watch active for new domains vs existing. Offer to continue with vertical drilling after.
+
+**Cross-cutting Mode (standalone)**: Read all features, identify interaction points. For each significant pair, ask about conflicts/dependencies/shared state. Document confirmed interactions. Note: works best after vertical drilling.
+
+**Combination Mode**: User specifies sequence. Apply each mode in order. Cross-cut detection always active.
+
+**As-is Mode**: Skip active expansion. Proceed to domain exhaustion check. Cross-cut watch still active — scan `ideation.md` for obvious interaction points and surface before compiling `vision.md`.
+
+> **Mid-session mode switching**: If you want to change expansion direction, update the `Expansion Mode` in `ideation.md` and re-run `/ideate-discover`.
+
+## 4. Problem exploration
+
+Read .agent/skills/brainstorming/SKILL.md and follow its structured facilitation methodology.
+
+Using the idea-extraction skill's approach for the selected mode, explore:
+
+1. **What problem are we solving?** — Get the user to articulate the core pain point in one sentence. If they can't, help them sharpen it.
+2. **Who has this problem?** — Identify 2-4 distinct user personas with different needs. For each persona, explore:
+   - Name and role
+   - Their primary pain point
+   - How they solve it today (workarounds)
+   - What success looks like for them
+   - What would make them switch from their current solution
+3. **How are they solving it today?** — Understand the competitive landscape and current workarounds
+4. **Why now?** — What has changed that makes this solvable/valuable now
+
+After each answer, summarize what you've captured and ask the user to confirm before moving on.
+
+**Persona completeness gate (Vision Rubric Dimension 2):** For each persona, verify all 6 fields are explicitly present before moving on:
+1. **Name + specific role** — not "a user" or "customers"; a named role with context
+2. **Specific pain point** — one sentence naming the exact friction, not "they struggle with X generally"
+3. **Current workaround** — how they solve this today: the specific tool, manual process, or coping mechanism
+4. **Success criteria** — what "solved" concretely looks like for this persona; measurable if possible
+5. **Switching trigger** — what would make them switch from their current approach (price threshold, feature, event)
+6. **At least one edge case or constraint unique to this persona** — something that makes their situation different from other personas
+
+If any field is absent → probe for it before proceeding. Do not move to feature collection until all personas have all 6 fields. Reference: `.agent/skills/pipeline-rubrics/references/vision-rubric.md` Dimension 2 for the ✅ criteria this gate enforces.
+
+## 5. Feature inventory — deep exploration
+
+This is where most ideation workflows fail. They collect a feature list and move on.
+This workflow explores each feature to multiple levels of depth.
+
+### 5a. Feature collection (MoSCoW)
+
+Read .agent/skills/brainstorming/SKILL.md and follow its methodology.
+
+For each persona identified in Step 4, brainstorm features:
+
+1. **Must-have features** — What features are launch-blocking?
+2. **Should-have features** — What features are expected but not day-one critical?
+3. **Could-have features** — What features would delight but can be deferred?
+4. **Won't-have (now)** — What is explicitly out of scope?
+
+Present the MoSCoW matrix to the user for validation.
+
+> **Note:** Deferred ≠ lower quality. Every feature that makes the cut will be
+> built to production standard. The categories control *what* ships, not *how well*
+> it's built.
+
+### 5b. Feature deepening — Must Haves
+
+Read .agent/skills/idea-extraction/SKILL.md and follow its domain exhaustion methodology.
+
+For each **Must Have** feature, use the idea-extraction skill's Domain Exhaustion Protocol
+to explore at least 2 levels deep:
+
+**Level 1: Sub-features.** What are the component parts of this feature?
+- "User authentication" → signup, login, password reset, profile management, account deletion, session management, OAuth providers
+
+**Level 2: Edge cases and failure modes.** For each sub-feature:
+- What happens on failure? What error does the user see?
+- What happens on partial failure? (network drops mid-operation)
+- What permissions are required?
+- What are the states? (loading, empty, populated, error)
+
+**Level 3 (for complex features): Interactions and conflicts.**
+- How does this feature interact with other Must Haves?
+- What if two features trigger simultaneously?
+- Are there any conflicts between features?
+
+**Decision routing:** When feature decisions arise, use the decision classification rule:
+- Feature inclusion/exclusion → product decision → ask the user
+- How to implement the feature → defer to `/create-prd`
+- Detailed technical choice → note for later, don't burden the user
+
+### 5c. Feature deepening — Should Haves (lighter touch)
+
+For Should Have features, explore Level 1 (sub-features) only. Note that these will get
+full Level 2-3 treatment in `/create-prd` when they enter scope.
+
+### Propose next step
+
+Once the feature inventory is complete and the user has confirmed the MoSCoW matrix, proceed to `/ideate-validate` to explore constraints, success metrics, and compile the vision document.
+
+> If this shard was invoked standalone (not from `/ideate`), surface this via `notify_user`. If invoked by the parent `/ideate`, this is a natural handoff — the parent orchestrates the transition.
+

package/template/.agent/workflows/ideate-extract.md

@@ -0,0 +1,129 @@
+---
+description: Input classification, noise filtering, and skill loading for the ideate workflow
+parent: ideate
+shard: extract
+standalone: true
+position: 1
+pipeline:
+  position: 1.1
+  stage: vision
+  predecessors: []
+  successors: [ideate-discover]
+  skills: [idea-extraction, resolve-ambiguity]
+  calls-bootstrap: false
+---
+
+// turbo-all
+
+# Ideate — Extract
+
+Classify the user's input, apply noise filtering for chat transcripts, and load the skills needed for ideation.
+
+**Prerequisite**: If invoked standalone (not from `/ideate`), verify the user has provided input — either an `@file` reference or a verbal description. If no input is provided, prompt: "What would you like to build? Describe your idea, or provide a file with `/ideate-extract @path/to/file.md`."
+
+---
+
+## 1. Input assessment
+
+Classify what the user has provided. This determines which mode the `idea-extraction` skill
+uses and how the rest of the workflow behaves.
+
+| Input Type | Detection | Extraction Mode |
+|---|---|---|
+| **Rich document** | >5KB, detailed docs, design conversations, prior specs | Extraction |
+| **Thin document** | <5KB, structured but shallow (bullet list, rough PRD) | Expansion |
+| **Conversational dump** | Chat logs, unstructured conversation transcripts | Extraction (with noise filtering) |
+| **Verbal / one-liner** | User describes idea in chat, no files | Interview |
+| **Nothing** | "I want to build an app" or similar | Interview (deep) |
+
+**For rich inputs (Extraction mode):**
+1. Read/ingest all provided documents
+2. **Proportionality check**: If the source document is over 50KB, the vision output (including appendices) must be at least 30% of the source document's line count. If it falls short, the agent must identify what was lost and recover it before presenting the vision.
+3. Enumerate what maps to vision domains (problem, personas, features, constraints, etc.)
+4. Present the organized inventory to the user for confirmation: "Here's what I found, organized by domain. Is anything missing or wrong?"
+5. Identify gaps — domains or sub-topics not covered
+6. For each gap, switch to Interview mode for that topic
+7. Use idea-extraction skill to refine and deepen, not to re-derive what's already known
+
+**For thin inputs (Expansion mode):**
+1. Read the input and map its sections to vision domains
+2. Identify which sections are surface-level vs implementation-ready
+3. Start with the shallowest sections
+4. Use idea-extraction skill to deepen each one
+
+**For verbal / no input (Interview mode):**
+1. Read `.agent/skills/idea-extraction/SKILL.md` and enter Interview mode
+2. Start with: "In one sentence, what problem does this solve and for whom?"
+3. From that sentence, identify the key nouns — these become initial domains
+4. Proceed to domain mapping (in `/ideate-discover`)
+
+## 1.4. Re-run check
+
+Before seeding, check whether `docs/plans/ideation.md` already exists.
+- If it **exists**: Present a summary of its current state (expansion mode, domain count, depth markers, cross-cutting candidate count). Ask: "An ideation document already exists. Do you want to **continue from it** or **start fresh**?"
+  - **Continue** → skip seeding, jump directly to Step 1.6.
+  - **Start fresh** → archive existing file to `docs/plans/ideation-archive-[timestamp].md`, then proceed with seeding.
+- If it **does not exist**: proceed with seeding.
+
+## 1.5. Seed `ideation.md`
+
+Read .agent/skills/technical-writer/SKILL.md and follow its methodology.
+
+Create `docs/plans/ideation.md` based on classified input type:
+
+- **Rich document**: Restructure source content into ideation format preserving all detail. Add reference at top: `> Source: path/to/original.md`. Do not modify the original.
+- **Chat transcript**: Run the noise filter (read full transcript, extract decisions/ideas/rejections, discard filler, present extracted signal to user for confirmation), then write the clean structured signal into `ideation.md` with section headers. Attribute decisions: `> Decided in conversation: [decision]`.
+- **Thin document**: Copy content into `ideation.md` and annotate each section with `[SURFACE]`, `[PARTIAL]`, or `[DEEP]` depth markers.
+- **Verbal / one-liner**: Create `ideation.md` with domain scaffolding based on the initial description. Sections are empty placeholders.
+
+## 1.6. User Intent Check (ALL input types)
+
+Read .agent/skills/brainstorming/SKILL.md and follow its methodology.
+
+After seeding, present a summary of what was captured and ask how the user wants to proceed. Framing adapts to input type:
+
+- **Rich document**: "I've organized your document into `ideation.md`. Here's what I found: [domain summary with depth indicators]. How would you like to proceed?"
+- **Chat transcript**: "I've extracted the signal from your conversation into `ideation.md` — [N] decisions, [N] feature ideas, [N] rejected directions. Here's the summary: [domain summary]. How would you like to proceed?"
+- **Thin document**: "I've annotated your document in `ideation.md`. I found [N] sections at surface depth, [N] at partial depth, [N] implementation-ready. How would you like to proceed?"
+- **Verbal / one-liner**: "I've scaffolded `ideation.md` with [N] initial domains based on your description. How would you like to approach this?"
+
+Present all options for every input type:
+1. **Full exploration** *(recommended for 3+ domains)* — Horizontal sweep → vertical drilling → cross-cutting synthesis, with cross-cut detection active throughout
+2. **Process as-is** — Proceed with what's captured; fill gaps via interview as they arise
+3. **Expand vertically** — Drill deeper into existing features
+4. **Expand horizontally** — Add new feature domains not yet covered
+5. **Explore cross-cutting concerns** — Map how existing features interact and conflict
+6. **Combination** — User specifies which dimensions and order
+7. **Audit ambiguity first** — Run inline check on `ideation.md` before deciding
+
+Recommendation logic: suggest Full if 3+ domains, vertical if 1-2 domains, Full if no domains (verbal). Always present all options. **Wait for user answer — do not assume.**
+
+> **Note**: Cross-cut detection is always-on regardless of mode. Even if the user picks vertical-only, maintain a `## Cross-cutting Candidates` list in `ideation.md` and surface it at the end.
+
+## 1.7. Expansion Mode Routing
+
+Based on the user's choice, write the expansion mode to `ideation.md`:
+
+```
+## Expansion Mode
+- Type: [full | vertical | horizontal | cross-cutting | combination | as-is]
+- Targets: [list of domains/features to focus on, if applicable]
+- Cross-cut Detection: always-on
+```
+
+This flag is read by `ideate-discover.md` to shape domain mapping behavior.
+
+## 2. Load skills
+
+Read `.agent/skills/idea-extraction/SKILL.md` and follow its methodology throughout this workflow.
+
+Also read `.agent/skills/resolve-ambiguity/SKILL.md` — use it reactively when encountering
+ambiguity that can be resolved without user input (technical/factual questions). For
+intent/choice questions, use the decision classification rule.
+
+### Propose next step
+
+Once input is classified and skills are loaded, proceed to `/ideate-discover` to map domains and build the feature inventory.
+
+> If this shard was invoked standalone (not from `/ideate`), surface this via `notify_user`. If invoked by the parent `/ideate`, this is a natural handoff — the parent orchestrates the transition.
+

package/template/.agent/workflows/ideate-validate.md

@@ -0,0 +1,117 @@
+---
+description: Constraints, metrics, competitive positioning, domain exhaustion, and vision compilation for the ideate workflow
+parent: ideate
+shard: validate
+standalone: true
+position: 3
+pipeline:
+  position: 1.3
+  stage: vision
+  predecessors: [ideate-discover]
+  successors: [create-prd]
+  skills: [idea-extraction, resolve-ambiguity, prd-templates, pipeline-rubrics]
+  calls-bootstrap: false
+---
+
+// turbo-all
+
+# Ideate — Validate
+
+Explore constraints, success metrics, and competitive positioning. Run domain exhaustion and vision deepening passes. Compile the vision document.
+
+**Prerequisite**: If invoked standalone, verify that domain mapping and feature inventory have been completed (from `/ideate-discover` or equivalent context).
+
+---
+
+## 6. Constraints and non-functionals
+
+Read .agent/skills/brainstorming/SKILL.md and follow its methodology.
+
+Explore constraints through targeted questions:
+
+1. **Budget** — Self-funded? VC-backed? Impacts hosting and infra decisions
+2. **Timeline** — Production launch target? Phased rollout?
+3. **Team** — Solo dev? Small team? Impacts architecture complexity
+4. **Compliance** — Age restrictions? GDPR? PCI? COPPA? HIPAA?
+5. **Performance** — Expected scale? Latency requirements?
+
+### Project surface classification
+
+Classify the project surfaces. Ask explicitly:
+
+1. **What surfaces does this project have?** — Web app, desktop app, mobile app, CLI tool, API service, or multi-surface
+2. **For desktop/mobile: cross-platform?**
+3. **For multi-surface: how are they connected?**
+
+> **Why this matters**: The surface classification drives folder structure in
+> `/decompose-architecture`, tech stack decisions in `/create-prd`, and the
+> shape of every spec downstream.
+
+Record the classification in the Constraints section of vision.md.
+
+## 7. Success metrics
+
+Define measurable success criteria:
+
+1. **Launch criteria** — What must be true to ship?
+2. **Growth metrics** — DAU, retention, conversion targets
+3. **Technical metrics** — Platform-appropriate performance targets (web: Core Web Vitals; desktop: cold start, memory; mobile: launch time, battery; CLI: execution time; API: p50/p95/p99)
+
+## 8. Competitive positioning
+
+1. **Who are the top 3 competitors?**
+2. **What's the unique angle?**
+3. **What's the moat?**
+
+## 9. Domain exhaustion check
+
+Read .agent/skills/idea-extraction/SKILL.md and apply its domain exhaustion checklist.
+
+1. Display the coverage map to the user
+2. Flag under-explored domains (any domain with <3 explored sub-topics)
+3. For each, ask: "Should we explore it now, or is it intentionally minimal?"
+4. Continue until all domains reach ≥3 sub-topics OR user confirms intentionally minimal
+
+Only proceed when: overall coverage ≥80%, every Must Have explored to ≥Level 2, user has confirmed.
+
+## 10. Vision deepening pass
+
+Read .agent/skills/resolve-ambiguity/SKILL.md and follow its methodology.
+
+One deepening pass across all captured material:
+
+1. **Persona gaps** — scenarios where personas conflict
+2. **Feature completeness** — implicit sub-features (e.g., "user accounts" implies signup, login, reset, profile, deletion)
+3. **Constraint interactions** — conflicting constraints
+4. **Surface completeness** — does every surface have clear feature ownership?
+5. **Missing "Won't Have"** — obvious features to explicitly exclude
+
+Present findings. Refine based on discussion.
+
+## 11. Compile vision document
+
+Read .agent/skills/technical-writer/SKILL.md and follow its methodology.
+
+Read `.agent/skills/prd-templates/references/vision-template.md` for the document structure. Compile `docs/plans/vision.md` from `docs/plans/ideation.md`. The ideation document is the authoritative source — do not add or drop material.
+
+Create domain appendices for domains with extensive material (>100 lines, technical artifacts, enumeration-heavy content) at `docs/plans/vision-appendix-{domain-slug}.md`.
+
+## 12. Request review and propose next steps
+
+Run a pre-flight self-check. Read `.agent/skills/pipeline-rubrics/references/vision-rubric.md` and apply each of the 7 dimensions. Also check:
+
+- **Input-Output Fidelity** — Two-layer check: (1) every major section of the original source maps to `ideation.md`; (2) every section in `ideation.md` maps to `vision.md` — nothing dropped.
+
+For any dimension scoring ⚠️ or ❌, resolve it before presenting.
+
+Call `notify_user` presenting:
+- `docs/plans/vision.md` and any appendices
+- The self-check summary (all dimensions with ✅/⚠️/❌ scores)
+- Any gaps resolved during the self-check
+- The final domain coverage map
+
+> **Do NOT proceed until the user sends a message explicitly approving this output.**
+
+### Proposed next steps
+
+**Hard gate**: Do NOT propose `/create-prd` until `/audit-ambiguity vision` has run as a fresh invocation and scored 0% ambiguity.

package/template/.agent/workflows/ideate.md

@@ -0,0 +1,113 @@
+---
+description: Structured idea extraction from raw input to vision document — input-adaptive, domain-exhaustive, production-grade from the first conversation
+pipeline:
+  position: 1
+  stage: vision
+  predecessors: [] # entry point
+  successors: [create-prd]
+  skills: [idea-extraction, resolve-ambiguity]
+  calls-bootstrap: false
+shards: [ideate-extract, ideate-discover, ideate-validate]
+---
+
+# Ideate
+
+## Invocation Patterns
+
+| Invocation | Behavior |
+|---|---|
+| `/ideate` | Starts an interactive interview from scratch |
+| `/ideate @path/to/file.md` | Reads the file, classifies it automatically, enters the appropriate mode |
+
+### Input Types and Modes
+
+| Input Type | Detection | Mode Triggered |
+|---|---|---|
+| Rich document | >5KB, detailed docs, design conversations, prior specs | Extraction — captures existing depth, fills gaps via interview |
+| Thin PRD | <5KB, structured but shallow (bullet list, rough PRD) | Expansion — deepens every section via domain exhaustion |
+| Chat transcript | Chat logs, unstructured conversation transcripts | Extraction + noise filter — extracts signal, discards noise, fills gaps |
+| One-liner / verbal | User describes idea in chat, no files | Interview (deep) — builds vision from scratch domain by domain |
+| Full exploration | Any input with 3+ domains | Full — Horizontal sweep → vertical drilling → cross-cutting synthesis, cross-cut detection active throughout |
+
+**Quality guarantee**: All four input types produce the **same output quality**. The vision document that emerges from a one-liner is structurally and substantively identical to one produced from a rich document. Only the amount of interview work differs.
+
+Transform a raw idea into a comprehensive vision document through exhaustive exploration.
+
+> This pipeline does not build MVPs. The ideation phase is where the entire downstream
+> pipeline gets its DNA. If the vision is shallow, every spec, every architecture decision,
+> every line of code downstream will be shallow. Treat this phase with the seriousness it
+> deserves.
+
+**Output**: `docs/plans/ideation.md` (intermediary, permanent) + `docs/plans/vision.md` (and optional domain appendices)
+
+---
+
+## Shard Overview
+
+| # | Shard | What It Does |
+|---|-------|-------------|
+| 1 | [`ideate-extract`](.agent/workflows/ideate-extract.md) | Classifies input, seeds `docs/plans/ideation.md`, applies noise filter for chat transcripts (integrated into seeding), runs user intent check, sets expansion mode, loads skills |
+| 2 | [`ideate-discover`](.agent/workflows/ideate-discover.md) | Domain mapping, problem exploration, feature inventory (MoSCoW + deepening) |
+| 3 | [`ideate-validate`](.agent/workflows/ideate-validate.md) | Constraints, metrics, competitive positioning, domain exhaustion, vision compilation |
+
+---
+
+## Orchestration
+
+### Step 1 — Run `.agent/workflows/ideate-extract.md`
+
+Classifies the user's input (rich doc, thin PRD, chat transcript, verbal), checks for an existing `ideation.md` (re-run check), seeds `docs/plans/ideation.md` from the input, runs the universal user intent check to determine expansion mode, sets the expansion mode flag in `ideation.md`, and loads the idea-extraction and resolve-ambiguity skills.
+
+### Step 2 — Run `.agent/workflows/ideate-discover.md`
+
+Maps domains from the classified input, explores the problem space (personas, pain points, competitive landscape), and builds the full MoSCoW feature inventory with multi-level deepening.
+
+### Step 3 — Run `.agent/workflows/ideate-validate.md`
+
+Explores constraints, success metrics, and competitive positioning. Runs domain exhaustion and vision deepening passes. Compiles `docs/plans/vision.md`.
+
+---
+
+## Quality Gate (Step 12)
+
+### Self-check against Vision rubric
+
+Before presenting to the user, self-check the vision document:
+
+Read .agent/skills/pipeline-rubrics/references/vision-rubric.md before applying the self-check dimensions.
+
+| # | Dimension | Check |
+|---|-----------|-------|
+| 1 | Problem Clarity | Is the problem one sentence, specific, and testable? |
+| 2 | Persona Specificity | Are personas named with pain points + success criteria + switching trigger? |
+| 3 | Feature Completeness | Is MoSCoW complete? Are Must Haves explored to ≥Level 2 depth? |
+| 4 | Constraint Explicitness | Are all axes (budget, timeline, team, compliance, performance) addressed? |
+| 5 | Success Measurability | Are there concrete numbers/thresholds? |
+| 6 | Competitive Positioning | Are competitors named with differentiation? |
+| 7 | Open Question Resolution | Do all open questions have owners + deadlines? |
+| 8 | **Input-Output Proportionality** | Is the vision output proportional to input richness? Rich inputs must produce rich visions. |
+| 9 | **Domain Coverage** | Has every identified domain been explored to ≥3 levels of depth? Are appendices created for complex domains? |
+| 10 | **Input-Output Fidelity** | Two-layer check: (1) Source → `ideation.md`: every major section of the original source maps to `ideation.md` (checked during seeding in Step 1.5); (2) `ideation.md` → `vision.md`: every section in `ideation.md` maps to `vision.md` — nothing dropped during compilation (checked in Step 11). |
+
+For any dimension that scores ⚠️ or ❌, resolve it NOW — don't present a document with known gaps.
+Loop back to the relevant step and work through it with the user.
+
+> **Dimension 8 is critical.** If the user provided a 738KB input document and the vision
+> is under 200 lines without appendices, this is a FAIL. Go back and extract what was lost.
+
+> **Note**: This is an internal self-check, not a formal audit. For a rigorous,
+> independent audit with evidence citations, run `/audit-ambiguity vision` as a
+> separate step after this workflow completes.
+
+### Request review
+
+Use `notify_user` to request review of `docs/plans/vision.md` (and any appendices). Include:
+- Summary of the self-check results (all 10 dimensions)
+- Any areas where you resolved gaps during the self-check
+- The final domain coverage map
+
+The vision must be approved before proceeding. Do NOT proceed to the next step until the user sends a message explicitly approving this output. Proposing next steps is not the same as receiving approval. Wait for explicit approval before continuing.
+
+### Proposed next steps
+
+**Mandatory next step**: Run `/audit-ambiguity vision` for all inputs, regardless of input type. Even a rich document can have gaps the agent missed. The audit is cheap; the cost of a gap propagating to architecture is high. Do not propose `/create-prd` until `/audit-ambiguity vision` has run.