deepflow 0.1.87 → 0.1.88

package/src/commands/df/auto.md

@@ -5,80 +5,41 @@ description: Set up and launch fully autonomous execution with plan generation a
 
 # /df:auto — Autonomous Mode Setup
 
-Set up and launch fully autonomous execution. Runs `/df:plan` if no PLAN.md exists, takes a ratchet snapshot, then starts `/loop 1m /df:auto-cycle`.
+Set up and launch fully autonomous execution. Run `/df:plan` if no PLAN.md, take ratchet snapshot, start `/loop 1m /df:auto-cycle`.
 
 **NEVER:** use EnterPlanMode, use ExitPlanMode
 
-## Usage
-```
-/df:auto    # Set up and start autonomous loop
-```
-
 ## Behavior
 
 ### 1. RUN PLAN IF NEEDED
 
-```
-If PLAN.md does not exist:
-  → Run /df:plan via Skill tool (skill: "df:plan", no args)
-  → Wait for plan to complete before continuing
-If PLAN.md exists:
-  → Skip planning, proceed to step 2
-```
+If PLAN.md missing → run `/df:plan` via Skill tool, wait for completion. If exists → skip.
 
 ### 2. RATCHET SNAPSHOT
 
-Before starting the loop, snapshot pre-existing test files so the ratchet has a stable baseline:
+Snapshot pre-existing test files for stable ratchet baseline:
 
 ```bash
-# Snapshot pre-existing test files (only these count for ratchet)
 git ls-files | grep -E '\.(test|spec)\.[^/]+$|^test_|_test\.[^/]+$|^tests/|__tests__/' \
   > .deepflow/auto-snapshot.txt
-
 echo "Ratchet snapshot: $(wc -l < .deepflow/auto-snapshot.txt) pre-existing test files"
 ```
 
-**Only pre-existing test files are used for ratchet evaluation.** New test files created by agents during implementation do not influence pass/fail decisions. This prevents agents from gaming the ratchet by writing tests that pass trivially.
+Only pre-existing tests count for ratchet. New agent-created tests are excluded to prevent gaming.
 
 ### 3. START LOOP
 
-Launch the autonomous cycle loop:
-
 ```
 /loop 1m /df:auto-cycle
 ```
 
-This starts `/df:auto-cycle` on a 1-minute recurring interval. Each invocation runs with fresh context — no coordination overhead, zero LLM tokens on loop management.
+Each invocation gets fresh context — zero LLM tokens on loop management.
 
 ## Rules
 
 | Rule | Detail |
 |------|--------|
-| Plan once | Only runs `/df:plan` if PLAN.md is absent |
-| Snapshot before loop | Ratchet baseline is set before any agents run |
-| No lead agent | No custom orchestrator — `/loop` is a native Claude Code feature |
-| Zero loop overhead | Loop coordination uses zero LLM tokens |
-| Cycle logic lives in `/df:auto-cycle` | This command is setup only |
-
-## Example
-
-```
-/df:auto
-
-No PLAN.md found — running /df:plan...
-  ✓ Plan generated — 1 spec, 5 tasks.
-
-Ratchet snapshot: 12 pre-existing test files
-
-Starting loop: /loop 1m /df:auto-cycle
-```
-
-```
-/df:auto
-
-PLAN.md exists — skipping plan.
-
-Ratchet snapshot: 12 pre-existing test files
-
-Starting loop: /loop 1m /df:auto-cycle
-```
+| Plan once | Only runs `/df:plan` if PLAN.md absent |
+| Snapshot before loop | Ratchet baseline set before any agents run |
+| No lead agent | `/loop` is native Claude Code — no custom orchestrator |
+| Cycle logic in `/df:auto-cycle` | This command is setup only |

package/src/commands/df/consolidate.md

@@ -5,62 +5,38 @@ description: Remove duplicates and superseded entries from decisions file, promo
 
 # /df:consolidate — Consolidate Decisions
 
-## Purpose
 Remove duplicates, superseded entries, and promote stale provisionals. Keep decisions.md dense and useful.
 
-**NEVER:** use EnterPlanMode, use ExitPlanMode
-
-## Usage
-```
-/df:consolidate          # Consolidate decisions.md
-```
+**NEVER:** use EnterPlanMode, ExitPlanMode
 
 ## Behavior
 
 ### 1. LOAD
