@rune-kit/rune 2.1.1

package/skills/ba/SKILL.md

@@ -0,0 +1,279 @@
+---
+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.2.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>
+
+### 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 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]
+
+## 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
+
+## 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 |
+
+## 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.

package/skills/brainstorm/SKILL.md

@@ -0,0 +1,266 @@
+---
+name: brainstorm
+description: Creative ideation and solution exploration. Generates multiple approaches with trade-offs, uses structured frameworks (SCAMPER, First Principles), and hands off to plan for structuring.
+metadata:
+  author: runedev
+  version: "0.3.0"
+  layer: L2
+  model: opus
+  group: creation
+  tools: "Read, Glob, Grep"
+---
+
+# brainstorm
+
+## Purpose
+
+Creative ideation and solution exploration. Brainstorm is the creative engine of the Creation group — it generates multiple approaches with trade-offs, explores alternatives using structured frameworks, and hands the selected approach to plan for structuring. Uses opus for deep creative reasoning.
+
+<HARD-GATE>
+Do NOT invoke any implementation skill or write any code until the user has approved the design.
+This applies to EVERY task regardless of perceived simplicity.
+"This is too simple to need a design" is a rationalization. Simple tasks get simple designs (a few sentences), but they still get designs.
+</HARD-GATE>
+
+## Modes
+
+### Discovery Mode (default)
+Normal brainstorming at the start of a task — generate approaches before any code is written.
+
+### Rescue Mode
+Activated when an approach has been tried and **fundamentally failed** — not a bug, but a wrong approach. Rescue mode forces **category-diverse** alternatives instead of variants of the failed approach.
+
+**Rescue Mode triggers:**
+- `cook` Phase 4: Approach Pivot Gate fires (3 debug-fix loops exhausted + re-plan still fails)
+- `debug`: 3-Fix Escalation Rule fires AND root cause is "approach doesn't work" (not a bug in implementation)
+- `fix`: 3 fix attempts fail AND each attempt reveals a different blocker (systemic, not localized)
+- Manual: `/rune brainstorm rescue <what failed and why>`
+
+**Rescue Mode input:**
+```
+mode: "rescue"
+failed_approach: string     — what was tried
+failure_evidence: string[]  — concrete reasons it failed (error messages, blockers, dead ends)
+original_goal: string       — what we're still trying to achieve
+```
+
+**Rescue Mode constraints:**
+1. MUST generate 3-5 approaches (more than Discovery's 2-3 — wider net)
+2. Each approach MUST be a **different category**, not a variant of the failed one
+3. At least 1 approach must be "unconventional" (hacky, wrapper, reverse-engineer, proxy, etc.)
+4. MUST use Collision-Zone Thinking or Inversion Exercise — conventional thinking already failed
+5. MUST explicitly state why each approach is a **different category** from the failed one
+6. Failed approach MUST be listed as "Option X (FAILED)" — visible reminder not to loop back
+
+**Category examples** (approaches in different categories):
+```
+Direct API call ≠ Wrapper/middleware layer ≠ Reverse engineering ≠ Browser automation
+  ≠ Extension/plugin ≠ Proxy/bridge service ≠ Alternative tool entirely
+```
+
+## Triggers
+
+- Called by `cook` when multiple valid approaches exist for a feature (Discovery Mode)
+- Called by `cook` Approach Pivot Gate when current approach fundamentally fails (Rescue Mode)
+- Called by `debug` 3-Fix Escalation when root cause is architectural, not a bug (Rescue Mode)
+- Called by `plan` when architecture decision needs creative exploration (Discovery Mode)
+- `/rune brainstorm <topic>` — manual brainstorming (Discovery Mode)
+- `/rune brainstorm rescue <context>` — manual rescue (Rescue Mode)
+- Auto-trigger: when task description is vague or open-ended (Discovery Mode)
+
+## Calls (outbound)
+
+- `plan` (L2): when idea is selected and needs structuring into actionable steps
+- `research` (L3): gather data for informed brainstorming (existing solutions, benchmarks)
+- `trend-scout` (L3): market context and trends for product-oriented brainstorming
+- `problem-solver` (L3): structured reasoning frameworks (SCAMPER, First Principles, 6 Hats)
+- `sequential-thinking` (L3): evaluating approaches with many variables
+
+## Called By (inbound)
+
+- `cook` (L1): when multiple valid approaches exist for a feature (Discovery Mode)
+- `cook` (L1): Approach Pivot Gate — current approach failed, need category-diverse alternatives (Rescue Mode)
+- `debug` (L2): 3-Fix Escalation when root cause is "wrong approach" not "wrong code" (Rescue Mode)
+- `plan` (L2): when architecture decision needs creative exploration (Discovery Mode)
+- User: `/rune brainstorm <topic>` direct invocation (Discovery Mode)
+- User: `/rune brainstorm rescue <context>` manual rescue (Rescue Mode)
+
+## Cross-Hub Connections
+
+- `brainstorm` ↔ `plan` — bidirectional: brainstorm generates options → plan structures the chosen one, plan needs exploration → brainstorm ideates
+
+## Reasoning Frameworks
+
+### Analytical Frameworks
+```
+SCAMPER          — Substitute, Combine, Adapt, Modify, Put to use, Eliminate, Reverse
+FIRST PRINCIPLES — Break down to fundamentals, rebuild from ground up
+6 THINKING HATS  — Facts, Emotions, Caution, Benefits, Creativity, Process
+CRAZY 8s         — 8 ideas in 8 minutes (rapid ideation)
+```
+
+### Breakthrough Frameworks (when conventional thinking fails)
+
+**Collision-Zone Thinking** — Force unrelated concepts together: "What if we treated X like Y?"
+- Pick two unrelated domains (e.g., services + electrical circuits → circuit breakers)
+- Explore emergent properties from the collision
+- Test where the metaphor breaks → those boundaries reveal design constraints
+- Best source domains: physics, biology, economics, psychology
+- Use when: conventional approaches feel inadequate, need innovation not optimization
+
+**Inversion Exercise** — Flip every assumption: "What if the opposite were true?"
+- List core assumptions ("cache reduces latency", "handle errors when they occur")
+- Invert each: "add latency" → debouncing; "make errors impossible" → type systems
+- Valid inversions expose context-dependence in "obvious" truths
+- Use when: feeling forced into "the only way", stuck on unquestioned assumptions
+
+**Scale Game** — Test at extremes (1000x bigger/smaller) to expose fundamentals
+- Pick a dimension: volume, speed, users, duration, failure rate
+- Test minimum (1000x smaller) AND maximum (1000x bigger)
+- What breaks reveals algorithmic limits; what survives is fundamentally sound
+- Use when: unsure about production scale, edge cases unclear, "it works in dev"
+
+## Executable Steps
+
+### Step 0 — Detect Mode
+
+Check the invocation context:
+- If `mode="rescue"` is set, or caller is Approach Pivot Gate / 3-Fix Escalation → **Rescue Mode**
+- Otherwise → **Discovery Mode**
+
+If Rescue Mode: read `failed_approach` and `failure_evidence` before proceeding. These become anti-constraints — approaches that MUST NOT repeat the failed category.
+
+### Step 1 — Frame the Problem
+State the decision to be made in one clear sentence: "We need to decide HOW TO [achieve X] given [constraints Y]." Identify:
+- Hard constraints (cannot change): budget, existing tech stack, deadlines
+- Soft constraints (prefer to avoid): complexity, breaking changes, unfamiliar tech
+- Success criteria: what does a good solution look like?
+- **[Rescue Mode only]** Anti-constraints: "Approach X was tried and failed because Y — do NOT generate variants of X"
+
+If the problem is unclear, ask the user ONE clarifying question before proceeding.
+
+### Step 2 — Generate Approaches
+
+**Discovery Mode**: Produce exactly 2–3 distinct approaches.
+**Rescue Mode**: Produce exactly 3–5 approaches, each a **different category** from the failed approach.
+
+Each approach must be meaningfully different — not just variations of the same idea. For each approach provide:
+- **Name**: short memorable label
+- **Description**: 2–4 sentences on how it works
+- **Pros**: concrete advantages (not generic "simple" — be specific)
+- **Cons**: concrete disadvantages and failure modes
+- **Effort**: low (< 1 day) | medium (1–3 days) | high (> 3 days)
+- **Risk**: low | medium | high + one-line explanation of the main risk
+
+If the domain is unfamiliar or data is needed, invoke `rune:research` before generating options. For product/market context, invoke `rune:trend-scout`.
+
+### Step 3 — Evaluate
+
+**Discovery Mode** — Apply the most relevant framework:
+- Use **SCAMPER** when exploring variations of an existing solution
+- Use **First Principles** when the problem looks unsolvable with conventional approaches
+- Use **6 Thinking Hats** when stakeholder perspectives matter (product vs. engineering vs. user)
+- Use **Crazy 8s** (rapid listing) when time-boxed exploration is needed
+- Use **Collision-Zone** when innovation is needed, not just optimization — force cross-domain metaphors
+- Use **Inversion** when all options feel forced or there's an unquestioned "must be this way"
+- Use **Scale Game** when validating which approach survives production reality
+
+**Rescue Mode** — MUST use at least one of these (conventional thinking already failed):
+- **Collision-Zone Thinking** (mandatory first pick) — force cross-domain metaphors to break out of the failed category
+- **Inversion Exercise** — flip assumptions that led to the failed approach
+- **First Principles** — strip to fundamentals, rebuild without the assumption that caused failure
+
+Additionally in Rescue Mode:
+- Invoke `rune:research` to search for how others solved similar problems (repos, articles, workarounds)
+- At least 1 approach must be "hacky/unconventional" — wrappers, reverse engineering, browser automation, proxy layers, debug mode abuse, etc.
+- Label each approach with its **category tag** to prove diversity: `[Direct API]`, `[Wrapper]`, `[Reverse-Engineer]`, `[Proxy]`, `[Extension]`, `[Alternative Tool]`, etc.
+
+For approaches with many interacting variables, invoke `rune:sequential-thinking` to reason through trade-offs systematically.
+
+### Step 4 — Recommend
+Select ONE approach as the recommendation. State:
+- Which option is recommended
+- Primary reason (1 sentence)
+- Conditions under which a different option would be better (hedge case)
+
+Do not recommend "it depends" without a concrete decision rule.
+
+### Step 5 — Return to Plan
+Pass the recommended approach back to `rune:plan` for structuring into an executable implementation plan. Include:
+- The chosen option name
+- Key constraints to honor in the plan
+- Any risks identified that the plan must mitigate
+
+If the user rejects the recommendation, return to Step 2 with adjusted constraints and regenerate.
+
+## Constraints
+
+1. MUST propose 2-3 approaches (Discovery) or 3-5 approaches (Rescue) — never present only one option
+2. MUST include your recommendation and reasoning for why
+3. MUST ask one question at a time — don't overwhelm with multiple questions
+4. MUST save approved design to docs/plans/ before transitioning to plan
+5. MUST NOT jump to implementation — brainstorm → plan → implement is the order
+6. [Rescue Mode] MUST NOT generate variants of the failed approach — each approach must be a different CATEGORY
+7. [Rescue Mode] MUST use Collision-Zone or Inversion framework — conventional thinking already failed
+8. [Rescue Mode] MUST include at least 1 unconventional/hacky approach — sometimes the "dirty" solution is the only one that works
+
+## Output Format
+
+```
+## Brainstorm: [Topic]
+
+### Context
+[Problem statement and constraints]
+
+### Option A: [Name] (Recommended)
+- **Approach**: [description]
+- **Pros**: [advantages]
+- **Cons**: [disadvantages]
+- **Effort**: low | medium | high
+- **Risk**: low | medium | high — [main risk]
+
+### Option B: [Name]
+- **Approach**: [description]
+- **Pros**: [advantages]
+- **Cons**: [disadvantages]
+- **Effort**: low | medium | high
+- **Risk**: low | medium | high — [main risk]
+
+### Option C: [Name] (if needed)
+...
+
+### Recommendation
+Option A — [one-line primary reason].
+Choose Option B if [specific hedge condition].
+
+### Next Step
+Proceeding to rune:plan with Option A. Constraints to honor: [list].
+```
+
+## Sharp Edges
+
+Known failure modes for this skill. Check these before declaring done.
+
+| Failure Mode | Severity | Mitigation |
+|---|---|---|
+| Generating only one option instead of 2-3 | HIGH | Always present multiple approaches — the value is in the comparison, not the recommendation |
+| Proceeding to plan without user approval on the approach | CRITICAL | Brainstorm MUST get explicit sign-off before calling plan — no silent "going with Option A" |
+| Options are variations of the same approach (fake diversity) | HIGH | Options must differ in architecture, not just naming — different trade-offs, not just different words |
+| [Rescue] Generating variants of the failed approach | CRITICAL | Each approach MUST have a different category tag — if two share a tag, one must be replaced |
+| [Rescue] Skipping Collision-Zone/Inversion frameworks | HIGH | Conventional thinking already failed — MUST use at least one breakthrough framework |
+| [Rescue] All approaches are "clean/proper" — no hacky option | MEDIUM | At least 1 must be unconventional — wrappers, reverse-engineering, debug mode abuse, proxy layers |
+| Calling plan directly instead of presenting options first | CRITICAL | Steps 2-3 are mandatory — present options, get approval, THEN call plan |
+| "Creative" options that ignore stated constraints | MEDIUM | Every option must satisfy the constraints declared in Step 1 |
+
+## Done When
+
+- Context scan complete (project files read, existing patterns identified)
+- 2-3 genuinely different approaches presented with trade-offs
+- User has explicitly approved an approach (not implied or assumed)
+- Selected option documented with rationale
+- Constraints for plan phase listed explicitly
+- `plan` (L2) called with the approved approach and constraints
+
+## Cost Profile
+
+~2000-5000 tokens input, ~1000-2500 tokens output. Opus for creative reasoning depth. Runs infrequently — only when creative exploration is needed.