@kudusov.takhir/ba-toolkit 4.0.0 → 4.0.1

package/CHANGELOG.md

@@ -11,6 +11,14 @@ Versions follow [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
 ---
 
+## [4.0.1] — 2026-04-12
+
+### Fixed
+
+- **Removed stale v3.x references from skill files.** `/principles` still offered an "Output folder structure" interview topic with a `{slug}/` subfolder option that no longer exists in v4.0 — removed, topics renumbered (8 → 7). `principles-template.md` subfolder section and Decision Authority rows renumbered to match. `/brief`, `/discovery`, `/srs` SKILL.md files still referenced "per-project AGENTS.md" and "legacy v3.0 single-project layouts" — updated to v4.0 wording (project root, flat output).
+
+---
+
 ## [4.0.0] — 2026-04-11
 
 ### Changed
@@ -872,6 +880,7 @@ CI scripts that relied on the old behaviour (`init` creates files only, `install
 ---
 
 [Unreleased]: https://github.com/TakhirKudusov/ba-toolkit/compare/v3.10.1...HEAD
+[4.0.1]: https://github.com/TakhirKudusov/ba-toolkit/compare/v4.0.0...v4.0.1
 [4.0.0]: https://github.com/TakhirKudusov/ba-toolkit/compare/v3.13.1...v4.0.0
 [3.13.1]: https://github.com/TakhirKudusov/ba-toolkit/compare/v3.13.0...v3.13.1
 [3.13.0]: https://github.com/TakhirKudusov/ba-toolkit/compare/v3.12.0...v3.13.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kudusov.takhir/ba-toolkit",
-  "version": "4.0.0",
+  "version": "4.0.1",
   "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.",
   "keywords": [
     "business-analyst",

package/skills/brief/SKILL.md

@@ -103,9 +103,9 @@ If a domain reference is loaded, supplement general questions with domain-specif
 
 `ba-toolkit init` already created `AGENTS.md` at the project root. After saving `01_brief_{slug}.md` to `output/`, find the project's `AGENTS.md` (look in cwd first; if cwd is `output/`, check `../AGENTS.md`).
 
-**Update only the `## Pipeline Status` row for `/brief`** — toggle its status from `⬜ Not started` to `✅ Done` and fill in the artifact filename in the `File` column. **Do not touch the managed block** (`<!-- ba-toolkit:begin managed -->` … `<!-- ba-toolkit:end managed -->`) — that's owned by `ba-toolkit init`. **Do not recreate the file at the repo root.** **Do not add `## Artifacts` / `## Key context` sections** — those are not part of the v3.1+ template and would be ignored by future runs.
+**Update only the `## Pipeline Status` row for `/brief`** — toggle its status from `⬜ Not started` to `✅ Done` and fill in the artifact filename in the `File` column. **Do not touch the managed block** (`<!-- ba-toolkit:begin managed -->` … `<!-- ba-toolkit:end managed -->`) — that's owned by `ba-toolkit init`.
 
-If you find no `AGENTS.md` at all (neither in cwd nor up the tree), warn the user that the project was likely set up before v3.1 and tell them to run `ba-toolkit init --name "..." --slug {slug}` to scaffold the per-project `AGENTS.md`. Do not create one yourself with arbitrary structure.
+If you find no `AGENTS.md` at all, warn the user that the project was likely not scaffolded with `ba-toolkit init` and tell them to run it. Do not create one yourself with arbitrary structure.
 
 ### 7. Iterative refinement
 

package/skills/discovery/SKILL.md

@@ -127,11 +127,11 @@ Things we don't yet know and need to learn before committing real resources.
 
 `ba-toolkit init` already created `AGENTS.md` at the project root. After saving `00_discovery_{slug}.md` to `output/`, find the project's `AGENTS.md` (look in cwd first; if cwd is `output/`, check `../AGENTS.md`).
 
-**Update only the `## Pipeline Status` row for `/discovery`** — toggle its status from `⬜ Not started` to `✅ Done` and fill in the artifact filename in the `File` column. **Do not recreate the file at the repo root.** **Do not add `## Artifacts` / `## Key context` sections** — those are not part of the v3.1+ template and would be ignored by future runs.
+**Update only the `## Pipeline Status` row for `/discovery`** — toggle its status from `⬜ Not started` to `✅ Done` and fill in the artifact filename in the `File` column. **Do not touch the managed block** (`<!-- ba-toolkit:begin managed -->` … `<!-- ba-toolkit:end managed -->`) — that's owned by `ba-toolkit init`.
 
 **Domain field exception (managed block).** `/discovery` is the canonical source of truth for the project domain after `ba-toolkit init`. After saving `00_discovery_{slug}.md`, compare the recommended domain in §8 of the discovery artifact against the `**Domain:**` line inside the managed block of `AGENTS.md`. **If they differ, surgically update only that single line** to the new value — do not modify any other managed-block field (`**Project:**`, `**Slug:**`, `**Language:**`, `**Output folder:**`, the auto-generated date comment). Mention the change in the user-facing reply: "Updated the project domain in AGENTS.md from `<old>` to `<new>` based on the discovery recommendation." This is the only managed-block field `/discovery` may touch; everything else inside `<!-- ba-toolkit:begin managed -->` … `<!-- ba-toolkit:end managed -->` remains owned by `ba-toolkit init`.
 
-If you find no `AGENTS.md` at all (neither in cwd nor up the tree), warn the user that the project was likely set up before v3.2 and tell them to run `ba-toolkit init --name "..." --slug {slug}` to scaffold the per-project `AGENTS.md`. Do not create one yourself with arbitrary structure.
+If you find no `AGENTS.md` at all, warn the user that the project was likely not scaffolded with `ba-toolkit init` and tell them to run it. Do not create one yourself with arbitrary structure.
 
 If the existing `AGENTS.md` predates v3.2 and has no `/discovery` row in its Pipeline Status table, prepend a new row at stage `0` (and renumber the existing `/principles` row to `0a`) — same convention used by `/research` at stage `7a`. Mention the migration in your reply so the user knows their AGENTS.md was updated.
 

package/skills/principles/SKILL.md

@@ -40,10 +40,9 @@ If `01_brief_*.md` already exists, extract the slug and domain from it. Otherwis
 2. NFR baseline — which **ISO/IEC 25010** quality characteristics are mandatory beyond the domain defaults? (Performance Efficiency / Reliability / Security / Compatibility / Usability / Maintainability / Portability / Functional Suitability — `/nfr` reads this list verbatim and treats it as a checklist).
 3. Definition of Ready — any project-specific acceptance criteria for finalizing an artifact beyond the `v3.7.0+` baseline DoR per artifact type listed in §4 below? (e.g., stakeholder sign-off, specific review steps).
 4. Quality gate — at what severity level should `/analyze` findings block `/done`? (default: CRITICAL only)
-5. Output folder structure — save all artifacts flat in the output directory (default), or inside a `{slug}/` subfolder? (useful when managing multiple projects side by side)
-6. **Testing strategy** — TDD (tests before implementation), tests-after, integration-only, manual-only, none? Drives whether `/implement-plan` task templates embed "Tests to write first" blocks. **Recommended:** TDD for production-grade systems; tests-after for prototypes; manual-only or none for spike work. *(This is the principles-based approach to the testing-discipline question that batch 6 item 2 surfaced — the right place to declare a testing strategy is here, not as a separate skill.)*
-7. **Stakeholder decision authority** — who has sign-off authority on changes to these principles? Captured by name and role. Without this, principle changes become contentious mid-project.
-8. **Code review and branching policy** — trunk-based / GitFlow / GitHub flow? Required reviewers per PR? `/implement-plan` and downstream skills assume one of these defaults but the principles file is the source of truth.
+5. **Testing strategy** — TDD (tests before implementation), tests-after, integration-only, manual-only, none? Drives whether `/implement-plan` task templates embed "Tests to write first" blocks. **Recommended:** TDD for production-grade systems; tests-after for prototypes; manual-only or none for spike work. *(This is the principles-based approach to the testing-discipline question that batch 6 item 2 surfaced — the right place to declare a testing strategy is here, not as a separate skill.)*
+6. **Stakeholder decision authority** — who has sign-off authority on changes to these principles? Captured by name and role. Without this, principle changes become contentious mid-project.
+7. **Code review and branching policy** — trunk-based / GitFlow / GitHub flow? Required reviewers per PR? `/implement-plan` and downstream skills assume one of these defaults but the principles file is the source of truth.
 
 **Note:** Artifact language is **not** an interview topic — it is detected automatically from the user's first message and recorded in `## 1. Artifact Language` of the generated file. The user can override it later by re-running `/principles`.
 
@@ -157,13 +156,7 @@ For `/analyze` findings — action required before `/done` at the current step:
 - **MEDIUM:** documented and may be deferred.
 - **LOW:** informational only.
 
-## 7. Output Folder Structure
-
-**Mode:** {flat | subfolder}
-
-_(flat = all artifacts in the output directory root; subfolder = all artifacts under `{output_dir}/{slug}/`)_
-
-## 8. Project-Specific Notes
+## 7. Project-Specific Notes
 
 {any_additional_conventions_from_interview}
 ```

package/skills/references/templates/principles-template.md

@@ -165,14 +165,7 @@ For `/analyze` findings:
 - **MEDIUM:** documented and may be deferred.
 - **LOW:** informational only.
 
-## 7. Output Folder Structure
-
-**Mode:** [flat | subfolder]
-
-- `flat` (default) — all artifacts saved directly in the output directory.
-- `subfolder` — all artifacts saved under `{output_dir}/[SLUG]/`.
-
-## 8. Testing Strategy
+## 7. Testing Strategy
 
 **Strategy:** TDD | Tests-after | Integration-only | Manual-only | None
 
@@ -186,13 +179,13 @@ For `/analyze` findings:
 
 `/implement-plan` reads this section to decide whether to embed test specifications in each task. Default is **TDD** for production-grade systems.
 
-## 9. Code Review and Branching
+## 8. Code Review and Branching
 
 **Branching model:** trunk-based | GitHub flow | GitFlow | other
 **Required reviewers per PR:** [N]
 **Merge gate:** [CI green + N reviews / CODEOWNERS approval / specific reviewer]
 
-## 10. Stakeholder Decision Authority
+## 9. Stakeholder Decision Authority
 
 Who can approve a change to these principles, and to which sections.
 
@@ -204,11 +197,10 @@ Who can approve a change to these principles, and to which sections.
 | §4 Definition of Ready | [Role] | |
 | §5 NFR Baseline | [Role] | |
 | §6 Quality Gates | [Role] | |
-| §7 Output Structure | [Role] | |
-| §8 Testing Strategy | [Role] | |
-| §9 Branching | [Role] | |
+| §7 Testing Strategy | [Role] | |
+| §8 Branching | [Role] | |
 
-## 11. Project-Specific Notes
+## 10. Project-Specific Notes
 
 [ADDITIONAL_CONVENTIONS]
 

package/skills/srs/SKILL.md

@@ -118,9 +118,9 @@ FR numbering: sequential within each feature area, three-digit, with reserved ra
 
 ## AGENTS.md update
 
-After `/done`, find the project's `AGENTS.md` (look in cwd first; fall back to walking up the directory tree for legacy v3.0 single-project layouts). **Update only the `## Pipeline Status` row for `/srs`** — toggle its status from `⬜ Not started` to `✅ Done` and fill in the artifact filename (`02_srs_{slug}.md`) in the `File` column. **Do not touch the managed block** (`<!-- ba-toolkit:begin managed -->` … `<!-- ba-toolkit:end managed -->`) — that's owned by `ba-toolkit init`. **Do not add `## Artifacts` / `## Key context` sections** — those are not part of the v3.1+ template.
+After `/done`, find the project's `AGENTS.md` (look in cwd first; if cwd is `output/`, check `../AGENTS.md`). **Update only the `## Pipeline Status` row for `/srs`** — toggle its status from `⬜ Not started` to `✅ Done` and fill in the artifact filename (`02_srs_{slug}.md`) in the `File` column. **Do not touch the managed block** (`<!-- ba-toolkit:begin managed -->` … `<!-- ba-toolkit:end managed -->`) — that's owned by `ba-toolkit init`.
 
-If you find no `AGENTS.md` at all, warn the user that the project was likely set up before v3.1 and tell them to run `ba-toolkit init --name "..." --slug {slug}` to scaffold the per-project file. Do not create one yourself with arbitrary structure.
+If you find no `AGENTS.md` at all, warn the user that the project was likely not scaffolded with `ba-toolkit init` and tell them to run it. Do not create one yourself with arbitrary structure.
 
 ## Iterative refinement