-Read `.deepflow/decisions.md`. If missing or empty, report and exit.
-
-Shell injection (use output directly — no manual file reads needed):
-- `` !`cat .deepflow/decisions.md 2>/dev/null || echo 'NOT_FOUND'` ``
+Read `.deepflow/decisions.md` via `` !`cat .deepflow/decisions.md 2>/dev/null || echo 'NOT_FOUND'` ``. If missing/empty, report and exit.
 
-### 2. ANALYZE
-Model-driven analysis (not regex):
-- Identify duplicate decisions (same meaning, different wording)
-- Identify superseded decisions (later entry contradicts earlier)
+### 2. ANALYZE (model-driven, not regex)
+- Identify duplicates (same meaning, different wording)
+- Identify superseded entries (later contradicts earlier)
 - Identify stale `[PROVISIONAL]` entries (>30 days old, no resolution)
 
 ### 3. CONSOLIDATE
-- Remove duplicates (keep the more precise wording)
-- Silently remove superseded entries (the later decision wins)
-- Promote stale `[PROVISIONAL]` to `[DEBT]` (needs revisiting)
-- Preserve all `[APPROACH]` entries unless superseded
-- Preserve all `[ASSUMPTION]` entries unless invalidated
-- Target: 200-500 lines (if currently longer)
+- Remove duplicates (keep more precise wording)
+- Remove superseded entries (later decision wins)
+- Promote stale `[PROVISIONAL]` → `[DEBT]`
+- Preserve `[APPROACH]` unless superseded, `[ASSUMPTION]` unless invalidated
+- Target: 200-500 lines if currently longer
 - When in doubt, keep both entries (conservative)
 
 ### 4. WRITE
 - Rewrite `.deepflow/decisions.md` with consolidated content
-- Write timestamp to `.deepflow/last-consolidated.json`:
-  ```json
-  { "last_consolidated": "{ISO-8601 timestamp}" }
-  ```
+- Write `{ "last_consolidated": "{ISO-8601}" }` to `.deepflow/last-consolidated.json`
 
 ### 5. REPORT
-```
-✓ Consolidated: {before} → {after} lines, {n} removed, {n} promoted to [DEBT]
-```
-
-## Tags
-| Tag | Meaning | Source |
-|-----|---------|--------|
-| `[APPROACH]` | Firm decision | Auto-extraction, /df:note |
-| `[PROVISIONAL]` | Revisit later | Auto-extraction, /df:note |
-| `[ASSUMPTION]` | Unverified | Auto-extraction, /df:note |
-| `[DEBT]` | Needs revisiting | Consolidation only |
+`✓ Consolidated: {before} → {after} lines, {n} removed, {n} promoted to [DEBT]`
 
 ## Rules
+
 - Conservative: when in doubt, keep both entries
 - Never add new decisions — only remove, merge, or re-tag
-- [DEBT] is never manually assigned — only produced by consolidation
+- `[DEBT]` is only produced by consolidation, never manually assigned
 - Preserve chronological ordering within sections
-- decisions.md stays a single flat file, human-readable

package/src/commands/df/debate.md

@@ -8,54 +8,35 @@ allowed-tools: [Read, Grep, Glob, Agent]
 
 ## Orchestrator Role
 
-You coordinate reasoner agents to debate a problem from multiple perspectives, then synthesize their arguments into a structured document.
+Coordinate reasoner agents to debate a problem from multiple perspectives, then synthesize into a structured document.
 
-**NEVER:** use TaskOutput, use `run_in_background`, use Explore agents, use EnterPlanMode, use ExitPlanMode
+**NEVER:** use TaskOutput, `run_in_background`, Explore agents, EnterPlanMode, ExitPlanMode
 
 **ONLY:** Gather codebase context (Glob/Grep/Read), spawn reasoner agents (non-background), write debate file, respond conversationally
 
----
-
-## Purpose
-Generate a multi-perspective analysis of a problem before formalizing into a spec. Surfaces tensions, trade-offs, and blind spots that a single perspective would miss.
-
-## Usage
-```
-/df:debate <name>
-```
-
-## Skills & Agents
+## Agents
 
-**Use Task tool to spawn agents:**
-| Agent | subagent_type | model | Purpose |
-|-------|---------------|-------|---------|
+| Agent | subagent_type | model | Focus |
+|-------|---------------|-------|-------|
 | User Advocate | `reasoner` | `opus` | UX, simplicity, real user needs |
 | Tech Skeptic | `reasoner` | `opus` | Technical risks, hidden complexity, feasibility |
 | Systems Thinker | `reasoner` | `opus` | Integration, scalability, long-term effects |
 | LLM Efficiency | `reasoner` | `opus` | Token density, minimal scaffolding, navigable structure |
 | Synthesizer | `reasoner` | `opus` | Merge perspectives into consensus + tensions |
 
