@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 +26 -1
- package/COMMANDS.md +10 -10
- package/README.md +8 -6
- package/bin/ba-toolkit.js +1 -1
- package/package.json +2 -2
- package/skills/ac/SKILL.md +1 -1
- package/skills/analyze/SKILL.md +1 -1
- package/skills/apicontract/SKILL.md +1 -1
- package/skills/brief/SKILL.md +1 -1
- package/skills/clarify/SKILL.md +1 -1
- package/skills/datadict/SKILL.md +1 -1
- package/skills/discovery/SKILL.md +1 -1
- package/skills/done/SKILL.md +118 -0
- package/skills/estimate/SKILL.md +1 -1
- package/skills/expand/SKILL.md +112 -0
- package/skills/export/SKILL.md +1 -1
- package/skills/glossary/SKILL.md +1 -1
- package/skills/handoff/SKILL.md +1 -1
- package/skills/implement-plan/SKILL.md +1 -1
- package/skills/nfr/SKILL.md +1 -1
- package/skills/principles/SKILL.md +1 -1
- package/skills/publish/SKILL.md +1 -1
- package/skills/references/closing-message.md +1 -1
- package/skills/references/interview-protocol.md +1 -1
- package/skills/references/language-rule.md +31 -0
- package/skills/research/SKILL.md +1 -1
- package/skills/revise/SKILL.md +124 -0
- package/skills/risk/SKILL.md +1 -1
- package/skills/scenarios/SKILL.md +1 -1
- package/skills/split/SKILL.md +151 -0
- package/skills/sprint/SKILL.md +1 -1
- package/skills/srs/SKILL.md +1 -1
- package/skills/stories/SKILL.md +1 -1
- package/skills/trace/SKILL.md +1 -1
- package/skills/usecases/SKILL.md +1 -1
- package/skills/validate/SKILL.md +124 -0
- package/skills/wireframes/SKILL.md +1 -1
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.
|
|
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
|
|
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
|
-
##
|
|
49
|
+
## Refinement skills
|
|
50
50
|
|
|
51
|
-
Available
|
|
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
|
-
|
|
|
54
|
-
|
|
55
|
-
| `/
|
|
56
|
-
| `/
|
|
57
|
-
| `/
|
|
58
|
-
| `/
|
|
59
|
-
| `/done` |
|
|
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 **
|
|
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
|
|
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
|
|
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
|
|
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
|
-
###
|
|
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
|
|
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
|
+
// 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.
|
|
4
|
-
"description": "AI-powered Business Analyst pipeline —
|
|
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",
|
package/skills/ac/SKILL.md
CHANGED
|
@@ -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.
|
package/skills/analyze/SKILL.md
CHANGED
|
@@ -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.
|
|
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.
|
package/skills/brief/SKILL.md
CHANGED
|
@@ -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.
|
|
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.
|
package/skills/clarify/SKILL.md
CHANGED
|
@@ -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.
|
package/skills/datadict/SKILL.md
CHANGED
|
@@ -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.
|
|
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.
|
package/skills/estimate/SKILL.md
CHANGED
|
@@ -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.
|
package/skills/export/SKILL.md
CHANGED
|
@@ -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.
|
package/skills/glossary/SKILL.md
CHANGED
|
@@ -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
|
|
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.
|
package/skills/handoff/SKILL.md
CHANGED
|
@@ -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
|
|
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
|
|
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.
|
package/skills/nfr/SKILL.md
CHANGED
|
@@ -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.
|
|
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.
|
package/skills/publish/SKILL.md
CHANGED
|
@@ -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.
|
package/skills/research/SKILL.md
CHANGED
|
@@ -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
|
|
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.
|
package/skills/risk/SKILL.md
CHANGED
|
@@ -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.
|
|
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
|
|
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.
|
package/skills/sprint/SKILL.md
CHANGED
|
@@ -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.
|
package/skills/srs/SKILL.md
CHANGED
|
@@ -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.
|
package/skills/stories/SKILL.md
CHANGED
|
@@ -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.
|
package/skills/trace/SKILL.md
CHANGED
|
@@ -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.
|
package/skills/usecases/SKILL.md
CHANGED
|
@@ -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.
|