@kudusov.takhir/ba-toolkit 4.0.4 → 4.1.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -11,6 +11,29 @@ Versions follow [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
11
11
 
12
12
  ---
13
13
 
14
+ ## [4.1.1] — 2026-04-12
15
+
16
+ ### Fixed
17
+
18
+ - **Systematic mixed-language output in non-English artifacts** — when users wrote in a non-English language, artifacts got English section headings, table headers, field labels ("**Priority:**", "**Description:**", etc.), and closing summaries ("Artifact saved:", "Next step:", etc.) while body text was in the user's language. Root cause: templates and reference files are English-only (correct per convention), but only 9 of 29 skills had an explicit rule to translate structural elements. Created `skills/references/language-rule.md` — a single shared reference defining exactly what to translate (headings, labels, table headers, closing message text, interview acknowledgments) and what stays in English (element IDs, file paths, slash commands, MoSCoW values, INVEST criteria). All 29 SKILL.md files now reference this file from their Style section. Updated `closing-message.md` with explicit translation guidance for all template labels. Updated `interview-protocol.md` rule 5 to specify acknowledgments are in the user's language. Removed per-template HTML language comments from `stories-template.md` and `ac-template.md` (now covered by the shared rule).
19
+
20
+ ---
21
+
22
+ ## [4.1.0] — 2026-04-12
23
+
24
+ ### Added
25
+
26
+ - **5 new refinement skills promoted from inline subcommands to standalone utility skills.** `/validate`, `/revise`, `/expand`, `/split`, and `/done` now have their own `skills/{name}/SKILL.md` files and work as first-class skills in every supported agent. Previously these were documented as "subcommands" but had no SKILL.md — typing them triggered "Unknown skill" errors. Each skill follows the established `/clarify` pattern: YAML frontmatter with trigger phrases, context loading, environment detection, slug source, and closing message format.
27
+ - **`/validate`** — single-artifact completeness and consistency check: mandatory fields, ID format, cross-references, MoSCoW count verification, Definition of Ready compliance. Reports findings by severity; offers auto-fix.
28
+ - **`/revise [section]`** — rewrites a specific section based on user feedback or an `/analyze` finding ID (e.g., `/revise A1`). Includes ripple-effect check across downstream artifacts.
29
+ - **`/expand [section]`** — adds depth and detail to an under-developed section using domain knowledge and prior artifacts. Preserves existing content.
30
+ - **`/split [element]`** — decomposes an oversized FR, User Story, or Use Case into smaller pieces using INVEST criteria and Mike Cohn's nine story-splitting patterns. Updates cross-references.
31
+ - **`/done`** — finalizes the current artifact (Version 1.0, Status: Approved), runs a quality gate check (blocks on CRITICAL findings), updates `AGENTS.md` pipeline status, and presents the next pipeline step.
32
+ - **Skill count increased from 24 to 29** across all documentation, package metadata, and test assertions.
33
+ - **"Subcommands" terminology retired** — all references to "subcommands" in documentation updated to "refinement skills". The `## Subcommands` section in COMMANDS.md and README.md replaced with `## Refinement skills` with full skill descriptions.
34
+
35
+ ---
36
+
14
37
  ## [4.0.4] — 2026-04-12
15
38
 
16
39
  ### Fixed
@@ -907,7 +930,9 @@ CI scripts that relied on the old behaviour (`init` creates files only, `install
907
930
 
908
931
  ---
909
932
 
910
- [Unreleased]: https://github.com/TakhirKudusov/ba-toolkit/compare/v4.0.4...HEAD
933
+ [Unreleased]: https://github.com/TakhirKudusov/ba-toolkit/compare/v4.1.1...HEAD
934
+ [4.1.1]: https://github.com/TakhirKudusov/ba-toolkit/compare/v4.1.0...v4.1.1
935
+ [4.1.0]: https://github.com/TakhirKudusov/ba-toolkit/compare/v4.0.4...v4.1.0
911
936
  [4.0.4]: https://github.com/TakhirKudusov/ba-toolkit/compare/v4.0.3...v4.0.4
912
937
  [4.0.3]: https://github.com/TakhirKudusov/ba-toolkit/compare/v4.0.2...v4.0.3
913
938
  [4.0.2]: https://github.com/TakhirKudusov/ba-toolkit/compare/v4.0.1...v4.0.2
package/COMMANDS.md CHANGED
@@ -1,6 +1,6 @@
1
1
  # BA Toolkit — Command Reference
2
2
 
3
- Quick reference for all 24 skills and subcommands. For term and acronym definitions (FR, US, AC, IEEE 830, etc.), see the [glossary](docs/GLOSSARY.md).
3
+ Quick reference for all 29 skills. For term and acronym definitions (FR, US, AC, IEEE 830, etc.), see the [glossary](docs/GLOSSARY.md).
4
4
 
5
5
  ---
6
6
 
@@ -46,17 +46,17 @@ Available at any pipeline stage.
46
46
 
47
47
  ---
48
48
 
49
- ## Subcommands
49
+ ## Refinement skills
50
50
 
51
- Available within any active pipeline skill (after generation, before `/done`).
51
+ Available at any pipeline stage after the first artifact exists. These skills refine and validate artifacts without advancing the pipeline (except `/done`, which finalizes and moves on).
52
52
 
53
- | Subcommand | What it does |
54
- |------------|-------------|
55
- | `/revise [section]` | Rewrite a specific section with your feedback |
56
- | `/expand [section]` | Add more detail to a section |
57
- | `/split [element]` | Break a large element into smaller ones (e.g., split an oversized User Story) |
58
- | `/validate` | Check completeness, consistency, and alignment with prior artifacts |
59
- | `/done` | Finalise the current artifact and move to the next pipeline step |
53
+ | Command | Output file | What it generates |
54
+ |---------|-------------|-------------------|
55
+ | `/validate` | _(reports in chat)_ | Completeness and consistency check for a single artifact: mandatory fields, ID format, cross-references, MoSCoW counts, Definition of Ready |
56
+ | `/revise [section]` | _(updates existing artifact)_ | Section rewrite: applies user feedback or resolves an `/analyze` finding, with ripple-effect check across downstream artifacts |
57
+ | `/expand [section]` | _(updates existing artifact)_ | Section expansion: adds depth, detail, and missing elements to an under-developed section |
58
+ | `/split [element]` | _(updates existing artifact)_ | Element decomposition: breaks an oversized FR, User Story, or Use Case into smaller pieces using INVEST criteria and Cohn's splitting patterns |
59
+ | `/done` | _(updates AGENTS.md)_ | Finalize: quality gate check, artifact metadata update (Version 1.0, Status: Approved), AGENTS.md pipeline advancement |
60
60
 
61
61
  ---
62
62
 
package/README.md CHANGED
@@ -22,7 +22,7 @@ Turn a rough project idea into a complete, structured specification — then han
22
22
 
23
23
  ## What is this
24
24
 
25
- BA Toolkit turns a rough project idea into a complete, structured specification — requirements, user stories, acceptance criteria, API contracts, wireframes, and a step-by-step implementation plan. It runs as **24 AI-powered skills** inside your coding agent (Claude Code, Cursor, Codex CLI, Gemini CLI, or Windsurf) and produces Markdown documents that are cross-referenced, traceable, and ready for development or stakeholder review.
25
+ BA Toolkit turns a rough project idea into a complete, structured specification — requirements, user stories, acceptance criteria, API contracts, wireframes, and a step-by-step implementation plan. It runs as **29 AI-powered skills** inside your coding agent (Claude Code, Cursor, Codex CLI, Gemini CLI, or Windsurf) and produces Markdown documents that are cross-referenced, traceable, and ready for development or stakeholder review.
26
26
 
27
27
  **How it works:** you type a slash command (e.g., `/brief`), the agent asks you a series of focused questions about your project, and generates a structured document. Each step builds on the previous ones — requirements link to user stories, stories link to acceptance criteria, and so on through the entire chain. After the last step, you have a complete specification package that a developer or AI coding agent can execute.
28
28
 
@@ -119,11 +119,11 @@ Reload the CLI after copying.
119
119
 
120
120
  ### Cursor
121
121
 
122
- Cursor has two separate features — Rules (`.cursor/rules/*.mdc`) and [Agent Skills](https://cursor.com/docs/skills) (`.cursor/skills/<skill>/SKILL.md`). BA Toolkit is a set of skills, not rules, so `ba-toolkit install --for cursor` drops the 24 skills directly into `.cursor/skills/` using the native folder-per-skill `SKILL.md` format — no conversion needed. Reload the Cursor window to pick them up.
122
+ Cursor has two separate features — Rules (`.cursor/rules/*.mdc`) and [Agent Skills](https://cursor.com/docs/skills) (`.cursor/skills/<skill>/SKILL.md`). BA Toolkit is a set of skills, not rules, so `ba-toolkit install --for cursor` drops the 29 skills directly into `.cursor/skills/` using the native folder-per-skill `SKILL.md` format — no conversion needed. Reload the Cursor window to pick them up.
123
123
 
124
124
  ### Windsurf
125
125
 
126
- Windsurf's [Agent Skills](https://docs.windsurf.com/windsurf/cascade/skills) feature loads skills from `.windsurf/skills/<skill>/SKILL.md`, the same folder-per-skill layout as Claude Code and Cursor. `ba-toolkit install --for windsurf` writes the 24 skills there natively. Reload the Windsurf window to pick them up.
126
+ Windsurf's [Agent Skills](https://docs.windsurf.com/windsurf/cascade/skills) feature loads skills from `.windsurf/skills/<skill>/SKILL.md`, the same folder-per-skill layout as Claude Code and Cursor. `ba-toolkit install --for windsurf` writes the 29 skills there natively. Reload the Windsurf window to pick them up.
127
127
 
128
128
  ### Aider
129
129
 
@@ -318,11 +318,13 @@ Adding a new domain = creating one Markdown file in `skills/references/domains/`
318
318
 
319
319
  ## How it works
320
320
 
321
- Most pipeline skills follow the same cycle: **Command → Context → Interview → Generate → Refine**. Each skill loads all previous artifacts plus the domain reference and project principles, asks a few rounds of targeted questions, writes a Markdown artifact, and offers refinement subcommands before moving on. `/handoff`, `/trace`, and `/analyze` skip the interview — they extract everything from existing artifacts automatically.
321
+ Most pipeline skills follow the same cycle: **Command → Context → Interview → Generate → Refine**. Each skill loads all previous artifacts plus the domain reference and project principles, asks a few rounds of targeted questions, writes a Markdown artifact, and offers refinement skills before moving on. `/handoff`, `/trace`, and `/analyze` skip the interview — they extract everything from existing artifacts automatically.
322
322
 
323
323
  Every artifact links back to its predecessors, forming the chain `FR → US → UC → AC → NFR → Entity → ADR → API → WF → Scenario` (see [glossary](docs/GLOSSARY.md) for definitions). Run `/trace` to verify coverage and `/analyze` for severity-rated findings (duplicates, ambiguous terms, terminology drift, invalid references).
324
324
 
325
- ### Subcommands
325
+ ### Refinement skills
326
+
327
+ Available at any pipeline stage after the first artifact exists. These skills refine and validate artifacts without advancing the pipeline (except `/done`, which finalizes and moves on).
326
328
 
327
329
  | Command | What it does |
328
330
  |---------|-------------|
@@ -338,7 +340,7 @@ Every artifact links back to its predecessors, forming the chain `FR → US →
338
340
 
339
341
  ## Minimum viable pipeline
340
342
 
341
- Not every project needs all 24 skills. Three common paths:
343
+ Not every project needs all 29 skills. Three common paths:
342
344
 
343
345
  **Concept-first** (when you don't yet know what to build):
344
346
  ```
package/bin/ba-toolkit.js CHANGED
@@ -21,7 +21,7 @@ const PKG = JSON.parse(fs.readFileSync(path.join(PACKAGE_ROOT, 'package.json'),
21
21
  // All five supported agents — Claude Code, Codex CLI, Gemini CLI,
22
22
  // Cursor, and Windsurf — load Agent Skills as direct subfolders of
23
23
  // their skills root: `<skills-root>/<skill-name>/SKILL.md`. The toolkit
24
- // installs the 24 skills natively in this layout for every agent. No
24
+ // installs the 29 skills natively in this layout for every agent. No
25
25
  // .mdc conversion. Confirmed against the Agent Skills documentation
26
26
  // for each platform via ctx7 MCP / official docs.
27
27
  //
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "@kudusov.takhir/ba-toolkit",
3
- "version": "4.0.4",
4
- "description": "AI-powered Business Analyst pipeline — 24 skills from concept discovery to a sequenced implementation plan an AI coding agent can execute, with one-command Notion + Confluence publish. Works with Claude Code, Codex CLI, Gemini CLI, Cursor, and Windsurf.",
3
+ "version": "4.1.1",
4
+ "description": "AI-powered Business Analyst pipeline — 29 skills from concept discovery to a sequenced implementation plan an AI coding agent can execute, with one-command Notion + Confluence publish. Works with Claude Code, Codex CLI, Gemini CLI, Cursor, and Windsurf.",
5
5
  "keywords": [
6
6
  "business-analyst",
7
7
  "requirements",
@@ -84,4 +84,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
84
84
 
85
85
  ## Style
86
86
 
87
- Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request.
87
+ Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -165,4 +165,4 @@ No pipeline advancement — this is a quality checkpoint, not a pipeline step.
165
165
 
166
166
  ## Style
167
167
 
168
- Formal, neutral. No emoji, slang. Generate output in the language of the artifacts. Element IDs, file names, and table column headers remain in English.
168
+ Formal, neutral. No emoji, slang. Generate output in the language of the artifacts — see `references/language-rule.md` for what to translate and what stays in English.
@@ -129,4 +129,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
129
129
 
130
130
  ## Style
131
131
 
132
- Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request. Endpoint names, field names, and error codes remain in English.
132
+ Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English. Endpoint names, field names, and error codes remain in English.
@@ -132,4 +132,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
132
132
 
133
133
  ## Style
134
134
 
135
- Formal, neutral. No emoji, slang, or evaluative language. Terms and abbreviations explained in parentheses on first use. Generate the artifact in the language of the user's request. Section headings, table headers, and labels also in the user's language.
135
+ Formal, neutral. No emoji, slang, or evaluative language. Terms and abbreviations explained in parentheses on first use. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -127,4 +127,4 @@ No pipeline advancement — return to the current artifact's workflow.
127
127
 
128
128
  ## Style
129
129
 
130
- Formal, neutral. Questions must be specific and reference exact element IDs. Generate output in the language of the artifact.
130
+ Formal, neutral. Questions must be specific and reference exact element IDs. Generate output in the language of the artifact — see `references/language-rule.md` for what to translate and what stays in English.
@@ -84,4 +84,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
84
84
 
85
85
  ## Style
86
86
 
87
- Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request.
87
+ Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -160,4 +160,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
160
160
 
161
161
  ## Style
162
162
 
163
- Formal, neutral, hypothesis-driven. No emoji, slang, or evaluative language ("amazing", "game-changing"). Frame every claim as a hypothesis to validate, not a fact. Generate the artifact in the language of the user's request. Section headings, table headers, and labels also in the user's language.
163
+ Formal, neutral, hypothesis-driven. No emoji, slang, or evaluative language ("amazing", "game-changing"). Frame every claim as a hypothesis to validate, not a fact. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -0,0 +1,118 @@
1
+ ---
2
+ name: done
3
+ description: >
4
+ Finalize the current artifact and advance to the next pipeline step. Use on /done command, or when the user says "done with this", "finalize", "lock this artifact", "move on", "next step", "mark as done", "approve this artifact". Gates on CRITICAL findings from /validate or /analyze. Updates AGENTS.md pipeline status.
5
+ ---
6
+
7
+ # /done — Finalize & Advance
8
+
9
+ Utility skill. Finalizes the current artifact, updates `AGENTS.md`, and presents the next pipeline step. This is the only refinement skill that advances the pipeline.
10
+
11
+ ## Syntax
12
+
13
+ ```
14
+ /done [optional: artifact reference]
15
+ ```
16
+
17
+ Examples:
18
+ - `/done` — finalize the most recent artifact
19
+ - `/done brief` — finalize the brief specifically
20
+ - `/done srs` — finalize the SRS
21
+
22
+ ## Context loading
23
+
24
+ 0. If `00_principles_*.md` exists in the output directory, load it. Use its quality gate (section 6) to determine which severity blocks finalization.
25
+ 1. Identify the target artifact:
26
+ - If the user specifies an artifact name, use it.
27
+ - Otherwise, use the most recently generated artifact in the output directory.
28
+ 2. Read the target artifact fully.
29
+ 3. Read `AGENTS.md` to find the pipeline status table.
30
+ 4. If `00_analyze_*.md` exists, check for unresolved CRITICAL findings against this artifact.
31
+
32
+ ## Environment
33
+
34
+ Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory. If unavailable, apply the default rule.
35
+
36
+ ## Slug source
37
+
38
+ Read `references/slug-source.md` from the `ba-toolkit` directory. Follow its rules to resolve the project slug from `AGENTS.md`.
39
+
40
+ ## Finalization workflow
41
+
42
+ ### Step 1 — Quality gate check
43
+
44
+ Before finalizing, run a lightweight validation:
45
+
46
+ 1. **Check for CRITICAL findings.** If `00_analyze_*.md` exists and contains unresolved CRITICAL findings for this artifact, block finalization:
47
+
48
+ ```
49
+ Cannot finalize — {N} CRITICAL finding(s) remain:
50
+ - A1: MoSCoW counts mismatch in §6
51
+ - A5: FR-012 referenced but does not exist
52
+
53
+ Fix these with `/revise` or `/validate`, then retry `/done`.
54
+ ```
55
+
56
+ 2. **Quick completeness scan.** Check for placeholder text (`(TBD)`, `(TODO)`, empty required fields). If found, warn but do not block:
57
+
58
+ ```
59
+ ⚠ {N} placeholder(s) found — consider resolving before finalizing:
60
+ - §5: "(имя основателя)" in stakeholders table
61
+ - FR-018: Source field is "(TBD)"
62
+
63
+ Finalize anyway? (yes / fix first)
64
+ ```
65
+
66
+ 3. **If no blockers**, proceed to finalization.
67
+
68
+ ### Step 2 — Update artifact metadata
69
+
70
+ Update the artifact header:
71
+
72
+ - **Version:** bump to `1.0` (or the next whole number if already versioned).
73
+ - **Status:** change from `Draft` to `Approved`.
74
+ - **Date:** update to today's date.
75
+
76
+ ### Step 3 — Update AGENTS.md
77
+
78
+ Find the `## Pipeline Status` table in `AGENTS.md`. Update the row for the current skill:
79
+
80
+ - **Status:** `⬜ Not started` or `🔄 In progress` → `✅ Done`
81
+ - **File:** fill in the artifact filename (e.g., `output/01_brief_sock-market.md`)
82
+
83
+ **Do not touch the managed block** (`<!-- ba-toolkit:begin managed -->` … `<!-- ba-toolkit:end managed -->`) — that is owned by `ba-toolkit init`.
84
+
85
+ ### Step 4 — Present next step
86
+
87
+ Build the `Next step:` block from the pipeline lookup table in `references/closing-message.md`. Look up the row where `Current` matches the skill that produced the finalized artifact, and present the four `→` lines:
88
+
89
+ ```
90
+ ✓ Artifact finalized: `{file_path}` — Version 1.0, Status: Approved.
91
+
92
+ AGENTS.md updated: {skill} → ✅ Done.
93
+
94
+ Next step: /{next_command}
95
+
96
+ → What it produces: {description}
97
+ → Output file: {NN}_{name}_{slug}.md
98
+ → Time estimate: {min}–{max} minutes
99
+ → After that: /{step_after_next} ({description})
100
+ ```
101
+
102
+ If the finalized artifact is from `/implement-plan` (the last pipeline step), present:
103
+
104
+ ```
105
+ ✓ Artifact finalized: `{file_path}` — Version 1.0, Status: Approved.
106
+
107
+ Pipeline complete. Hand `12_implplan_{slug}.md` to your AI coding agent (Claude Code, Cursor, Windsurf, Codex, Gemini) to begin implementation.
108
+ ```
109
+
110
+ ## Edge cases
111
+
112
+ - **Artifact already finalized.** If the artifact's Status is already `Approved` and AGENTS.md already shows `✅ Done`, inform the user and do nothing.
113
+ - **Multiple artifacts pending.** `/done` finalizes one artifact at a time. If the user wants to finalize multiple, they run `/done` once per artifact.
114
+ - **No AGENTS.md.** Warn the user that the project was likely not scaffolded with `ba-toolkit init`. Finalize the artifact metadata but skip the AGENTS.md update.
115
+
116
+ ## Style
117
+
118
+ Formal, neutral. Generate output in the language of the artifact — see `references/language-rule.md` for what to translate and what stays in English.
@@ -155,4 +155,4 @@ Available commands: `/estimate [US-NNN]` (re-estimate a story) · `/split [US-NN
155
155
 
156
156
  ## Style
157
157
 
158
- Be explicit about the rationale for each estimate. Use concise bullet drivers, not paragraphs. Generate output in the language of the artifact.
158
+ Be explicit about the rationale for each estimate. Use concise bullet drivers, not paragraphs. Generate output in the language of the artifact — see `references/language-rule.md` for what to translate and what stays in English.
@@ -0,0 +1,112 @@
1
+ ---
2
+ name: expand
3
+ description: >
4
+ Add more depth and detail to an under-developed section of a BA Toolkit artifact. Use on /expand command, or when the user asks to "expand this section", "add more detail", "flesh out", "elaborate on", "go deeper on", "add depth to", "develop further". Utility skill available at any pipeline stage after the first artifact exists.
5
+ ---
6
+
7
+ # /expand — Section Expansion
8
+
9
+ Utility skill. Adds depth, detail, and coverage to a thin or under-developed section of the target artifact. Updates the artifact in place; does not generate a new file.
10
+
11
+ ## Syntax
12
+
13
+ ```
14
+ /expand [section reference] [optional: inline guidance]
15
+ ```
16
+
17
+ Examples:
18
+ - `/expand risks` — expand the risks section of the most recent artifact
19
+ - `/expand §7` — expand section 7
20
+ - `/expand §3.2 add edge cases for payment failures` — expand with specific direction
21
+ - `/expand assumptions in brief` — expand the assumptions section of the brief
22
+ - `/expand FR-003` — expand a specific functional requirement with more detail
23
+
24
+ ## Context loading
25
+
26
+ 0. If `00_principles_*.md` exists in the output directory, load it.
27
+ 1. Identify the target artifact:
28
+ - If the user specifies an artifact name (e.g., "in brief", "in srs"), use it.
29
+ - Otherwise, use the most recently generated artifact in the output directory.
30
+ 2. Read the target artifact fully.
31
+ 3. Read prior artifacts for context that can inform the expansion.
32
+ 4. Load the domain reference (`references/domains/{domain}.md`) if available — domain-specific knowledge helps generate richer content.
33
+
34
+ ## Environment
35
+
36
+ Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory. If unavailable, apply the default rule.
37
+
38
+ ## Slug source
39
+
40
+ Read `references/slug-source.md` from the `ba-toolkit` directory. Follow its rules to resolve the project slug from `AGENTS.md`.
41
+
42
+ ## Section identification
43
+
44
+ Use the same identification strategy as `/revise`:
45
+
46
+ 1. **Section number.** `§3`, `section 3`, `§3.2`.
47
+ 2. **Section name keyword.** `risks`, `constraints`, `assumptions`, `glossary`.
48
+ 3. **Element ID.** `FR-003`, `US-012` — expand that specific element.
49
+
50
+ If the section cannot be identified, ask the user to clarify.
51
+
52
+ ## Expansion workflow
53
+
54
+ ### Step 1 — Assess current state
55
+
56
+ Read the target section and assess what is thin or missing:
57
+
58
+ - **Tables with few rows** — can more rows be added based on the domain reference, prior artifacts, or industry knowledge?
59
+ - **Single-sentence descriptions** — can they be expanded with acceptance criteria, edge cases, or examples?
60
+ - **Missing sub-sections** — does the template for this artifact type include sub-sections that are absent?
61
+ - **Bare elements** — elements with only required fields but no optional fields (Source, Rationale, Verification method, etc.)?
62
+
63
+ ### Step 2 — Generate expansion
64
+
65
+ If the user provided inline guidance, follow it. Otherwise, use domain knowledge and prior artifacts to determine what to add.
66
+
67
+ Follow these rules:
68
+
69
+ 1. **Add, don't replace.** Preserve all existing content. New content is appended or inserted at the appropriate position.
70
+ 2. **Follow the artifact's conventions.** Match ID scheme, heading levels, table columns, and language.
71
+ 3. **Ground in prior artifacts.** Every new element (FR, risk, assumption, etc.) should trace back to something in a prior artifact or in the domain reference. Do not invent requirements that contradict existing decisions.
72
+ 4. **Respect MoSCoW.** New elements added during expansion are typically Should or Could priority unless the user explicitly marks them higher.
73
+ 5. **Update counts.** If the artifact has a summary table with counts (e.g., MoSCoW distribution), update it after adding new elements.
74
+
75
+ ### Step 3 — Present and confirm
76
+
77
+ Before saving, present a summary of what will be added:
78
+
79
+ ```
80
+ Expanding §{N}: {section title}
81
+
82
+ Adding:
83
+ - {N} new {element type}(s): {brief list}
84
+ - {N} fields enriched on existing elements
85
+ - Sub-section "{name}" added
86
+
87
+ Total section size: {before} → {after} elements.
88
+
89
+ Apply? (yes / adjust — describe what to change)
90
+ ```
91
+
92
+ For small expansions (fewer than 3 changes), skip the confirmation and apply directly with a one-line acknowledgment.
93
+
94
+ ### Step 4 — Save
95
+
96
+ Save the updated artifact. Bump the version (e.g., `0.1` → `0.2`) and update the date.
97
+
98
+ ## Closing message
99
+
100
+ After saving, present the following summary (see `references/closing-message.md` for format):
101
+
102
+ - Saved file path.
103
+ - Summary of what was added (element counts, new sub-sections).
104
+ - Any new cross-references created.
105
+
106
+ Available commands: `/expand [section]` (expand another section) · `/validate` · `/clarify [focus]` · `/revise [section]` · `/done`
107
+
108
+ No pipeline advancement — return to the current artifact's workflow.
109
+
110
+ ## Style
111
+
112
+ Formal, neutral. Generate output in the language of the artifact — see `references/language-rule.md` for what to translate and what stays in English.
@@ -220,4 +220,4 @@ Available commands: `/export [format]` (export in another format) · `/estimate`
220
220
 
221
221
  ## Style
222
222
 
223
- Generate only valid JSON or CSV. Do not include comments inside JSON files. Use double quotes for all JSON strings. Escape newlines in description fields as `\n`. Generate output in English regardless of the artifact language (issue trackers expect English field values unless explicitly told otherwise).
223
+ Generate only valid JSON or CSV. Do not include comments inside JSON files. Use double quotes for all JSON strings. Escape newlines in description fields as `\n`. Generate output in English regardless of the artifact language (issue trackers expect English field values unless explicitly told otherwise). Chat messages (interview questions, closing summary) follow `references/language-rule.md` — use the user's language.
@@ -161,4 +161,4 @@ Available commands: `/glossary drift` (drift report only) · `/glossary add [Ter
161
161
 
162
162
  ## Style
163
163
 
164
- Neutral, precise. Term definitions should be one sentence, domain-specific, and consistent with the artifact language set in `00_principles_{slug}.md`. Do not invent definitions — only use what is stated or clearly implied in the artifacts.
164
+ Neutral, precise. Term definitions should be one sentence, domain-specific, and consistent with the artifact language. Do not invent definitions — only use what is stated or clearly implied in the artifacts. See `references/language-rule.md` for what to translate and what stays in English.
@@ -190,4 +190,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
190
190
 
191
191
  ## Style
192
192
 
193
- Formal, neutral. No emoji in the saved file. Generate in the artifact language. English for IDs, file names, table column headers, and code.
193
+ Formal, neutral. No emoji in the saved file. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -280,4 +280,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
280
280
 
281
281
  ## Style
282
282
 
283
- Formal, neutral, imperative. No emoji in the saved file. Phase goals are user-outcome sentences, not task lists. Task titles are imperative verbs ("Create", "Implement", "Wire", "Migrate", "Document"). Definition-of-Done bullets are checkable, not aspirational. Generate the artifact in the language of the user's request; section headings, table headers, and labels also in the user's language. ID columns and code identifiers (`T-04-007`, `FR-001`, `Entity:User`, file paths) stay ASCII.
283
+ Formal, neutral, imperative. No emoji in the saved file. Phase goals are user-outcome sentences, not task lists. Task titles are imperative verbs ("Create", "Implement", "Wire", "Migrate", "Document"). Definition-of-Done bullets are checkable, not aspirational. Generate the artifact in the language of the user's request see `references/language-rule.md` for what to translate and what stays in English.
@@ -87,4 +87,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
87
87
 
88
88
  ## Style
89
89
 
90
- Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request.
90
+ Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -182,4 +182,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
182
182
 
183
183
  ## Style
184
184
 
185
- Formal, neutral. No emoji, slang. The principles file itself is generated in the artifact language defined in section 1. Section headings and table column headers remain in that language.
185
+ Formal, neutral. No emoji, slang. The principles file itself is generated in the artifact language defined in section 1. See `references/language-rule.md` for what to translate and what stays in English.
@@ -76,4 +76,4 @@ Do not build a `Next step:` block — `/publish` is cross-cutting and does not a
76
76
 
77
77
  ## Style
78
78
 
79
- Formal, neutral. No emoji. Generate the chat reply in the language of the user's first message. Keep the report under 10 lines: paths, counts, two next-step lines, optional re-run hint.
79
+ Formal, neutral. No emoji. Generate the chat reply in the language of the user's first message — see `references/language-rule.md` for what to translate and what stays in English. Keep the report under 10 lines: paths, counts, two next-step lines, optional re-run hint.
@@ -4,7 +4,7 @@ After saving an artifact, every BA Toolkit skill presents a closing summary bloc
4
4
 
5
5
  ## Format
6
6
 
7
- Present the block in the same language as the artifact.
7
+ Present the block in the same language as the artifact. The template below is written in English because this file follows the project's English-only convention. At generation time, translate all labels ("Artifact saved:", "Available commands:", "Next step:", "What it produces:", "Quality check before moving on:", table headers) to the artifact's language. Slash commands (`/clarify`, `/revise`, etc.) and file paths stay as-is. See `references/language-rule.md` for the full list of what to translate and what stays in English.
8
8
 
9
9
  ```
10
10
  Artifact saved: `{file_path}`
@@ -17,7 +17,7 @@ Every BA Toolkit skill that gathers information from the user MUST follow this p
17
17
 
18
18
  4. **Wait for the answer.** Do not generate the next question or any part of the artifact until the user has replied. A non-answer (e.g. "I don't know", "skip") is a valid answer — record it as "unknown" and move on. The user can respond with the letter ID (`a`, `b`, …), the verbatim variant text, or — for the free-text row — any text of their own.
19
19
 
20
- 5. **Acknowledge, then proceed.** After each answer, reflect it back in one line (e.g. "Got it — primary user is the Ops team at mid-size logistics companies.") before asking the next question. This catches misunderstandings early.
20
+ 5. **Acknowledge, then proceed.** After each answer, reflect it back in one line **in the user's language** (e.g. "Got it — primary user is the Ops team at mid-size logistics companies.") before asking the next question. This catches misunderstandings early.
21
21
 
22
22
  6. **Batch only when the user asks.** If the user explicitly says "just give me all the questions at once" or "I'll answer in one go", switch to a single numbered list. Otherwise stay one-at-a-time.
23
23
 
@@ -0,0 +1,31 @@
1
+ # Language Rule
2
+
3
+ Template files, reference documents, and closing-message templates in BA Toolkit are written in English per the project's English-only file convention. When generating artifacts, chat summaries (closing messages), and interview questions, translate **all** of the following to the user's language:
4
+
5
+ ## Translate to the user's language
6
+
7
+ - Section headings (`##` and `###`)
8
+ - Table headers (`| Column | ... |`)
9
+ - Field labels (`**Priority:**`, `**Description:**`, `**Type:**`, `**Source:**`, `**Linked FR:**`, `**Depends on:**`, `**Notes:**`, etc.)
10
+ - User story labels (`**As**` / `**I want to**` / `**so that**`)
11
+ - Acceptance criteria labels (`**Given**` / `**When**` / `**Then**`)
12
+ - Closing message labels ("Artifact saved:", "Available commands:", "Next step:", "What it produces:", "Quality check before moving on:", table headers in the commands table)
13
+ - Interview acknowledgments ("Got it — ...")
14
+ - Interview question text and option variants (per interview-protocol rule 11)
15
+
16
+ ## Keep in English/ASCII regardless of artifact language
17
+
18
+ - Element IDs: FR-001, US-001, AC-001-01, NFR-001, UC-001, E-01, etc.
19
+ - File paths and filenames: `output/01_brief_my-app.md`
20
+ - Slash commands: `/brief`, `/srs`, `/clarify`, `/revise`, `/validate`, `/done`, etc.
21
+ - The `(recommended)` marker in interview option tables
22
+ - Letter IDs in option tables: `a`, `b`, `c`, `d`, `e`
23
+ - MoSCoW priority values: Must, Should, Could, Won't
24
+ - INVEST criteria names: Independent, Negotiable, Valuable, Estimable, Small, Testable
25
+ - Code identifiers, API endpoint paths, HTTP methods, status codes
26
+ - Technical terms that are industry-standard English (REST, JWT, OAuth, CRUD, etc.)
27
+ - ISO/IEEE standard references (IEEE 830, ISO 25010, ISO 31000, etc.)
28
+
29
+ ## Why this rule exists
30
+
31
+ Without this rule, the AI copies English labels from templates verbatim and only translates body text, producing mixed-language artifacts — e.g., Russian content under English headings, or an English closing summary after a Russian-language interview. The rule ensures that every user-facing text element matches the artifact's language while technical identifiers stay stable for cross-referencing.
@@ -152,4 +152,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
152
152
 
153
153
  ## Style
154
154
 
155
- Formal, neutral. No emoji, slang. Generate in the artifact language. Technical terms (ADR, REST, WebSocket, JWT) remain in English. Architecture option names remain in English.
155
+ Formal, neutral. No emoji, slang. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English. Architecture option names remain in English.
@@ -0,0 +1,124 @@
1
+ ---
2
+ name: revise
3
+ description: >
4
+ Rewrite a specific section of a BA Toolkit artifact with new feedback. Use on /revise command, or when the user asks to "revise a section", "rewrite this part", "update section", "fix section", "change section", "rework this", "apply feedback". Accepts a section name, section number, or an /analyze finding ID. Utility skill available at any pipeline stage after the first artifact exists.
5
+ ---
6
+
7
+ # /revise — Section Rewrite
8
+
9
+ Utility skill. Rewrites a specific section (or resolves a specific finding) in the target artifact based on the user's feedback. Updates the artifact in place; does not generate a new file.
10
+
11
+ ## Syntax
12
+
13
+ ```
14
+ /revise [section reference or finding ID] [optional: inline feedback]
15
+ ```
16
+
17
+ Examples:
18
+ - `/revise §6` — revise section 6 of the most recent artifact
19
+ - `/revise risks` — revise the risks section
20
+ - `/revise A1` — resolve finding A1 from the latest `/analyze` report
21
+ - `/revise §3 add more detail about payment processing` — revise with inline direction
22
+ - `/revise V-002` — resolve finding V-002 from the latest `/validate` report
23
+ - `/revise section 7 in brief` — revise section 7 of the brief specifically
24
+
25
+ ## Context loading
26
+
27
+ 0. If `00_principles_*.md` exists in the output directory, load it. Use its conventions for maintaining consistency during the rewrite.
28
+ 1. Identify the target artifact:
29
+ - If the user specifies an artifact name (e.g., "in brief", "in srs"), use it.
30
+ - If the user specifies a finding ID (e.g., `A1`, `V-002`), locate the finding in `00_analyze_*.md` or the last `/validate` output, and use the artifact referenced by that finding.
31
+ - Otherwise, use the most recently generated artifact in the output directory.
32
+ 2. Read the target artifact fully.
33
+ 3. Read prior artifacts for cross-reference context (roles, terms, IDs).
34
+ 4. If the user referenced an `/analyze` finding, read `00_analyze_*.md` to understand the finding details and recommendation.
35
+
36
+ ## Environment
37
+
38
+ Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory. If unavailable, apply the default rule.
39
+
40
+ ## Slug source
41
+
42
+ Read `references/slug-source.md` from the `ba-toolkit` directory. Follow its rules to resolve the project slug from `AGENTS.md`.
43
+
44
+ ## Section identification
45
+
46
+ Identify the target section using one of these strategies (in order of priority):
47
+
48
+ 1. **Section number.** `§3`, `section 3`, `§3.2` — match the `## 3.` or `### 3.2` heading.
49
+ 2. **Section name keyword.** `risks`, `constraints`, `stakeholders`, `MoSCoW`, `glossary` — match the closest heading by keyword.
50
+ 3. **Finding ID.** `A1`, `A2`, `V-001` — read the finding's `Location` field to identify the section and element.
51
+ 4. **Element ID.** `FR-003`, `US-012` — find the element and its containing section.
52
+
53
+ If the section cannot be identified, ask the user to clarify.
54
+
55
+ ## Revision workflow
56
+
57
+ ### Step 1 — Understand the change
58
+
59
+ If the user provided inline feedback (e.g., `/revise §3 add payment processing details`), use it directly.
60
+
61
+ If the user provided only a section reference, ask one focused question:
62
+
63
+ ```
64
+ Section {N}: {section title} — {current content summary in one line}.
65
+
66
+ What should change? (Describe the update, or type "apply A1" to use an /analyze recommendation.)
67
+ ```
68
+
69
+ If the user referenced a finding ID, extract the finding's `Recommendation` field and confirm:
70
+
71
+ ```
72
+ Finding {ID}: {summary}. Recommendation: {recommendation}.
73
+
74
+ Apply this recommendation? (yes / adjust — type your version)
75
+ ```
76
+
77
+ ### Step 2 — Rewrite
78
+
79
+ Rewrite the identified section following these rules:
80
+
81
+ 1. **Preserve structure.** Keep the same heading level, table format, and element ID scheme.
82
+ 2. **Preserve unchanged content.** Only modify what needs to change. Do not rewrite adjacent sections.
83
+ 3. **Maintain cross-references.** If the rewrite changes an element ID, update all internal references within the artifact.
84
+ 4. **Follow artifact conventions.** Match the style, language, and format of the rest of the artifact.
85
+ 5. **Update metadata.** Bump the artifact version (e.g., `0.1` → `0.2`) and update the date.
86
+
87
+ ### Step 3 — Ripple-effect check
88
+
89
+ Before saving, check whether the change affects other artifacts:
90
+
91
+ - A changed role definition affects `/srs` Roles, `/stories` personas, `/usecases` actors, `/scenarios` personas.
92
+ - A changed business rule affects `/srs` business rules, `/ac` Given/When/Then conditions, `/datadict` constraints, `/apicontract` validation rules.
93
+ - A changed FR affects `/stories` (linked FR), `/usecases` (linked FR), `/ac` (linked US → FR), `/nfr` (if the FR had NFR implications).
94
+ - A removed or renumbered element affects every artifact that references its ID.
95
+
96
+ If ripple effects are detected, list the affected files and offer to update them:
97
+
98
+ ```
99
+ This change affects {N} other artifact(s):
100
+ - `02_srs_*.md` — roles section references the changed role
101
+ - `03_stories_*.md` — 2 stories link to the modified FR
102
+
103
+ Update them now? (yes / no / pick files)
104
+ ```
105
+
106
+ ### Step 4 — Save
107
+
108
+ Save the updated artifact. If the user approved ripple-effect updates, save those too.
109
+
110
+ ## Closing message
111
+
112
+ After saving, present the following summary (see `references/closing-message.md` for format):
113
+
114
+ - Saved file path(s).
115
+ - Summary of what changed (section, element count, nature of change).
116
+ - Any ripple-effect updates applied or deferred.
117
+
118
+ Available commands: `/revise [section]` (revise another section) · `/validate` · `/clarify [focus]` · `/done`
119
+
120
+ No pipeline advancement — return to the current artifact's workflow.
121
+
122
+ ## Style
123
+
124
+ Formal, neutral. Generate output in the language of the artifact — see `references/language-rule.md` for what to translate and what stays in English.
@@ -196,4 +196,4 @@ Available commands: `/risk add [description]` · `/risk update RISK-NN` · `/cla
196
196
 
197
197
  ## Style
198
198
 
199
- Concise, factual. Risk descriptions state the condition and consequence ("If X happens, then Y will occur"). Do not inflate severity — score based on evidence from artifacts, not speculation. Use the artifact language set in `00_principles_{slug}.md`.
199
+ Concise, factual. Risk descriptions state the condition and consequence ("If X happens, then Y will occur"). Do not inflate severity — score based on evidence from artifacts, not speculation. Generate output in the language of the artifact — see `references/language-rule.md` for what to translate and what stays in English.
@@ -80,4 +80,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
80
80
 
81
81
  ## Style
82
82
 
83
- Formal, neutral. No emoji, slang. Generate in the artifact language. Persona names, screen labels, and API paths remain in their original language/format.
83
+ Formal, neutral. No emoji, slang. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English. Persona names, screen labels, and API paths remain in their original language/format.
@@ -0,0 +1,151 @@
1
+ ---
2
+ name: split
3
+ description: >
4
+ Break a large element (FR, User Story, Use Case, etc.) into smaller, more manageable pieces. Use on /split command, or when the user asks to "split this story", "break down", "decompose", "this is too big", "split requirement", "make smaller". References INVEST criteria for User Stories and Mike Cohn's nine story-splitting patterns. Utility skill available at any pipeline stage after the first artifact exists.
5
+ ---
6
+
7
+ # /split — Element Decomposition
8
+
9
+ Utility skill. Breaks a large element (FR, US, UC, AC, NFR) into smaller, well-scoped pieces. Updates the artifact in place; does not generate a new file.
10
+
11
+ ## Syntax
12
+
13
+ ```
14
+ /split [element ID] [optional: split strategy hint]
15
+ ```
16
+
17
+ Examples:
18
+ - `/split US-014` — split User Story 014
19
+ - `/split FR-003` — split Functional Requirement 003
20
+ - `/split US-014 by user role` — split by role (one of Cohn's patterns)
21
+ - `/split UC-005 by happy path vs error paths` — split by flow
22
+ - `/split FR-012 into CRUD operations` — split by operation
23
+
24
+ ## Context loading
25
+
26
+ 0. If `00_principles_*.md` exists in the output directory, load it. Use its ID conventions (section 2) to assign new IDs and its Definition of Ready (section 4) to validate the resulting elements.
27
+ 1. Identify the target artifact by finding the element ID in the output directory.
28
+ 2. Read the target artifact fully.
29
+ 3. Read prior artifacts for context (the element's linked FRs, upstream brief goals, etc.).
30
+
31
+ ## Environment
32
+
33
+ Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory. If unavailable, apply the default rule.
34
+
35
+ ## Slug source
36
+
37
+ Read `references/slug-source.md` from the `ba-toolkit` directory. Follow its rules to resolve the project slug from `AGENTS.md`.
38
+
39
+ ## Split strategies
40
+
41
+ Use the appropriate strategy based on the element type and the user's hint. If no hint is provided, choose the best strategy automatically.
42
+
43
+ ### For User Stories — INVEST + Cohn's nine patterns
44
+
45
+ A story should be split when it violates the **S** (Small) or **I** (Independent) criteria of INVEST. Apply one of Mike Cohn's nine story-splitting patterns:
46
+
47
+ 1. **By workflow step.** "As a buyer, I can purchase an item" → separate stories for browse, add-to-cart, checkout, payment, confirmation.
48
+ 2. **By business rule variation.** "As a master, I can set pricing" → separate stories for fixed price, auction, bulk discount.
49
+ 3. **By data variation.** "As a buyer, I can search" → separate stories for search by keyword, by category, by price range, by material.
50
+ 4. **By interface.** "As a user, I can pay" → separate stories for card payment, SBP, e-wallet.
51
+ 5. **By user role.** "As a user, I can manage profile" → separate stories for buyer profile vs. master profile.
52
+ 6. **By CRUD operation.** "As an admin, I can manage masters" → create, read, update, delete/suspend.
53
+ 7. **By happy path vs. exceptions.** "As a buyer, I can place an order" → happy path, out-of-stock, payment failure, address validation error.
54
+ 8. **By effort (spike + implementation).** "As a developer, I can integrate payment gateway" → research/spike story + implementation story.
55
+ 9. **By platform/channel.** "As a user, I can receive notifications" → email, push, in-app.
56
+
57
+ ### For Functional Requirements
58
+
59
+ Split by:
60
+ - **Sub-function.** A compound FR ("The system shall manage orders") → separate FRs for order creation, status tracking, cancellation, refund.
61
+ - **Actor.** An FR that serves multiple roles → one FR per role.
62
+ - **Trigger condition.** An FR with multiple triggers → one FR per trigger.
63
+
64
+ ### For Use Cases
65
+
66
+ Split by:
67
+ - **Goal level.** A summary-level UC → multiple user-goal-level UCs.
68
+ - **Main flow vs. extensions.** A UC with 5+ extensions → promote major extensions to separate UCs.
69
+
70
+ ## Split workflow
71
+
72
+ ### Step 1 — Analyze the element
73
+
74
+ Read the element and determine:
75
+ - Why it is too large (too many acceptance criteria, too many business rules, too many actors, compound action).
76
+ - Which split strategy fits best.
77
+ - How many pieces it should become (typically 2–4; never more than 6).
78
+
79
+ ### Step 2 — Propose the split
80
+
81
+ Present the proposed split for user review:
82
+
83
+ ```
84
+ Splitting {element_ID}: "{element title}"
85
+
86
+ Strategy: {strategy name} (e.g., "by workflow step")
87
+ Reason: {why this element is too large}
88
+
89
+ | New ID | Title | Priority | Key difference |
90
+ |--------|-------|----------|----------------|
91
+ | US-014a | ... | Must | ... |
92
+ | US-014b | ... | Must | ... |
93
+ | US-014c | ... | Should | ... |
94
+
95
+ The original {element_ID} will be replaced by these {N} elements.
96
+
97
+ Cross-references that currently point to {element_ID}:
98
+ - AC-021, AC-022 → will be reassigned to the appropriate new element
99
+ - UC-005 step 3 → will reference US-014a
100
+
101
+ Apply? (yes / adjust — describe what to change)
102
+ ```
103
+
104
+ ### Step 3 — Assign new IDs
105
+
106
+ Follow the project's ID convention:
107
+
108
+ - **If the project uses sequential IDs** (FR-001, FR-002, …), assign the next available IDs.
109
+ - **Suffix convention.** If the user prefers, use suffix IDs (US-014a, US-014b, US-014c) to preserve traceability to the original element.
110
+ - **Ask if ambiguous.** If the convention is unclear, ask the user.
111
+
112
+ ### Step 4 — Apply and update references
113
+
114
+ 1. Replace the original element with the new elements in the artifact.
115
+ 2. Update all internal cross-references within the artifact (e.g., MoSCoW summary table, forward traceability matrix).
116
+ 3. Check for references in other artifacts. List affected files and offer to update:
117
+
118
+ ```
119
+ The following artifacts reference {element_ID}:
120
+ - `05_ac_*.md` — AC-021, AC-022 linked to the original story
121
+ - `04_usecases_*.md` — UC-005 step 3
122
+
123
+ Update them? (yes / no / pick files)
124
+ ```
125
+
126
+ ### Step 5 — Validate result
127
+
128
+ After applying, run a quick INVEST check on each new User Story (if applicable) and report:
129
+
130
+ ```
131
+ INVEST check:
132
+ - US-014a: ✓ all criteria pass
133
+ - US-014b: ✓ all criteria pass
134
+ - US-014c: ⚠ Testable — no AC linked yet (will be created in /ac step)
135
+ ```
136
+
137
+ ## Closing message
138
+
139
+ After saving, present the following summary (see `references/closing-message.md` for format):
140
+
141
+ - Saved file path(s).
142
+ - Original element replaced by {N} new elements.
143
+ - Cross-reference updates applied or deferred.
144
+
145
+ Available commands: `/split [element]` (split another element) · `/validate` · `/revise [section]` · `/done`
146
+
147
+ No pipeline advancement — return to the current artifact's workflow.
148
+
149
+ ## Style
150
+
151
+ Formal, neutral. Generate output in the language of the artifact — see `references/language-rule.md` for what to translate and what stays in English.
@@ -120,4 +120,4 @@ Available commands: `/sprint [SP-NN]` (re-plan a sprint) · `/split [US-NNN]` (s
120
120
 
121
121
  ## Style
122
122
 
123
- 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.
123
+ 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 — see `references/language-rule.md` for what to translate and what stays in English.
@@ -146,4 +146,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
146
146
 
147
147
  ## Style
148
148
 
149
- Formal, neutral. No emoji, slang. Terms explained in parentheses on first use. Generate the artifact in the language of the user's request.
149
+ Formal, neutral. No emoji, slang. Terms explained in parentheses on first use. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -87,4 +87,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
87
87
 
88
88
  ## Style
89
89
 
90
- Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request.
90
+ Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -67,4 +67,4 @@ No further pipeline step — use `/analyze` for a detailed cross-artifact qualit
67
67
 
68
68
  ## Style
69
69
 
70
- Formal, neutral. No emoji, slang. Generate the artifact in the language of the user's request.
70
+ Formal, neutral. No emoji, slang. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -79,4 +79,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
79
79
 
80
80
  ## Style
81
81
 
82
- Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request.
82
+ Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.
@@ -0,0 +1,124 @@
1
+ ---
2
+ name: validate
3
+ description: >
4
+ Internal completeness and consistency check for a single BA Toolkit artifact. Use on /validate command, or when the user asks to "validate this artifact", "check completeness", "is this artifact complete", "consistency check", "check if ready", "is it done", "quality gate check". Utility skill available at any pipeline stage after the first artifact exists. Unlike /analyze (cross-artifact), /validate focuses on one artifact at a time.
5
+ ---
6
+
7
+ # /validate — Artifact Completeness & Consistency Check
8
+
9
+ Utility skill. Performs a single-artifact validation pass: checks that the target artifact is internally complete, consistent, and ready to `/done`. Does not generate a new file — reports findings in chat and optionally fixes issues in place.
10
+
11
+ ## Syntax
12
+
13
+ ```
14
+ /validate [optional: artifact reference]
15
+ ```
16
+
17
+ Examples:
18
+ - `/validate` — validate the most recent artifact
19
+ - `/validate brief` — validate `01_brief_*.md`
20
+ - `/validate srs` — validate `02_srs_*.md`
21
+ - `/validate 03_stories_sock-market.md` — validate a specific file
22
+
23
+ ## Context loading
24
+
25
+ 0. If `00_principles_*.md` exists in the output directory, load it. Use its Definition of Ready (section 4) as the primary checklist, its ID conventions (section 2) to validate ID formats, and its quality gate (section 6) to determine which severity blocks `/done`.
26
+ 1. Identify the target artifact:
27
+ - If the user specifies an artifact name or filename, use it.
28
+ - Otherwise, use the most recently generated artifact in the output directory.
29
+ 2. Read the target artifact fully.
30
+ 3. Read prior artifacts for cross-reference spot-checks (roles, terms, IDs referenced from the target).
31
+
32
+ ## Environment
33
+
34
+ Read `references/environment.md` from the `ba-toolkit` directory to determine the output directory. If unavailable, apply the default rule.
35
+
36
+ ## Slug source
37
+
38
+ Read `references/slug-source.md` from the `ba-toolkit` directory. Follow its rules to resolve the project slug from `AGENTS.md`.
39
+
40
+ ## Validation checklist
41
+
42
+ Run the following checks against the target artifact. Each check maps to a severity level.
43
+
44
+ ### Structural checks (CRITICAL if missing)
45
+
46
+ 1. **Metadata present.** The artifact has a title, version, status, domain, date, and slug in the header.
47
+ 2. **All mandatory sections exist.** Compare the artifact's `## N.` headings against the expected template structure for that artifact type.
48
+ 3. **ID format consistent.** All element IDs (FR-NNN, US-NNN, UC-NNN, AC-NNN, NFR-NNN, etc.) follow the project's ID convention (from `00_principles_*.md` §2, or the default `XX-NNN` pattern).
49
+
50
+ ### Completeness checks (HIGH if missing)
51
+
52
+ 4. **No placeholder text.** Scan for `(TBD)`, `(TODO)`, `(TBC)`, `(placeholder)`, `(имя основателя)`, `(name)`, empty table cells in required columns.
53
+ 5. **Definition of Ready.** If `00_principles_*.md` exists, check each element against the DoR checklist for its type (FR, US, UC, AC, NFR). Report which elements fail which DoR criteria.
54
+ 6. **MoSCoW count consistency.** If the artifact has a MoSCoW summary table and individual priorities, verify that the counts match. Report discrepancies with exact numbers.
55
+ 7. **Cross-reference validity.** Every ID referenced in the artifact (e.g., `FR-003` in a US's "Linked FR" field) must exist within the artifact or in a prior artifact. Flag dangling references.
56
+
57
+ ### Consistency checks (MEDIUM)
58
+
59
+ 8. **Role consistency.** Roles/actors used in the artifact must match the roles defined in the SRS roles section or the brief stakeholders section. Flag unknown roles.
60
+ 9. **Glossary term usage.** Terms that appear in the glossary (if `00_glossary_*.md` exists) should be used consistently. Flag variant spellings or undefined terms.
61
+ 10. **Priority distribution.** If every element is marked "Must", warn that the prioritization may not be meaningful.
62
+
63
+ ### Style checks (LOW)
64
+
65
+ 11. **Empty sections.** Sections that exist but contain no content.
66
+ 12. **Orphan elements.** Elements with no cross-references to or from other elements within the artifact.
67
+
68
+ ## Output format
69
+
70
+ Present findings grouped by severity, with a summary count at the top:
71
+
72
+ ```
73
+ Validation results for `{artifact_file}`:
74
+
75
+ | Severity | Count |
76
+ |----------|-------|
77
+ | CRITICAL | N |
78
+ | HIGH | N |
79
+ | MEDIUM | N |
80
+ | LOW | N |
81
+
82
+ ### CRITICAL
83
+
84
+ 1. **V-001** [Structural] MoSCoW summary says 25 Must, but 34 FRs are marked Must.
85
+ → Fix: update the summary table in §6.
86
+
87
+ ### HIGH
88
+
89
+ 2. **V-002** [Completeness] FR-012 has no Source field.
90
+ → Fix: add `Source: G-2` (brief goal 2).
91
+
92
+ ...
93
+ ```
94
+
95
+ If all checks pass, report:
96
+
97
+ ```
98
+ ✓ Validation passed for `{artifact_file}` — no issues found. Ready to `/done`.
99
+ ```
100
+
101
+ ## Auto-fix offer
102
+
103
+ After presenting findings, offer to fix issues automatically:
104
+
105
+ - If CRITICAL or HIGH findings exist: "Found {N} issues. Want me to fix them? (yes / no / pick specific V-NNN IDs)"
106
+ - If only MEDIUM/LOW: "Found {N} minor issues. Want me to fix them, or proceed to `/done`?"
107
+
108
+ When fixing, update the artifact in place. After each fix, confirm what changed in one line.
109
+
110
+ ## Closing message
111
+
112
+ After validation (and optional fixes), present the following summary (see `references/closing-message.md` for format):
113
+
114
+ - Artifact file path.
115
+ - Summary of findings by severity.
116
+ - Whether the artifact passes the `/done` gate (no CRITICAL findings remaining).
117
+
118
+ Available commands: `/validate` (re-run) · `/clarify [focus]` · `/revise [section]` · `/done`
119
+
120
+ No pipeline advancement — return to the current artifact's workflow.
121
+
122
+ ## Style
123
+
124
+ Formal, neutral. Findings must reference exact element IDs and section numbers. Generate output in the language of the artifact — see `references/language-rule.md` for what to translate and what stays in English.
@@ -113,4 +113,4 @@ Build the `Next step:` block from the pipeline lookup table in `references/closi
113
113
 
114
114
  ## Style
115
115
 
116
- Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request.
116
+ Formal, neutral. No emoji, slang. Terms explained on first use. Generate the artifact in the language of the user's request — see `references/language-rule.md` for what to translate and what stays in English.