----
-
 ## Behavior
 
 ### 1. SUMMARIZE
-
-Summarize conversation context in ~200 words: core problem, key requirements, constraints, user priorities. Passed to each perspective agent.
+Summarize conversation context in ~200 words: core problem, requirements, constraints, user priorities. Passed to each perspective agent.
 
 ### 2. GATHER CODEBASE CONTEXT
-
-Ground the debate in what actually exists. Glob/Grep/Read relevant files (up to 5-6, focus on core logic).
-
-Produce a ~300 word codebase summary: what exists, key interfaces/contracts, current limitations, dependencies. Passed to every perspective agent so they argue from facts, not assumptions.
+Glob/Grep/Read relevant files (up to 5-6, focus on core logic). Produce ~300 word codebase summary: what exists, key interfaces, current limitations, dependencies. Passed to every agent.
 
 ### 3. SPAWN PERSPECTIVES
 
-**Spawn ALL 4 perspective agents in ONE message (non-background, parallel):**
-
-Each agent receives the same preamble + codebase context but a different role lens.
+**Spawn ALL 4 perspective agents in ONE message (parallel, non-background).** Each receives the shared preamble + a role-specific lens.
 
-**Shared preamble for all perspectives:**
+**Shared preamble (included in every agent prompt):**
 ```
 ## Context
 {summary}
@@ -71,146 +52,36 @@ Provide:
 Keep response under 400 words.
 ```
 
-**Perspective-specific role lenses (append to preamble):**
-
-```python
-# All 4 in a single message — parallel, non-background:
-
-Task(subagent_type="reasoner", model="opus", prompt="""
-{shared_preamble}
-
-## Your Role: USER ADVOCATE
-Argue from the perspective of the end user. Focus on:
-- Simplicity and ease of use
-- Real user needs vs assumed needs
-- Friction points and cognitive load
-- Whether the solution matches how users actually think
-""")
-
-Task(subagent_type="reasoner", model="opus", prompt="""
-{shared_preamble}
-
-## Your Role: TECH SKEPTIC
-Challenge technical assumptions and surface hidden complexity. Focus on:
-- What could go wrong technically
-- Hidden dependencies or coupling
-- Complexity that seems simple but isn't
-- Maintenance burden over time
-""")
-
-Task(subagent_type="reasoner", model="opus", prompt="""
-{shared_preamble}
-
-## Your Role: SYSTEMS THINKER
-Analyze how this fits into the broader system. Focus on:
-- Integration with existing components
-- Scalability implications
-- Second-order effects and unintended consequences
-- Long-term evolution and extensibility
-""")
-
-Task(subagent_type="reasoner", model="opus", prompt="""
-{shared_preamble}
-
-## Your Role: LLM EFFICIENCY
-Evaluate from the perspective of LLM consumption and interaction. Focus on:
-- Token density: can the output be consumed efficiently by LLMs?
-- Minimal scaffolding: avoid ceremony that adds tokens without information
-- Navigable structure: can an LLM quickly find what it needs?
-- Attention budget: does the design respect limited context windows?
-""")
-```
-
-### 4. SYNTHESIZE
-
-After all 4 perspectives return, spawn 1 additional reasoner to synthesize:
-
-```python
-Task(subagent_type="reasoner", model="opus", prompt="""
-You are the SYNTHESIZER. Four perspectives have debated a design problem.
-
-## Context
-{summary}
-
-## User Advocate's Arguments
-{user_advocate_response}
-
-## Tech Skeptic's Arguments
-{tech_skeptic_response}
-
-## Systems Thinker's Arguments
-{systems_thinker_response}
+**Role lenses (append one per agent):**
 
-## LLM Efficiency's Arguments
-{llm_efficiency_response}
+| Role | Focus areas |
+|------|------------|
+| USER ADVOCATE | Simplicity, real vs assumed needs, friction, cognitive load, user mental model |
+| TECH SKEPTIC | What could go wrong, hidden dependencies/coupling, deceptive simplicity, maintenance burden |
+| SYSTEMS THINKER | Integration with existing components, scalability, second-order effects, extensibility |
+| LLM EFFICIENCY | Token density, minimal ceremony, navigable structure, attention budget |
 
-## Your Task
-Synthesize these perspectives into:
+### 4. SYNTHESIZE
 
-1. **Consensus** — Points where all or most perspectives agree
+After all 4 return, spawn 1 synthesizer agent. Pass context summary + all 4 responses. Synthesizer produces (under 500 words):
+1. **Consensus** — Points where perspectives agree
 2. **Tensions** — Unresolved disagreements and genuine trade-offs
-3. **Open Decisions** — Questions that need human judgment to resolve
-4. **Recommendation** — Your balanced recommendation considering all perspectives
-
-Be specific. Name the tensions, don't smooth them over.
+3. **Open Decisions** — Questions needing human judgment
+4. **Recommendation** — Balanced recommendation considering all perspectives
 
-Keep response under 500 words.
-""")
-```
+Instruction: "Be specific. Name the tensions, don't smooth them over."
 
 ### 5. WRITE DEBATE FILE
 
