@rune-kit/rune 2.3.0 → 2.3.1

package/skills/ba/SKILL.md

@@ -1,351 +1,349 @@
----
-name: ba
-description: Business Analyst agent. Deeply understands user requirements before any planning or coding begins. Asks probing questions, identifies hidden requirements, maps stakeholders, defines scope boundaries, and produces a structured Requirements Document that plan and cook consume.
-metadata:
-  author: runedev
-  version: "0.4.0"
-  layer: L2
-  model: opus
-  group: creation
-  tools: "Read, Glob, Grep"
----
-
-# ba
-
-## Purpose
-
-Business Analyst agent — the ROOT FIX for "Claude works a lot but produces nothing." BA forces deep understanding of WHAT to build before any code is written. It asks probing questions, identifies hidden requirements, maps stakeholders, defines scope boundaries, and produces a structured Requirements Document.
-
-<HARD-GATE>
-BA produces WHAT, not HOW. Never write code. Never plan implementation.
-Output is a Requirements Document → hand off to rune:plan for implementation planning.
-</HARD-GATE>
-
-## Triggers
-
-- Called by `cook` Phase 1 when task is product-oriented (not a simple bug fix)
-- Called by `scaffold` Phase 1 before any project generation
-- `/rune ba <requirement>` — manual invocation
-- Auto-trigger: when user description is > 50 words OR contains business terms (users, revenue, workflow, integration)
-
-## Calls (outbound)
-
-- `scout` (L2): scan existing codebase for context
-- `research` (L3): look up similar products, APIs, integrations
-- `plan` (L2): hand off Requirements Document for implementation planning
-- `brainstorm` (L2): when multiple approaches exist for a requirement
-
-## Called By (inbound)
-
-- `cook` (L1): before Phase 2 PLAN, when task is non-trivial
-- `scaffold` (L1): Phase 1, before any project generation
-- `plan` (L2): when plan receives vague requirements
-- User: `/rune ba` direct invocation
-
-## Cross-Hub Connections
-
-- `ba` → `plan` — ba produces requirements, plan produces implementation steps
-- `ba` → `brainstorm` — ba calls brainstorm when multiple requirement approaches exist
-- `ba` ↔ `cook` — cook calls ba for non-trivial tasks, ba feeds requirements into cook's pipeline
-- `ba` → `scaffold` — scaffold requires ba output before project generation
-
-## Executable Steps
-
-### Step 1 — Intake & Classify
-
-Read the user's request. Classify the requirement type:
-
-| Type | Signal | Depth |
-|------|--------|-------|
-| Feature Request | "add X", "build Y", "I want Z" | Full BA cycle (Steps 1-7) |
-| Bug Fix | "broken", "error", "doesn't work" | Skip BA → direct to debug |
-| Refactor | "clean up", "refactor", "restructure" | Light BA (Step 1 + Step 4 only) |
-| Integration | "connect X to Y", "integrate with Z" | Full BA + API research |
-| Greenfield | "new project", "build from scratch" | Full BA + market context |
-
-If Bug Fix → skip BA, route to cook/debug directly.
-If Refactor → light version (Step 1 + Step 4 only).
-
-If existing codebase → invoke `rune:scout` for context before proceeding.
-
-### Step 2 — Requirement Elicitation (the "5 Questions")
-
-Ask exactly 5 probing questions, ONE AT A TIME (not all at once):
-
-1. **WHO** — "Who is the end user? What's their technical level? What are they doing right before and after using this feature?"
-2. **WHAT** — "What specific outcome do they need? What does 'done' look like from the user's perspective?"
-3. **WHY** — "Why do they need this? What problem does this solve? What happens if we don't build it?"
-4. **BOUNDARIES** — "What should this NOT do? What's explicitly out of scope?"
-5. **CONSTRAINTS** — "Any technical constraints? (existing APIs, performance requirements, security needs, deadlines)"
-
-<HARD-GATE>
-Do NOT skip questions. Do NOT answer your own questions.
-If user says "just build it" → respond with: "I'll build it better with 2 minutes of context. Question 1: [WHO]"
-Each question must be asked separately, wait for answer before next.
-Exception: if user provides a detailed spec/PRD → extract answers from it, confirm with user.
-</HARD-GATE>
-
-#### Structured Elicitation Frameworks
-
-Choose the framework that fits the requirement type. Use it to STRUCTURE the 5 Questions above, not replace them.
-
-| Framework | When to Use | Structure |
-|-----------|------------|-----------|
-| **PICO** | Clinical, research, data-driven, or A/B testing features | **P**opulation (who), **I**ntervention (what change), **C**omparison (vs what), **O**utcome (measurable result) |
-| **INVEST** | User stories for sprint-sized features | **I**ndependent, **N**egotiable, **V**aluable, **E**stimable, **S**mall, **T**estable |
-| **Jobs-to-be-Done** | Product features, user workflows | "When [situation], I want to [motivation] so I can [expected outcome]" |
-
-> Source: K-Dense claude-scientific-skills (literature-review PICO pattern), adapted for software BA.
-
-**PICO Example (data feature):**
-```
-P: Dashboard users monitoring real-time metrics
-I: Add anomaly detection alerts
-C: vs. current manual threshold setting
-O: 30% faster incident detection (measurable KPI)
-```
-
-**When to apply which:**
-- Feature Request → INVEST (ensures stories are sprint-ready)
-- Data/Analytics/Research feature → PICO (forces measurable outcome definition)
-- Product/UX feature → Jobs-to-be-Done (keeps focus on user motivation)
-- Integration → 5 Questions only (frameworks add noise for plumbing tasks)
-
-### Step 3 — Hidden Requirement Discovery
-
-After the 5 questions, analyze for requirements the user DIDN'T mention:
-
-**Technical hidden requirements:**
-- Authentication/authorization needed?
-- Rate limiting needed?
-- Data persistence needed? (what DB, what schema)
-- Error handling strategy?
-- Offline/fallback behavior?
-- Mobile responsiveness?
-- Accessibility requirements?
-- Internationalization?
-
-**Business hidden requirements:**
-- What happens on failure? (graceful degradation)
-- What data needs to be tracked? (analytics events)
-- Who else is affected? (other teams, other systems)
-- What are the edge cases? (empty state, max limits, concurrent access)
-- Regulatory/compliance needs? (GDPR, PCI, HIPAA)
-
-Present discovered hidden requirements to user: "I found N additional requirements you may not have considered: [list]. Which are relevant?"
-
-### Step 3.5 — Completeness Scoring (Options & Alternatives)
-
-When presenting options, alternatives, or scope decisions to the user, rate each with a **Completeness score (X/10)**:
-
-| Score | Meaning | Guidance |
-|-------|---------|----------|
-| 9-10 | Complete — all edge cases, full coverage, production-ready | Always recommend |
-| 7-8 | Covers happy path, skips some edges | Acceptable for MVP |
-| 4-6 | Shortcut — defers significant work to later | Flag trade-off explicitly |
-| 1-3 | Minimal viable, technical debt guaranteed | Only for time-critical emergencies |
-
-**Always recommend the higher-completeness option** unless the delta is truly expensive. With AI-assisted coding, the marginal cost of completeness is near-zero:
-
-| Task Type | Human Team | AI-Assisted | Compression |
-|-----------|-----------|-------------|-------------|
-| Boilerplate / scaffolding | 2 days | 15 min | ~100x |
-| Test writing | 1 day | 15 min | ~50x |
-| Feature implementation | 1 week | 30 min | ~30x |
-| Bug fix + regression test | 4 hours | 15 min | ~20x |
-
-**When showing effort estimates**, always show both scales: `(human: ~X / AI: ~Y)`. The compression ratio reframes "too expensive" into "15 minutes more."
-
-**Anti-pattern**: "Choose B — it covers 90% of the value with less code." → If A is only 70 lines more, choose A. The last 10% is where production bugs hide.
-
-> Source: garrytan/gstack v0.9.0 — "Boil the Lake" principle. Completeness is cheap when AI makes the marginal cost near-zero.
-
-### Step 4 — Scope Definition
-
-Based on all gathered information, produce:
-
-**In-Scope** (explicitly included):
-- [list of features/behaviors that WILL be built]
-
-**Out-of-Scope** (explicitly excluded):
-- [list of things we WON'T build — prevents scope creep]
-
-**Assumptions** (things we're assuming without proof):
-- [each assumption is a risk if wrong]
-
-**Dependencies** (things that must exist before we can build):
-- [APIs, services, libraries, access, existing code]
-
-### Step 5 — User Stories & Acceptance Criteria
-
-For each in-scope feature, generate:
-
-```
-US-1: As a [persona], I want to [action] so that [benefit]
-  AC-1.1: GIVEN [context] WHEN [action] THEN [result]
-  AC-1.2: GIVEN [error case] WHEN [action] THEN [error handling]
-  AC-1.3: GIVEN [edge case] WHEN [action] THEN [graceful behavior]
-```
-
-Rules:
-- Primary user story first, then edge cases
-- Every user story has at least 2 acceptance criteria (happy path + error)
-- Acceptance criteria are TESTABLE — they become test cases in Phase 3
-
-### Step 6 — Non-Functional Requirements (NFRs)
-
-Assess and document ONLY relevant NFRs:
-
-| NFR | Requirement | Measurement |
-|-----|-------------|-------------|
-| Performance | Page load < Xs, API response < Yms | Lighthouse, k6 |
-| Security | Auth required, input validation, OWASP top 10 | sentinel scan |
-| Scalability | Expected users, data volume | Load test target |
-| Reliability | Uptime target, error budget | Monitoring threshold |
-| Accessibility | WCAG 2.2 AA | Axe audit |
-
-Only include NFRs relevant to this specific task. Don't generate a generic checklist.
-
-### Step 7 — Requirements Document
-
-Produce structured output and hand off to `plan`:
-
-```markdown
-# Requirements Document: [Feature Name]
-Created: [date] | BA Session: [summary]
-
-## Context
-[Problem statement — 2-3 sentences]
-
-## Stakeholders
-- Primary user: [who]
-- Affected systems: [what]
-
-## User Stories
-[from Step 5]
-
-## Scope
-### In Scope
-[from Step 4]
-### Out of Scope
-[from Step 4]
-### Assumptions
-[from Step 4]
-
-## Non-Functional Requirements
-[from Step 6]
-
-## Dependencies
-[from Step 4]
-
-## Risks
-- [risk]: [mitigation]
-
-## Next Step
-→ Hand off to rune:plan for implementation planning
-```
-
-Save to `.rune/features/<feature-name>/requirements.md`
-
-## Output Format
-
-```
-# Requirements Document: [Feature Name]
-Created: [date] | BA Session: [summary]
-
-## Context
-[Problem statement — 2-3 sentences]
-
-## Stakeholders
-- Primary user: [who, technical level, workflow context]
-- Affected systems: [existing services, databases, APIs]
-
-## User Stories
-US-1: As a [persona], I want to [action] so that [benefit]
-  AC-1.1: GIVEN [context] WHEN [action] THEN [result]
-  AC-1.2: GIVEN [error case] WHEN [action] THEN [error handling]
-
-## Scope
-### In Scope
-- [feature/behavior 1]
-- [feature/behavior 2]
-### Out of Scope
-- [explicitly excluded 1]
-### Assumptions
-- [assumption — risk if wrong]
-
-## Non-Functional Requirements
-| NFR | Requirement | Measurement |
-|-----|-------------|-------------|
-| [Performance/Security/etc.] | [specific target] | [how to verify] |
-
-## Dependencies
-- [API/service/library]: [status — available/needs setup]
-
-## Risks
-- [risk]: [mitigation strategy]
-
-## Decision Classification
-
-| Category | Meaning | Example |
-|----------|---------|---------|
-| **Decisions** (locked) | User confirmed — agent MUST follow | "Use PostgreSQL, not MongoDB" |
-| **Discretion** (agent decides) | User trusts agent judgment | "Pick the best validation library" |
-| **Deferred** (out of scope) | Explicitly NOT this task | "Mobile app — future phase" |
-
-Plan gates on Decision compliance — Discretion items don't need approval.
-
-## Next Step
-→ Hand off to rune:plan for implementation planning
-```
-
-Saved to `.rune/features/<feature-name>/requirements.md`
-
-## Constraints
-
-1. MUST ask 5 probing questions before producing requirements — no assumptions
-2. MUST identify hidden requirements — the obvious ones are never the full picture
-3. MUST define out-of-scope explicitly — prevents scope creep
-4. MUST produce testable acceptance criteria — they become test cases
-5. MUST NOT write code or plan implementation — BA produces WHAT, plan produces HOW
-6. MUST ask ONE question at a time — don't overwhelm user with 5 questions at once
-7. MUST NOT skip BA for non-trivial tasks — "just build it" gets redirected to Question 1
-
-## Returns
-
-| Artifact | Format | Location |
-|----------|--------|----------|
-| Requirements document | Markdown | `.rune/features/<feature-name>/requirements.md` |
-| User stories with acceptance criteria | Markdown (GIVEN/WHEN/THEN) | inline + requirements.md |
-| Scope definition (in/out/assumptions) | Markdown sections | requirements.md |
-| Non-functional requirements table | Markdown table | requirements.md |
-
-## Sharp Edges
-
-Known failure modes for this skill. Check these before declaring done.
-
-| Failure Mode | Severity | Mitigation |
-|---|---|---|
-| Skipping questions because "requirements are obvious" | CRITICAL | HARD-GATE: 5 questions mandatory, even for "simple" tasks |
-| Answering own questions instead of asking user | HIGH | Questions require USER input — BA doesn't guess |
-| Producing implementation details (HOW) instead of requirements (WHAT) | HIGH | BA outputs requirements doc → plan outputs implementation |
-| All-at-once question dump (asking 5 questions in one message) | MEDIUM | One question at a time, wait for answer before next |
-| Missing hidden requirements (auth, error handling, edge cases) | HIGH | Step 3 checklist is mandatory scan |
-| Requirements doc too verbose (>500 lines) | MEDIUM | Max 200 lines — concise, actionable, testable |
-| Skipping BA for "simple" features that turn out complex | HIGH | Let cook's complexity detection trigger BA, not user judgment |
-| Recommending shortcuts without Completeness Score | MEDIUM | Step 3.5: every option needs X/10 score + dual effort estimate (human vs AI). "90% coverage" is a red flag when 100% costs 15 min more |
-
-## Done When
-
-- Requirement type classified (feature/refactor/integration/greenfield)
-- 5 probing questions asked and answered (or extracted from spec/PRD)
-- Hidden requirements discovered and confirmed with user
-- Scope defined (in/out/assumptions/dependencies)
-- User stories with testable acceptance criteria produced
-- Non-functional requirements assessed (relevant ones only)
-- Requirements Document saved to `.rune/features/<name>/requirements.md`
-- Handed off to `plan` for implementation planning
-
-## Cost Profile
-
-~3000-6000 tokens input, ~1500-3000 tokens output. Opus for deep requirement analysis — understanding WHAT to build is the most expensive mistake to get wrong.
+---
+name: ba
+description: Business Analyst agent. Deeply understands user requirements before any planning or coding begins. Asks probing questions, identifies hidden requirements, maps stakeholders, defines scope boundaries, and produces a structured Requirements Document that plan and cook consume.
+metadata:
+  author: runedev
+  version: "0.4.0"
+  layer: L2
+  model: opus
+  group: creation
+  tools: "Read, Glob, Grep"
+---
+
+# ba
+
+## Purpose
+
+Business Analyst agent — the ROOT FIX for "Claude works a lot but produces nothing." BA forces deep understanding of WHAT to build before any code is written. It asks probing questions, identifies hidden requirements, maps stakeholders, defines scope boundaries, and produces a structured Requirements Document.
+
+<HARD-GATE>
+BA produces WHAT, not HOW. Never write code. Never plan implementation.
+Output is a Requirements Document → hand off to rune:plan for implementation planning.
+</HARD-GATE>
+
+## Triggers
+
+- Called by `cook` Phase 1 when task is product-oriented (not a simple bug fix)
+- Called by `scaffold` Phase 1 before any project generation
+- `/rune ba <requirement>` — manual invocation
+- Auto-trigger: when user description is > 50 words OR contains business terms (users, revenue, workflow, integration)
+
+## Calls (outbound)
+
+- `scout` (L2): scan existing codebase for context
+- `research` (L3): look up similar products, APIs, integrations
+- `plan` (L2): hand off Requirements Document for implementation planning
+- `brainstorm` (L2): when multiple approaches exist for a requirement
+
+## Called By (inbound)
+
+- `cook` (L1): before Phase 2 PLAN, when task is non-trivial
+- `scaffold` (L1): Phase 1, before any project generation
+- `plan` (L2): when plan receives vague requirements
+- User: `/rune ba` direct invocation
+
+## Cross-Hub Connections
+
+- `ba` → `plan` — ba produces requirements, plan produces implementation steps
+- `ba` → `brainstorm` — ba calls brainstorm when multiple requirement approaches exist
+- `ba` ↔ `cook` — cook calls ba for non-trivial tasks, ba feeds requirements into cook's pipeline
+- `ba` → `scaffold` — scaffold requires ba output before project generation
+
+## Executable Steps
+
+### Step 1 — Intake & Classify
+
+Read the user's request. Classify the requirement type:
+
+| Type | Signal | Depth |
+|------|--------|-------|
+| Feature Request | "add X", "build Y", "I want Z" | Full BA cycle (Steps 1-7) |
+| Bug Fix | "broken", "error", "doesn't work" | Skip BA → direct to debug |
+| Refactor | "clean up", "refactor", "restructure" | Light BA (Step 1 + Step 4 only) |
+| Integration | "connect X to Y", "integrate with Z" | Full BA + API research |
+| Greenfield | "new project", "build from scratch" | Full BA + market context |
+
+If Bug Fix → skip BA, route to cook/debug directly.
+If Refactor → light version (Step 1 + Step 4 only).
+
+If existing codebase → invoke `rune:scout` for context before proceeding.
+
+### Step 2 — Requirement Elicitation (the "5 Questions")
+
+Ask exactly 5 probing questions, ONE AT A TIME (not all at once):
+
+1. **WHO** — "Who is the end user? What's their technical level? What are they doing right before and after using this feature?"
+2. **WHAT** — "What specific outcome do they need? What does 'done' look like from the user's perspective?"
+3. **WHY** — "Why do they need this? What problem does this solve? What happens if we don't build it?"
+4. **BOUNDARIES** — "What should this NOT do? What's explicitly out of scope?"
+5. **CONSTRAINTS** — "Any technical constraints? (existing APIs, performance requirements, security needs, deadlines)"
+
+<HARD-GATE>
+Do NOT skip questions. Do NOT answer your own questions.
+If user says "just build it" → respond with: "I'll build it better with 2 minutes of context. Question 1: [WHO]"
+Each question must be asked separately, wait for answer before next.
+Exception: if user provides a detailed spec/PRD → extract answers from it, confirm with user.
+</HARD-GATE>
+
+#### Structured Elicitation Frameworks
+
+Choose the framework that fits the requirement type. Use it to STRUCTURE the 5 Questions above, not replace them.
+
+| Framework | When to Use | Structure |
+|-----------|------------|-----------|
+| **PICO** | Clinical, research, data-driven, or A/B testing features | **P**opulation (who), **I**ntervention (what change), **C**omparison (vs what), **O**utcome (measurable result) |
+| **INVEST** | User stories for sprint-sized features | **I**ndependent, **N**egotiable, **V**aluable, **E**stimable, **S**mall, **T**estable |
+| **Jobs-to-be-Done** | Product features, user workflows | "When [situation], I want to [motivation] so I can [expected outcome]" |
+
+
+**PICO Example (data feature):**
+```
+P: Dashboard users monitoring real-time metrics
+I: Add anomaly detection alerts
+C: vs. current manual threshold setting
+O: 30% faster incident detection (measurable KPI)
+```
+
+**When to apply which:**
+- Feature Request → INVEST (ensures stories are sprint-ready)
+- Data/Analytics/Research feature → PICO (forces measurable outcome definition)
+- Product/UX feature → Jobs-to-be-Done (keeps focus on user motivation)
+- Integration → 5 Questions only (frameworks add noise for plumbing tasks)
+
+### Step 3 — Hidden Requirement Discovery
+
+After the 5 questions, analyze for requirements the user DIDN'T mention:
+
+**Technical hidden requirements:**
+- Authentication/authorization needed?
+- Rate limiting needed?
+- Data persistence needed? (what DB, what schema)
+- Error handling strategy?
+- Offline/fallback behavior?
+- Mobile responsiveness?
+- Accessibility requirements?
+- Internationalization?
+
+**Business hidden requirements:**
+- What happens on failure? (graceful degradation)
+- What data needs to be tracked? (analytics events)
+- Who else is affected? (other teams, other systems)
+- What are the edge cases? (empty state, max limits, concurrent access)
+- Regulatory/compliance needs? (GDPR, PCI, HIPAA)
+
+Present discovered hidden requirements to user: "I found N additional requirements you may not have considered: [list]. Which are relevant?"
+
+### Step 3.5 — Completeness Scoring (Options & Alternatives)
+
+When presenting options, alternatives, or scope decisions to the user, rate each with a **Completeness score (X/10)**:
+
+| Score | Meaning | Guidance |
+|-------|---------|----------|
+| 9-10 | Complete — all edge cases, full coverage, production-ready | Always recommend |
+| 7-8 | Covers happy path, skips some edges | Acceptable for MVP |
+| 4-6 | Shortcut — defers significant work to later | Flag trade-off explicitly |
+| 1-3 | Minimal viable, technical debt guaranteed | Only for time-critical emergencies |
+
+**Always recommend the higher-completeness option** unless the delta is truly expensive. With AI-assisted coding, the marginal cost of completeness is near-zero:
+
+| Task Type | Human Team | AI-Assisted | Compression |
+|-----------|-----------|-------------|-------------|
+| Boilerplate / scaffolding | 2 days | 15 min | ~100x |
+| Test writing | 1 day | 15 min | ~50x |
+| Feature implementation | 1 week | 30 min | ~30x |
+| Bug fix + regression test | 4 hours | 15 min | ~20x |
+
+**When showing effort estimates**, always show both scales: `(human: ~X / AI: ~Y)`. The compression ratio reframes "too expensive" into "15 minutes more."
+
+**Anti-pattern**: "Choose B — it covers 90% of the value with less code." → If A is only 70 lines more, choose A. The last 10% is where production bugs hide.
+
+
+### Step 4 — Scope Definition
+
+Based on all gathered information, produce:
+
+**In-Scope** (explicitly included):
+- [list of features/behaviors that WILL be built]
+
+**Out-of-Scope** (explicitly excluded):
+- [list of things we WON'T build — prevents scope creep]
+
+**Assumptions** (things we're assuming without proof):
+- [each assumption is a risk if wrong]
+
+**Dependencies** (things that must exist before we can build):
+- [APIs, services, libraries, access, existing code]
+
+### Step 5 — User Stories & Acceptance Criteria
+
+For each in-scope feature, generate:
+
+```
+US-1: As a [persona], I want to [action] so that [benefit]
+  AC-1.1: GIVEN [context] WHEN [action] THEN [result]
+  AC-1.2: GIVEN [error case] WHEN [action] THEN [error handling]
+  AC-1.3: GIVEN [edge case] WHEN [action] THEN [graceful behavior]
+```
+
+Rules:
+- Primary user story first, then edge cases
+- Every user story has at least 2 acceptance criteria (happy path + error)
+- Acceptance criteria are TESTABLE — they become test cases in Phase 3
+
+### Step 6 — Non-Functional Requirements (NFRs)
+
+Assess and document ONLY relevant NFRs:
+
+| NFR | Requirement | Measurement |
+|-----|-------------|-------------|
+| Performance | Page load < Xs, API response < Yms | Lighthouse, k6 |
+| Security | Auth required, input validation, OWASP top 10 | sentinel scan |
+| Scalability | Expected users, data volume | Load test target |
+| Reliability | Uptime target, error budget | Monitoring threshold |
+| Accessibility | WCAG 2.2 AA | Axe audit |
+
+Only include NFRs relevant to this specific task. Don't generate a generic checklist.
+
+### Step 7 — Requirements Document
+
+Produce structured output and hand off to `plan`:
+
+```markdown
+# Requirements Document: [Feature Name]
+Created: [date] | BA Session: [summary]
+
+## Context
+[Problem statement — 2-3 sentences]
+
+## Stakeholders
+- Primary user: [who]
+- Affected systems: [what]
+
+## User Stories
+[from Step 5]
+
+## Scope
+### In Scope
+[from Step 4]
+### Out of Scope
+[from Step 4]
+### Assumptions
+[from Step 4]
+
+## Non-Functional Requirements
+[from Step 6]
+
+## Dependencies
+[from Step 4]
+
+## Risks
+- [risk]: [mitigation]
+
+## Next Step
+→ Hand off to rune:plan for implementation planning
+```
+
+Save to `.rune/features/<feature-name>/requirements.md`
+
+## Output Format
+
+```
+# Requirements Document: [Feature Name]
+Created: [date] | BA Session: [summary]
+
+## Context
+[Problem statement — 2-3 sentences]
+
+## Stakeholders
+- Primary user: [who, technical level, workflow context]
+- Affected systems: [existing services, databases, APIs]
+
+## User Stories
+US-1: As a [persona], I want to [action] so that [benefit]
+  AC-1.1: GIVEN [context] WHEN [action] THEN [result]
+  AC-1.2: GIVEN [error case] WHEN [action] THEN [error handling]
+
+## Scope
+### In Scope
+- [feature/behavior 1]
+- [feature/behavior 2]
+### Out of Scope
+- [explicitly excluded 1]
+### Assumptions
+- [assumption — risk if wrong]
+
+## Non-Functional Requirements
+| NFR | Requirement | Measurement |
+|-----|-------------|-------------|
+| [Performance/Security/etc.] | [specific target] | [how to verify] |
+
+## Dependencies
+- [API/service/library]: [status — available/needs setup]
+
+## Risks
+- [risk]: [mitigation strategy]
+
+## Decision Classification
+
+| Category | Meaning | Example |
+|----------|---------|---------|
+| **Decisions** (locked) | User confirmed — agent MUST follow | "Use PostgreSQL, not MongoDB" |
+| **Discretion** (agent decides) | User trusts agent judgment | "Pick the best validation library" |
+| **Deferred** (out of scope) | Explicitly NOT this task | "Mobile app — future phase" |
+
+Plan gates on Decision compliance — Discretion items don't need approval.
+
+## Next Step
+→ Hand off to rune:plan for implementation planning
+```
+
+Saved to `.rune/features/<feature-name>/requirements.md`
+
+## Constraints
+
+1. MUST ask 5 probing questions before producing requirements — no assumptions
+2. MUST identify hidden requirements — the obvious ones are never the full picture
+3. MUST define out-of-scope explicitly — prevents scope creep
+4. MUST produce testable acceptance criteria — they become test cases
+5. MUST NOT write code or plan implementation — BA produces WHAT, plan produces HOW
+6. MUST ask ONE question at a time — don't overwhelm user with 5 questions at once
+7. MUST NOT skip BA for non-trivial tasks — "just build it" gets redirected to Question 1
+
+## Returns
+
+| Artifact | Format | Location |
+|----------|--------|----------|
+| Requirements document | Markdown | `.rune/features/<feature-name>/requirements.md` |
+| User stories with acceptance criteria | Markdown (GIVEN/WHEN/THEN) | inline + requirements.md |
+| Scope definition (in/out/assumptions) | Markdown sections | requirements.md |
+| Non-functional requirements table | Markdown table | requirements.md |
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Skipping questions because "requirements are obvious" | CRITICAL | HARD-GATE: 5 questions mandatory, even for "simple" tasks |
+| Answering own questions instead of asking user | HIGH | Questions require USER input — BA doesn't guess |
+| Producing implementation details (HOW) instead of requirements (WHAT) | HIGH | BA outputs requirements doc → plan outputs implementation |
+| All-at-once question dump (asking 5 questions in one message) | MEDIUM | One question at a time, wait for answer before next |
+| Missing hidden requirements (auth, error handling, edge cases) | HIGH | Step 3 checklist is mandatory scan |
+| Requirements doc too verbose (>500 lines) | MEDIUM | Max 200 lines — concise, actionable, testable |
+| Skipping BA for "simple" features that turn out complex | HIGH | Let cook's complexity detection trigger BA, not user judgment |
+| Recommending shortcuts without Completeness Score | MEDIUM | Step 3.5: every option needs X/10 score + dual effort estimate (human vs AI). "90% coverage" is a red flag when 100% costs 15 min more |
+
+## Done When
+
+- Requirement type classified (feature/refactor/integration/greenfield)
+- 5 probing questions asked and answered (or extracted from spec/PRD)
+- Hidden requirements discovered and confirmed with user
+- Scope defined (in/out/assumptions/dependencies)
+- User stories with testable acceptance criteria produced
+- Non-functional requirements assessed (relevant ones only)
+- Requirements Document saved to `.rune/features/<name>/requirements.md`
+- Handed off to `plan` for implementation planning
+
+## Cost Profile
+
+~3000-6000 tokens input, ~1500-3000 tokens output. Opus for deep requirement analysis — understanding WHAT to build is the most expensive mistake to get wrong.