@kudusov.takhir/ba-toolkit 1.2.0

package/skills/scenarios/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: ba-scenarios
+description: >
+  Generate end-to-end validation scenarios linking user stories, acceptance criteria, API endpoints, and wireframes into complete user journeys for acceptance testing. Use on /scenarios command, or when the user asks for "validation scenarios", "end-to-end scenarios", "user journeys", "acceptance test scenarios", "E2E scenarios", "test cases", "walkthrough scenarios", "happy path scenarios", "test the product", "QA scenarios". Optional step — run after /wireframes.
+---
+
+# /scenarios — Validation Scenarios
+
+Optional step after `/wireframes`. Generates end-to-end user journeys that can be used for acceptance testing, UX walkthroughs, and stakeholder demos. Each scenario traces a complete user path from entry point to outcome, linking US, AC, API endpoints, and wireframes.
+
+Scenarios are not unit or integration tests — they describe observable behavior from the user's perspective.
+
+## Context loading
+
+0. If `00_principles_*.md` exists in the output directory, load it and apply its conventions.
+1. Read `01_brief_*.md`, `03_stories_*.md`, `05_ac_*.md`, `09_wireframes_*.md`. Stories and AC are required; wireframes strongly recommended.
+2. If `08_apicontract_*.md` exists, use it to link API calls within steps.
+3. Extract: slug, domain, roles, Must-priority US list, AC per US, WF per US, API endpoints.
+
+## Environment
+
+Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory. If unavailable, apply the default rule.
+
+## Interview
+
+1 round, 3–5 questions.
+
+**Required topics:**
+1. Coverage priority — generate scenarios for Must-priority US only, or include Should as well?
+2. Negative paths — include error and edge-case journeys alongside happy paths?
+3. Persona depth — use generic role names (e.g., "Player") or named personas with context (e.g., "Andrei, a new player from Germany")?
+4. Platform — which platform does the primary scenario run on (web / mobile / Telegram Mini App)?
+5. Demo focus — are any scenarios intended for a stakeholder demo? If so, which flows should be highlighted?
+
+## Generation
+
+**File:** `10_scenarios_{slug}.md`
+
+```markdown
+# Validation Scenarios: {Project Name}
+
+**Date:** {date}
+**Coverage:** {Must / Must + Should} priority user stories
+**Platform:** {web | mobile | Telegram Mini App | all}
+
+---
+
+## SC-{NNN}: {Scenario Title}
+
+**Persona:** {Role or named persona with brief context}
+**Entry point:** {Where the journey starts — screen, URL, or trigger}
+**Goal:** {What the user is trying to achieve}
+**Linked US:** US-{NNN}, US-{NNN}
+**Type:** {happy path | negative | edge case}
+
+### Steps
+
+| # | User action | System response | Screen (WF) | API call | AC verified |
+|---|-------------|-----------------|-------------|----------|-------------|
+| 1 | {what the user does} | {what the system shows/does} | WF-{NNN} | {METHOD /path} | AC-{NNN}-{NN} |
+| 2 | … | … | … | … | … |
+
+### Expected outcome
+{Specific, observable result — what the user sees or receives at the end of the scenario.}
+
+### Failure conditions
+{Conditions under which this scenario fails and what the user should see instead.}
+
+---
+
+_(Repeat SC block for each scenario.)_
+
+## Coverage Summary
+
+| US | Scenario(s) | Happy path | Negative path |
+|----|-------------|------------|---------------|
+| US-001 | SC-001, SC-002 | ✓ | ✓ |
+| US-002 | SC-003 | ✓ | — |
+```
+
+**Rules:**
+- Numbering: SC-001, SC-002, ...
+- Every Must-priority US must have at least one happy-path scenario.
+- Each step must reference a WF screen if wireframes were generated.
+- Each step must reference the AC it verifies (if applicable).
+- API calls reference endpoints from `08_apicontract_{slug}.md` using the exact method and path.
+- Failure conditions are mandatory for each scenario.
+
+## Iterative refinement
+
+- `/revise [SC-NNN]` — rewrite a scenario.
+- `/expand [SC-NNN]` — add more steps or paths.
+- `/split [SC-NNN]` — separate a long scenario into focused ones.
+- `/clarify [focus]` — targeted ambiguity pass.
+- `/validate` — all Must-US covered; AC links correct; WF references exist; API paths match contract.
+- `/done` — finalize.
+
+## Closing message
+
+After saving the artifact, present the following summary (see `references/closing-message.md` for format):
+
+- Saved file path.
+- Total number of scenarios generated, broken down by type (happy path / negative / edge case).
+- Count of Must-priority US covered.
+- Any Must-priority US without a scenario.
+
+Available commands: `/clarify [focus]` · `/revise [SC-NNN]` · `/expand [SC-NNN]` · `/split [SC-NNN]` · `/validate` · `/done`
+
+Pipeline complete. Proceed to `/handoff` to package all artifacts for development.
+
+## Style
+
+Formal, neutral. No emoji, slang. Generate in the artifact language. Persona names, screen labels, and API paths remain in their original language/format.