-Create `specs/.debate-{name}.md` with sections: Context · Codebase Context · Perspectives (User Advocate / Tech Skeptic / Systems Thinker / LLM Efficiency) · Synthesis (Consensus / Tensions / Open Decisions / Recommendation).
+Create `specs/.debate-{name}.md` with sections: Context, Codebase Context, Perspectives (User Advocate / Tech Skeptic / Systems Thinker / LLM Efficiency), Synthesis (Consensus / Tensions / Open Decisions / Recommendation).
 
 ### 6. CONFIRM
 
 Present key tensions and open decisions, then: `Next: Run /df:spec {name} to formalize into a specification`
 
----
-
 ## Rules
 
-- **All 4 perspective agents MUST be spawned in ONE message** (parallel, non-background)
-- **Codebase context is gathered by the orchestrator** (step 2) and passed to agents via prompt
-- Reasoner agents receive context through their prompt, not by reading files themselves
-- The debate file goes in `specs/` so `/df:spec` can reference it
-- File name MUST be `.debate-{name}.md` (dot prefix = auxiliary file)
-- Keep each perspective under 400 words, synthesis under 500 words
-
-## Example
-
-```
-USER: /df:debate auth
-
-CLAUDE: Let me summarize what we've discussed and understand the current
-codebase before getting multiple perspectives on the authentication design.
-
-[Summarizes: ~200 words about auth requirements from conversation]
-
-[Globs/Greps/Reads relevant auth files — middleware, routes, config]
-
-[Produces ~300 word codebase summary of what exists]
-
-[Spawns 4 reasoner agents in parallel — each receives both summaries]
-
-[All 4 return their arguments]
-
-[Spawns synthesizer agent with all 4 perspectives]
-
-[Synthesizer returns consensus, tensions, open decisions, recommendation]
-
-[Writes specs/.debate-auth.md]
-
-✓ Created specs/.debate-auth.md
-
-Key tensions:
-- OAuth complexity vs simpler API key approach
-- User convenience (social login) vs privacy concerns
-- Centralized auth service vs per-route middleware
-
-Open decisions:
-- Session storage strategy (JWT vs server-side)
-- Token expiration policy
-
-Next: Run /df:spec auth to formalize into a specification
-```
+- ALL 4 perspective agents MUST be spawned in ONE message (parallel, non-background)
+- Orchestrator gathers codebase context (step 2), passes to agents via prompt — agents never read files
+- File name MUST be `.debate-{name}.md` (dot prefix = auxiliary file, lives in `specs/`)
+- Word limits: each perspective <400 words, synthesis <500 words

package/src/commands/df/discover.md

@@ -6,18 +6,11 @@ allowed-tools: [AskUserQuestion, Read, Agent]
 
 # /df:discover — Deep Problem Exploration
 
-## Orchestrator Role
-
 You are a Socratic questioner. Your ONLY job is to ask questions that surface hidden requirements, assumptions, and constraints.
 
 **NEVER:** Read source files directly, use Glob/Grep directly, proactively spawn agents, create files (except `.deepflow/decisions.md`), run git, use TaskOutput, use Task tool, use EnterPlanMode, use ExitPlanMode
 
-**ONLY:** Ask questions using `AskUserQuestion` tool, respond conversationally, and spawn context-fetch agents **when the user explicitly requests it**
-
----
-
-## Purpose
-Explore a problem space deeply before formalizing into specs. Surface motivations, constraints, scope boundaries, success criteria, and anti-goals through structured questioning.
+**ONLY:** Ask questions via `AskUserQuestion`, respond conversationally, spawn context-fetch agents **only when the user explicitly requests it**.
 
 ## Usage
 ```
@@ -26,198 +19,59 @@ Explore a problem space deeply before formalizing into specs. Surface motivation
 
 ## Behavior
 
-Work through these phases organically. You don't need to announce phases — let the conversation flow naturally. Move to the next phase when the current one feels sufficiently explored.
-
-### Phase 1: MOTIVATION
-Why does this need to exist? What problem does it solve? Who suffers without it?
-
-Example questions:
-- What triggered the need for this?
-- Who will use this and what's their current workaround?
-- What happens if we don't build this?
-
-### Phase 2: CONTEXT
-What already exists? What has been tried? What's the current state?
-
-Example questions:
-- Is there existing code or infrastructure that relates to this?
-- Have you tried solving this before? What worked/didn't?
-- Are there external systems or APIs involved?
-
-### Phase 3: SCOPE
-What's in? What's out? What's the minimum viable version?
-
-Example questions:
-- What's the smallest version that would be useful?
-- What features feel essential vs nice-to-have?
-- Are there parts you explicitly want to exclude?
-
-### Phase 4: CONSTRAINTS
-Technical limits, time pressure, resource boundaries?
+Work through phases organically. Don't announce phases — let conversation flow naturally. Move on when a phase feels sufficiently explored.
 
-Example questions:
-- Are there performance requirements or SLAs?
-- What technologies are non-negotiable?
-- Is there a deadline or timeline pressure?
+| Phase | Purpose |
+|-------|---------|
+| 1. MOTIVATION | Why does this need to exist? What problem? Who suffers without it? |
+| 2. CONTEXT | What exists? What's been tried? Current state? External systems? |
+| 3. SCOPE | What's in/out? Minimum viable version? Essential vs nice-to-have? |
+| 4. CONSTRAINTS | Performance requirements? Non-negotiable tech? Timeline pressure? |
+| 5. SUCCESS | How to verify it works? What metrics? What makes you confident to ship? |
+| 6. ANTI-GOALS | What to explicitly NOT build? Common over-engineering traps? Failed approaches elsewhere? |
 
-### Phase 5: SUCCESS
-How do we know it worked? What does "done" look like?
+## Questioning Rules
 
-Example questions:
-- How will you verify this works correctly?
-- What metrics would indicate success?
-- What would make you confident enough to ship?
+- Use `AskUserQuestion` for structured questions with options. Max **4 questions per call** (tool limit). Headers **≤12 chars**.
+- Mix structured questions with conversational follow-ups.
+- Follow up on surprising/unclear answers — don't march through phases mechanically.
+- **Never re-ask answered questions.** Review prior answers before composing each call. If a topic was settled, reference the prior answer and move forward.
+- Keep responses short between questions — don't lecture. Acknowledge answers briefly.
 
-### Phase 6: ANTI-GOALS
-What should we explicitly NOT do? What traps to avoid?
+## On-Demand Context Fetching
 
-Example questions:
-- What's the most common way this kind of feature gets over-engineered?
-- Are there approaches you've seen fail elsewhere?
-- What should we explicitly avoid building?
-
----
-
-## Rules
-
-### Questioning Rules
-- Use `AskUserQuestion` tool for structured questions with options
-- Maximum **4 questions per `AskUserQuestion` call** (tool limit)
-- Headers must be **≤12 characters**
-- Mix structured questions (AskUserQuestion) with conversational follow-ups
-- Ask follow-up questions based on answers — don't just march through phases mechanically
-- Go deeper on surprising or unclear answers
-### Behavioral Rules
-- Keep your responses short between questions — don't lecture
-- Acknowledge answers briefly before asking the next question
-
-### On-Demand Context Fetching
-
-When the user explicitly asks you to look at code or a URL (e.g., "olha no código", "vê esse link", "look at src/auth/", "check https://docs.example.com"), fetch context using a sub-agent.
-
-**Trigger:** Intent-based detection — the user must explicitly request it. NEVER proactively fetch context.
+**Trigger:** User explicitly asks to look at code or a URL (e.g., "look at src/auth/", "check this link"). NEVER proactively fetch.
 
 **For codebase context:**
 ```
-Agent(subagent_type="Explore", model="haiku", prompt="""
-Read and summarize the following: {what the user asked to see}
-
-Rules:
-- Return ONLY factual observations: what files exist, what functions/types are defined, what patterns are used
-- Do NOT suggest solutions, improvements, or architectural changes
-- Do NOT give opinions on code quality
-- Keep response under 4000 tokens
-- Format: bullet points of facts
-""")
+Agent(subagent_type="Explore", model="haiku", prompt="Read and summarize: {target}. Rules: factual observations only (files, functions, types, patterns). No solutions/improvements/opinions. Under 4000 tokens. Bullet points.")
 ```
 
 **For URL context:**
 ```