package/skills/sprint/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: ba-sprint
+description: >
+  Sprint planning for BA Toolkit projects. Use on /sprint command, or when the user asks to "create a sprint plan", "plan sprints", "organise backlog into sprints", "sprint breakdown", "velocity planning", "release plan". Run after /estimate (required) and /risk (recommended). Generates 00_sprint_{slug}.md with sprint goals, story assignments, and capacity summary.
+---
+
+# /sprint — Sprint Plan
+
+Utility command. Reads estimated User Stories, applies team capacity and velocity constraints, groups stories into sprints by priority and risk weight, and produces `00_sprint_{slug}.md` with a complete sprint breakdown.
+
+## Syntax
+
+```
+/sprint [optional: action]
+```
+
+Examples:
+- `/sprint` — generate a full sprint plan using defaults or a calibration interview
+- `/sprint 2` — re-plan sprint 2 only (e.g., after stories were added or re-estimated)
+- `/sprint velocity 40` — override team velocity to 40 SP per sprint
+- `/sprint add SP-01 US-007` — move a story to a specific sprint manually
+
+## Context loading
+
+0. If `00_principles_*.md` exists, load it — apply language convention (section 1) and ID naming convention (section 2).
+1. Load `00_estimate_{slug}.md` or check `03_stories_{slug}.md` for inline `**Estimate:**` fields. **Required** — sprint planning cannot proceed without estimates.
+2. Load `03_stories_{slug}.md` — source of story priority (MoSCoW or custom), epic grouping, and acceptance criteria count.
+3. Load `00_risks_{slug}.md` if it exists — use risk scores to elevate priority of stories that mitigate 🔴 Critical or 🟡 High risks.
+4. Load `02_srs_{slug}.md` — to extract any sequencing constraints (dependencies, technical prerequisites).
+5. Load `00_sprint_{slug}.md` if it exists — merge mode: preserve confirmed sprints, re-plan only future ones.
+
+## Environment
+
+Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory.
+
+## Calibration interview
+
+Ask the following before planning (skip questions already answered in context or via syntax flags):
+
+1. **Sprint length:** How many weeks per sprint? _(default: 2 weeks)_
+2. **Team velocity:** Estimated Story Points per sprint (or T-shirt / person-days equivalent)? _(if not given, estimate from story count: assume 30–40 SP for a 3–5 developer team)_
+3. **Team size:** Number of developers contributing to this project? _(used to sanity-check velocity)_
+4. **Sprint 0:** Does the team need a sprint 0 for setup, architecture, or environment? _(yes/no — if yes, add SP-00 with no user stories)_
+5. **Hard deadline:** Is there a fixed release date or milestone? _(if yes, flag stories that will not fit before the deadline)_
+6. **Parallel tracks:** Are frontend and backend worked on simultaneously, or sequentially? _(affects story ordering within a sprint)_
+
+If the user types `/sprint` without additional input and prior context is sufficient, apply defaults and state assumptions explicitly in the output.
+
+## Planning algorithm
+
+### Step 1 — Priority ordering
+
+Sort stories for assignment using this precedence:
+
+1. **Must** stories first (MoSCoW: Must > Should > Could > Won't).
+2. Within the same priority tier, elevate stories that mitigate 🔴 Critical or 🟡 High risks (from `00_risks_{slug}.md`).
+3. Within the same priority and risk tier, order by dependencies: stories that are prerequisite to others go first.
+4. Within the same tier with no dependencies, order by estimate ascending (smaller stories first — reduces WIP).
+
+### Step 2 — Sprint assignment
+
+Fill sprints greedily from the ordered list:
+
+- Assign stories to the current sprint until adding the next story would exceed velocity.
+- If a story alone exceeds velocity, flag it for splitting: `⚠️ US-NNN (N SP) exceeds sprint capacity — consider /split US-NNN`.
+- If a story has an explicit prerequisite not yet assigned, defer it to the sprint after its prerequisite completes.
+- When a hard deadline is provided, mark the sprint that contains it and flag any Must stories not scheduled before it as 🚨 **At risk**.
+
+### Step 3 — Sprint goal derivation
+
+For each sprint, derive a one-sentence goal that describes the primary user-facing outcome:
+- Group stories by epic and pick the dominant epic in the sprint.
+- Express the goal as a user outcome, not a task list: "Players can register, deposit, and spin for the first time."
+
+## Generation
+
+Save `00_sprint_{slug}.md` to the output directory.
+
+```markdown
+# Sprint Plan: {PROJECT_NAME}
+
+**Domain:** {DOMAIN}
+**Date:** {DATE}
+**Slug:** {SLUG}
+**Sprint length:** {N} weeks
+**Team velocity:** {N} SP per sprint
+**Sources:** {list of artifacts used}
+
+---
+
+## Summary
+
+| Sprint | Goal | Stories | Points | Capacity |
+|--------|------|:-------:|:------:|:--------:|
+| SP-00  | Setup and environment | — | — | — |
+| SP-01  | [Goal] | N | N SP | N% |
+| SP-02  | [Goal] | N | N SP | N% |
+| **Total** | | **N** | **N SP** | |
+
+**Planned:** N stories / N SP across N sprints
+**Unplanned backlog:** N stories / N SP (scope exceeds capacity or marked Won't)
+
+---
+
+## Sprint Details
+
+### SP-01 — [Sprint Goal]
+
+**Duration:** Week 1–2
+**Capacity:** {N} SP
+
+| US | Title | Epic | Priority | Risk | Estimate |
+|----|-------|------|---------|------|---------|
+| US-001 | [Title] | E-01 | Must | RISK-02 ↑ | 5 SP |
+| US-002 | [Title] | E-01 | Must | — | 3 SP |
+| US-005 | [Title] | E-02 | Should | — | 8 SP |
+
+**Sprint total:** N SP / {velocity} SP capacity (N%)
+
+**Definition of Done for this sprint:**
+- [ ] All stories pass their Acceptance Criteria.
+- [ ] API endpoints for this sprint are integrated and tested.
+- [ ] No 🔴 Critical open items in `/analyze` for completed stories.
+
+---
+
+### SP-02 — [Sprint Goal]
+
+...
+
+---
+
+## Unplanned Backlog
+
+Stories not assigned to any sprint (capacity exceeded, low priority, or deferred):
+
+| US | Title | Epic | Priority | Estimate | Reason |
+|----|-------|------|---------|---------|--------|
+| US-018 | [Title] | E-04 | Could | 3 SP | Capacity exceeded |
+| US-022 | [Title] | E-05 | Won't | 8 SP | Out of MVP scope |
+
+---
+
+## Assumptions
+
+- Sprint velocity: {N} SP based on {source: user input / estimate from team size}.
+- {Any other assumption made during planning.}
+```
+
+Sprint IDs are sequential (SP-00, SP-01, SP-02, …). SP-00 is reserved for setup/architecture sprint if requested.
+
+### Merge behaviour
+
+If `00_sprint_{slug}.md` already exists:
+- Preserve sprints marked as **Done** or **In Progress** — do not re-plan them.
+- Re-plan only **Planned** sprints that are in the future.
+- Assign new IDs only to newly created sprints (do not renumber existing ones).
+- Update Summary table and Assumptions.
+
+## Closing message
+
+After saving, present the following summary (see `references/closing-message.md` for format):
+
+- Saved file: `00_sprint_{slug}.md`
+- Number of sprints planned and total duration in weeks.
+- Total stories and Story Points planned vs. unplanned backlog size.
+- Any stories flagged 🚨 At risk (won't fit before the hard deadline).
+- Any stories that exceed sprint capacity and need splitting (`/split`).
+
+Available commands: `/sprint [SP-NN]` (re-plan a sprint) · `/split [US-NNN]` (split large story) · `/estimate` (re-estimate) · `/risk` (refresh risks) · `/done`
+
+## Style
+
+Be specific about sprint goals — one user-outcome sentence per sprint. Show capacity percentages to make overloading visible at a glance. Flag risks and deadline conflicts explicitly, do not bury them in footnotes. Generate output in the language of the artifact.

package/skills/srs/SKILL.md

@@ -0,0 +1,124 @@
+---
+name: ba-srs
+description: >
+  Generate a Software Requirements Specification (SRS) based on the Project Brief. Adapted IEEE 830 format. Use on /srs command, or when the user asks for "requirements specification", "SRS", "functional requirements", "system requirements", "describe requirements", "write a technical specification". Second step of the BA Toolkit pipeline.
+---
+
+# /srs — Requirements Specification
+
+Second step of the BA Toolkit pipeline. Generates an SRS adapted from IEEE 830.
+
+**Scope boundary:** The SRS describes *what* the system must do and *why* — functional requirements, roles, business rules, and interface contracts at a logical level. It does not prescribe *how* to build it: technology stack, DBMS choice, cloud provider, infrastructure, and architecture decisions belong in `/research` (step 7a). If the user mentions specific technologies during the interview, note them as constraints or assumptions, not as requirements.
+
+## Context loading
+
+0. If `00_principles_*.md` exists in the output directory, load it and apply its conventions (artifact language, ID format, traceability requirements, Definition of Ready, quality gate threshold).
+1. Read `01_brief_*.md` from the output directory. If missing, warn and suggest running `/brief`.
+2. Extract: slug, domain, business goals, functionality, stakeholders, constraints, glossary.
+3. If domain is `igaming`, `fintech`, or `saas`, load `references/domains/{domain}.md`, section `2. /srs`.
+
+## Environment
+
+Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory for the current platform. If the file is unavailable, apply the default rule: if `/mnt/user-data/outputs/` exists and is writable, save there (Claude.ai); otherwise save to the current working directory.
+
+## Interview
+
+3–7 questions per round, 2–4 rounds. Do not re-ask information already known from the brief.
+
+**Required topics:**
+1. User roles — which roles interact with the system?
+2. External integrations — which systems require connection?
+3. Multi-language and multi-currency support — if applicable.
+4. Regulatory requirements — which standards and laws apply?
+5. Prioritization method — MoSCoW (Must, Should, Could, Won't) or other.
+6. Key business rules — limits, thresholds, calculation formulas.
+
+Supplement with domain-specific questions and typical functional areas from the reference.
+
+## Generation
+
+**File:** `02_srs_{slug}.md`
+
+```markdown
+# Software Requirements Specification (SRS): {Name}
+
+## 1. Introduction
+### 1.1 Purpose
+### 1.2 Scope
+### 1.3 Definitions and Abbreviations
+### 1.4 Document References
+
+## 2. General Description
+### 2.1 Product Context
+### 2.2 User Roles
+### 2.3 Constraints
+### 2.4 Assumptions and Dependencies
+
+## 3. Functional Requirements
+### FR-{NNN}: {Title}
+- **Description:** ...
+- **Actor:** ...
+- **Input:** ...
+- **Output / Result:** ...
+- **Business Rules:** ...
+- **Priority:** Must | Should | Could | Won't
+
+## 4. Interface Requirements
+### 4.1 User Interfaces
+### 4.2 Software Interfaces (API)
+### 4.3 External System Interfaces
+
+## 5. Non-functional Requirements
+_(detailed in /nfr artifact)_
+
+## 6. Priority Matrix (MoSCoW)
+```
+
+FR numbering: sequential, three-digit (FR-001, FR-002, ...).
+
+## AGENTS.md update
+
+After `/done`, update `AGENTS.md` in the project root with SRS-level context:
+
+```markdown
+## Artifacts
+...
+- `{output_dir}/02_srs_{slug}.md` — SRS ({n} FR, MoSCoW breakdown)
+
+## Key context
+...
+- **User roles:** {comma-separated list}
+- **External integrations:** {comma-separated list}
+- **Must-priority FR count:** {n}
+
+## Next step
+Run `/stories` to generate User Stories.
+```
+
+Only update the "Pipeline stage", "Artifacts", and "Key context" sections. Preserve any custom content.
+
+## Iterative refinement
+
+- `/revise [section]` — rewrite.
+- `/expand [section]` — add detail.
+- `/split [FR-NNN]` — split a large requirement.
+- `/clarify [focus]` — targeted ambiguity pass.
+- `/validate` — all brief functions covered by FR; no duplicates; roles consistent.
+- `/done` — finalize and update `AGENTS.md`. Next step: `/stories`.
+
+## Closing message
+
+After saving the artifact, present the following summary to the user (see `references/closing-message.md` for format):
+
+- Saved file path.
+- Total number of functional requirements (FR) generated, broken down by MoSCoW priority.
+- User roles identified.
+- External integrations and regulatory requirements captured.
+
+Available commands: `/clarify [focus]` · `/revise [section]` · `/expand [section]` · `/split [FR-NNN]` · `/validate` · `/done`
+
+Next step: `/stories`
+
+## Style
+
+Formal, neutral. No emoji, slang. Terms explained in parentheses on first use. Generate the artifact in the language of the user's request.

package/skills/stories/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: ba-stories
+description: >
+  Generate User Stories based on the SRS. Format: "As a [role], I want [action], so that [value]". Use on /stories command, or when the user asks for "user stories", "create stories", "write user stories", "story decomposition", "epics and stories", "backlog", "break requirements into stories". Third step of the BA Toolkit pipeline.
+---
+
+# /stories — User Stories
+
+Third step of the BA Toolkit pipeline. Generates User Stories from functional requirements in the SRS.
+
+## Context loading
+
+0. If `00_principles_*.md` exists in the output directory, load it and apply its conventions (artifact language, ID format, traceability requirements, Definition of Ready, quality gate threshold).
+1. Read `01_brief_*.md` and `02_srs_*.md`. If SRS is missing, warn and suggest `/srs`.
+2. Extract: slug, domain, roles, FR list, business rules, priorities.
+3. If domain is supported, load `references/domains/{domain}.md`, section `3. /stories`.
+
+## Environment
+
+Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory for the current platform. If the file is unavailable, apply the default rule: if `/mnt/user-data/outputs/` exists and is writable, save there (Claude.ai); otherwise save to the current working directory.
+
+## Interview
+
+3–7 questions per round, 2–4 rounds.
+
+**Required topics:**
+1. Which user flows are most critical?
+2. Are there edge cases requiring separate stories?
+3. Is an Epic → Feature → Story hierarchy needed?
+4. Are there specific personas for roles?
+5. What is the Definition of Ready for a story?
+
+Supplement with domain-specific questions and typical epics from the reference.
+
+## Generation
+
+**File:** `03_stories_{slug}.md`
+
+```markdown
+# User Stories: {Name}
+
+## Epic: {Epic Name}
+Brief description and business value.
+
+### US-{NNN}: {Short Description}
+- **Role:** {role from SRS}
+- **Action:** {what they want to do}
+- **Value:** {why, business outcome}
+- **Priority:** {Must | Should | Could | Won't}
+- **Linked FR:** FR-{NNN}
+- **Acceptance Criteria:** _(filled at /ac stage)_
+- **Notes:** {edge cases, additional context}
+```
+
+**Rules:**
+- Sequential numbering: US-001, US-002, ...
+- One story = one atomic action by one role.
+- All Must-priority FR from SRS must have at least one US.
+- Story covering > 3 scenarios — suggest `/split`.
+
+## Iterative refinement
+
+- `/revise [US-NNN or section]` — rewrite.
+- `/expand [US-NNN]` — add detail.
+- `/split [US-NNN]` — split into smaller stories.
+- `/clarify [focus]` — targeted ambiguity pass.
+- `/validate` — all FR covered; no orphan stories; numbering correct; roles consistent.
+- `/done` — finalize. Next step: `/usecases`.
+
+## Closing message
+
+After saving the artifact, present the following summary to the user (see `references/closing-message.md` for format):
+
+- Saved file path.
+- Total number of user stories generated, grouped by Epic and MoSCoW priority.
+- Count of Must-priority FR covered.
+- Any stories flagged for `/split` due to complexity.
+
+Available commands: `/clarify [focus]` · `/revise [US-NNN]` · `/expand [US-NNN]` · `/split [US-NNN]` · `/validate` · `/done`
+
+Next step: `/usecases`
+
+## Style
+
+Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request.

package/skills/trace/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: ba-trace
+description: >
+  Build and update the traceability matrix across all BA Toolkit pipeline artifacts: FR ↔ US ↔ UC ↔ AC ↔ NFR ↔ Data Entity ↔ API Endpoint ↔ Wireframe. Use on /trace command, or when the user asks for "traceability matrix", "requirements traceability", "coverage check", "uncovered requirements", "artifact links", "check coverage", "find missing requirements", "what is not covered". Cross-cutting command available at any stage after /stories.
+---
+
+# /trace — Traceability Matrix
+
+Cross-cutting command of the BA Toolkit pipeline. Available after `/stories` is complete. Builds a traceability matrix across all existing artifacts.
+
+## Context loading
+
+0. If `00_principles_*.md` exists in the output directory, load it. Use its traceability requirements (section 3) to determine which links are CRITICAL, HIGH, or MEDIUM severity when flagging gaps.
+1. Read all pipeline artifacts from the output directory. Minimum required: `02_srs_*.md` and `03_stories_*.md`.
+2. Determine which artifacts are available and adapt matrix columns accordingly.
+3. Domain reference not needed for this skill — all information comes from the artifacts.
+
+## Environment
+
+Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory for the current platform. If the file is unavailable, apply the default rule: if `/mnt/user-data/outputs/` exists and is writable, save there (Claude.ai); otherwise save to the current working directory.
+
+## Generation
+
+No interview needed. Information is extracted from existing artifacts automatically.
+
+**File:** `00_trace_{slug}.md`
+
+```markdown
+# Traceability Matrix: {Name}
+
+**Date:** {date}
+**Artifacts:** {list of found pipeline files}
+
+## Matrix
+
+| FR | US | UC | AC | NFR | Data Entity | API Endpoint | Wireframe |
+|----|----|----|----|----|-------------|-------------|-----------|
+| FR-001 | US-001, US-002 | UC-001 | AC-001-01 | NFR-003 | User, Bet | POST /bets | WF-005 |
+
+## Coverage Statistics
+
+| Artifact | Total | Covered | Uncovered | Coverage % |
+|----------|-------|---------|-----------|------------|
+
+## Uncovered Elements
+
+### FR without linked US
+### US without linked UC
+### US without AC
+### FR without NFR coverage
+### Data entities without FR/US link
+### API endpoints without FR/US link
+### Wireframes without US link
+
+## Recommendations
+Specific actions to close coverage gaps.
+```
+
+**Rules:**
+- Columns include only artifact types that have been created. Missing columns marked with `—`.
+- Links extracted from "Linked FR/US" fields in each artifact.
+- Inconsistency (link present in one artifact but missing in another) is flagged.
+- Coverage: an element is covered if it has at least one link in the next matrix column.
+
+## Iterative refinement
+
+- `/revise` — regenerate (re-read all artifacts).
+- `/validate` — extended check: nonexistent IDs, circular dependencies, duplicate links.
+
+## Closing message
+
+After saving the artifact, present the following summary to the user (see `references/closing-message.md` for format):
+
+- Saved file path.
+- Overall coverage percentage per artifact type.
+- Count of uncovered FRs, orphan US, and US without AC.
+- Specific recommendations to close the highest-severity gaps.
+
+Available commands: `/revise` (regenerate) · `/validate` · `/analyze` (full quality report)
+
+No further pipeline step — use `/analyze` for a detailed cross-artifact quality report.
+
+## Style
+
+Formal, neutral. No emoji, slang. Generate the artifact in the language of the user's request.

package/skills/usecases/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: ba-usecases
+description: >
+  Generate Use Cases (Cockburn format) based on User Stories. Use on /usecases command, or when the user asks for "use cases", "scenarios", "describe scenarios", "interaction flows", "main and alternative flows", "describe system behavior", "user interaction scenario". Fourth step of the BA Toolkit pipeline.
+---
+
+# /usecases — Use Cases
+
+Fourth step of the BA Toolkit pipeline. Generates Use Cases in simplified Cockburn format.
+
+## Context loading
+
+0. If `00_principles_*.md` exists in the output directory, load it and apply its conventions (artifact language, ID format, traceability requirements, Definition of Ready, quality gate threshold).
+1. Read `01_brief_*.md`, `02_srs_*.md`, `03_stories_*.md`. If stories missing, warn and suggest `/stories`.
+2. Extract: slug, domain, roles (actors), US list, FR list, business rules.
+3. If domain supported, load `references/domains/{domain}.md`, section `4. /usecases`.
+
+## Environment
+
+Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory for the current platform. If the file is unavailable, apply the default rule: if `/mnt/user-data/outputs/` exists and is writable, save there (Claude.ai); otherwise save to the current working directory.
+
+## Interview
+
+3–7 questions per round, 2–4 rounds.
+
+**Required topics:**
+1. Detail level — summary, user-goal, subfunction?
+2. Which alternative flows are most critical?
+3. Which exceptional flows (errors) must be formalized?
+4. Which external systems act as actors?
+5. Grouping — which US should be combined into a single UC?
+
+Supplement with domain-specific questions and typical exceptional flows from the reference.
+
+## Generation
+
+**File:** `04_usecases_{slug}.md`
+
+```markdown
+# Use Cases: {Name}
+
+## UC-{NNN}: {Title}
+- **Actor:** {primary actor}
+- **Level:** {user-goal | summary | subfunction}
+- **Linked US:** US-{NNN}
+- **Preconditions:**
+  1. {condition}
+- **Trigger:** {event}
+- **Main Flow:**
+  1. {Actor performs action.}
+  2. {System responds.}
+- **Alternative Flows:**
+  - {N}a: {description}
+- **Exceptional Flows:**
+  - {N}e: {description}
+- **Postconditions:**
+  - Success: {result}
+  - Failure: {result}
+```
+
+**Rules:**
+- Numbering: UC-001, UC-002, ...
+- Each UC linked to at least one US.
+- Steps: "Actor does X" / "System does Y".
+- Alternative flows reference main flow step numbers.
+
+## Iterative refinement
+
+- `/revise [UC-NNN]` — rewrite.
+- `/expand [UC-NNN]` — add flows.
+- `/split [UC-NNN]` — split.
+- `/clarify [focus]` — targeted ambiguity pass.
+- `/validate` — all Must-US covered; references correct; actors consistent.
+- `/done` — finalize. Next step: `/ac`.
+
+## Closing message
+
+After saving the artifact, present the following summary to the user (see `references/closing-message.md` for format):
+
+- Saved file path.
+- Total number of use cases generated.
+- Count of alternative and exceptional flows documented.
+- External system actors identified.
+
+Available commands: `/clarify [focus]` · `/revise [UC-NNN]` · `/expand [UC-NNN]` · `/split [UC-NNN]` · `/validate` · `/done`
+
+Next step: `/ac`
+
+## Style
+
+Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request.