-Agent(subagent_type="Explore", model="haiku", prompt="""
-Use the browse-fetch skill to fetch this URL: {url}
-
-Then summarize what the page contains.
-
-Rules:
-- Return ONLY factual observations: what the documentation says, what APIs are described, what patterns are shown
-- Do NOT suggest how to use this in the project
-- Do NOT give opinions or recommendations
-- Keep response under 4000 tokens
-- Format: bullet points of facts
-""")
+Agent(subagent_type="Explore", model="haiku", prompt="Use browse-fetch skill to fetch: {url}. Summarize contents. Rules: factual observations only. No recommendations. Under 4000 tokens. Bullet points.")
 ```
 
-**After receiving context:** Briefly share the factual summary with the user, then **resume Socratic questioning** incorporating the new facts. Do NOT shift to suggesting solutions.
-
-**Soft cap:** ~3 context fetches per discover session to protect context window.
+After receiving context: share factual summary, then **resume Socratic questioning** incorporating new facts. Do NOT shift to suggesting solutions. Soft cap: ~3 context fetches per session.
 
-### When the User Wants to Move On
-When the user signals they want to advance (e.g., "I think that's enough", "let's move on", "ready for next step"):
+## When the User Wants to Move On
 
-```
-Great, we've covered a lot of ground. To analyze this from multiple perspectives, run:
+Assess spec layer reached:
 
-/df:debate {name}
+| Layer | Criteria |
+|-------|----------|
+| L0 | Objective clear |
+| L1 | Requirements enumerated |
+| L2 | Testable ACs defined |
+| L3 | Constraints + scope + tech context |
 
-Or if you want to go straight to a spec:
-
-/df:spec {name}
 ```
+Great, we've covered enough for an L{N} spec ({label}).
 
-## Example
+/df:spec {name}   — generate spec at current layer
+/df:debate {name}  — analyze from multiple perspectives first
 
-```
-USER: /df:discover auth
-
-CLAUDE: Let's explore the authentication problem space.
-
-[Uses AskUserQuestion]
-{
-  "questions": [
-    {
-      "question": "What's driving the need for auth right now?",
-      "header": "Motivation",
-      "multiSelect": false,
-      "options": [
-        {"label": "Security gap", "description": "Current system has no auth or weak auth"},
-        {"label": "New users", "description": "Opening up to users who need access control"},
-        {"label": "Compliance", "description": "Regulatory or policy requirement"}
-      ]
-    },
-    {
-      "question": "Who are the primary users that will authenticate?",
-      "header": "Users",
-      "multiSelect": true,
-      "options": [
-        {"label": "End users", "description": "Public-facing users of the product"},
-        {"label": "Internal team", "description": "Your team or organization members"},
-        {"label": "API clients", "description": "Other services or integrations"}
-      ]
-    }
-  ]
-}
-
-USER: [Selects: Security gap, End users + API clients]
-
-CLAUDE: So there's a real security gap and you need to cover both human users
-and machine clients. That's two different auth flows to think about.
-
-[Uses AskUserQuestion]
-{
-  "questions": [
-    {
-      "question": "Do end users currently have any way to identify themselves?",
-      "header": "Current state",
-      "multiSelect": false,
-      "options": [
-        {"label": "Nothing", "description": "Completely open, no identification"},
-        {"label": "Basic auth", "description": "Simple username/password exists"},
-        {"label": "Third-party", "description": "Using external auth provider already"}
-      ]
-    },
-    {
-      "question": "For API clients, what authentication exists today?",
-      "header": "API auth",
-      "multiSelect": false,
-      "options": [
-        {"label": "None", "description": "APIs are open"},
-        {"label": "API keys", "description": "Static keys in headers"},
-        {"label": "OAuth/JWT", "description": "Token-based auth already in place"}
-      ]
-    }
-  ]
-}
-
-[... continues through phases based on answers ...]
-
-USER: I think we've covered everything, let's move on.
-
-CLAUDE: Great, we've covered a lot of ground. To analyze this from multiple
-perspectives, run:
-
-/df:debate auth
-
-Or if you want to go straight to a spec:
-
-/df:spec auth
+{If L0-L1:}
+At L{N}, /df:plan will generate spikes to discover what's missing.
+Deepen the spec later with /df:spec {name} after spikes run.
 ```