sdtk-kit 0.3.1 → 0.3.3

package/assets/toolkit/toolkit/skills-claude/arch/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: arch
+description: Solution Architect workflow for SDTK. Use when you need to convert BA_SPEC + PM backlog into technical architecture, API contracts (OpenAPI), and UI layout docs; update SHARED_PLANNING.md / QUALITY_CHECKLIST.md and handoff to DEV.
+---
+
+## SDTK Pipeline Rules (always apply)
+1. Pipeline: PM Initiation → BA Analysis → PM Planning → Architecture Design → Development + Review → QA Validation
+2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
+3. If unclear: log OQ-xx in artifact, escalate to PM (PM asks user if needed)
+4. Traceability: REQ → BR/UC/AC → design → backlog → code/tests → QA
+5. Code review must be COMPLETE before QA phase can start
+6. Do not skip phases. If inputs missing, ask focused questions.
+
+## Prerequisites (verify before proceeding)
+Read QUALITY_CHECKLIST.md and verify:
+- Phase 2 BA Analysis gate must show all items [x] Done.
+- Phase 2+ PM Planning gate must show all items [x] Done.
+
+If prerequisites NOT met: report which gate is missing, suggest user run the prerequisite phase first.
+
+## Current Context
+- Config: !`node -e "try{process.stdout.write(require('fs').readFileSync('sdtk.config.json','utf8'))}catch{process.stdout.write('{}')}"`
+- Pipeline: !`node -e "try{process.stdout.write(require('fs').readFileSync('SHARED_PLANNING.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- Gates: !`node -e "try{process.stdout.write(require('fs').readFileSync('QUALITY_CHECKLIST.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- State: !`node -e "try{process.stdout.write(require('fs').readFileSync('.sdtk/orchestration-state.json','utf8'))}catch{process.stdout.write('{}')}"`
+
+## Input
+$ARGUMENTS
+
+If no arguments provided, read current feature context from SHARED_PLANNING.md.
+
+# SDTK ARCH (Solution Architecture)
+
+## Outputs
+- `docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md`
+- If applicable:
+  - `docs/api/[FeaturePascal]_API.yaml`
+  - `docs/api/[FEATURE_KEY]_ENDPOINTS.md`
+  - `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md`
+  - `docs/api/[feature_snake]_api_flow_list.txt`
+  - `docs/database/DATABASE_SPEC_[FEATURE_KEY].md`
+  - `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`
+  - `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
+
+## Process
+1. Read BA spec + PRD/backlog.
+2. Read `sdtk.config.json` for project stack assumptions (backend/frontend/db/auth).
+3. If architecture output includes API contracts/flows, read and apply the split API rule sources before defining endpoints/flows:
+   - `.claude/skills/references/YAML_CREATION_RULES.md`
+   - `.claude/skills/references/API_DESIGN_FLOWCHART_CREATION_RULES.md`
+4. If architecture output includes screen flow-action specs, read and apply rules from `.claude/skills/references/FLOW_ACTION_SPEC_CREATION_RULES.md` (global numbering policy).
+5. If API detail spec is required, use skill `/api-design-spec` to build/update `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md` using YAML + flow list.
+6. For complex UI flow-action specs, use skill `/screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
+7. Define:
+   - System components + data model
+   - API endpoints and flows (if backend changes)
+   - Screen layouts (if UI changes)
+   - Security/authz decisions
+8. Create/update:
+   - OpenAPI YAML + API endpoint markdown
+   - API flow list
+   - API design detail spec (when `orchestration.apiDesignDetailMode` is `auto/on`)
+   - Database spec (if DB impact exists)
+   - Flow-action spec and design layout (if UI impact exists)
+9. Ensure mapping UC/BR -> DB/API/screens and run output hygiene checks:
+   - EN artifacts use English narrative text (except clearly marked original-language appendix blocks).
+   - No mojibake/encoding corruption in markdown/yaml/txt outputs.
+10. If anything is unclear: record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to PM (suggest user run `/pm` for a decision if still missing info).
+11. Update shared state + Phase 3 checklist.
+12. Handoff: suggest user run `/dev` to implement the design.

package/assets/toolkit/toolkit/skills-claude/ba/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: ba
+description: Business Analyst workflow for SDTK. Use when you need to turn PM initiation into BA_SPEC with glossary, business rules (BR-xx), use cases (UC-xx), acceptance criteria (AC-xx), NFRs, risks, open questions, and a traceability matrix.
+---
+
+## SDTK Pipeline Rules (always apply)
+1. Pipeline: PM Initiation → BA Analysis → PM Planning → Architecture Design → Development + Review → QA Validation
+2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
+3. If unclear: log OQ-xx in artifact, escalate to PM (PM asks user if needed)
+4. Traceability: REQ → BR/UC/AC → design → backlog → code/tests → QA
+5. Code review must be COMPLETE before QA phase can start
+6. Do not skip phases. If inputs missing, ask focused questions.
+
+## Prerequisites (verify before proceeding)
+Read QUALITY_CHECKLIST.md and verify:
+- Phase 1 PM Init gate must show all items [x] Done.
+
+If prerequisites NOT met: report which gate is missing, suggest user run `/pm` first.
+
+## Current Context
+- Config: !`node -e "try{process.stdout.write(require('fs').readFileSync('sdtk.config.json','utf8'))}catch{process.stdout.write('{}')}"`
+- Pipeline: !`node -e "try{process.stdout.write(require('fs').readFileSync('SHARED_PLANNING.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- Gates: !`node -e "try{process.stdout.write(require('fs').readFileSync('QUALITY_CHECKLIST.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- State: !`node -e "try{process.stdout.write(require('fs').readFileSync('.sdtk/orchestration-state.json','utf8'))}catch{process.stdout.write('{}')}"`
+
+## Input
+$ARGUMENTS
+
+If no arguments provided, read current feature context from SHARED_PLANNING.md.
+
+# SDTK BA (Business Analysis)
+
+## Output
+- `docs/specs/BA_SPEC_[FEATURE_KEY].md`
+
+## Process
+1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` (and any source requirements).
+2. Produce:
+   - Glossary
+   - BR-xx (numbered)
+   - UC-xx (cover 100% REQ-xx)
+   - AC-xx (mapped to UC/BR)
+   - NFR-xx
+   - Risks + Open Questions
+   - Traceability summary table (REQ → UC/BR/AC)
+3. If source requirements are VI/JP: preserve the original text and add a literal EN translation in appendices.
+4. If anything is unclear: record OQ-xx in BA_SPEC "Open Questions" and escalate to PM (suggest user run `/pm` for a decision if still missing info).
+5. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 2.
+6. Handoff: suggest user run `/pm` to proceed with PRD planning.

package/assets/toolkit/toolkit/skills-claude/design-layout/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: design-layout
+description: Generate UI screen layout documentation for a feature, including PlantUML @startsalt wireframes and item tables. Use when a feature includes frontend/admin screens and you need docs/design/* deliverables.
+---
+
+## Required Inputs (read before proceeding)
+Read the following artifacts for the current feature:
+1. `docs/specs/BA_SPEC_*.md` — screens + fields
+2. `docs/api/[FEATURE_KEY]_ENDPOINTS.md` — API list
+
+## Input
+$ARGUMENTS
+
+# SDTK Screen Layout Design
+
+## Output
+- `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`
+
+## Process
+1. Read BA spec (screens + fields) and API list.
+2. For each screen, include:
+   - PlantUML `@startsalt` wireframe first
+   - API list table
+   - Item table with numbering that matches the wireframe
+3. Keep screen IDs consistent (A-*, B-*, C-*).

package/assets/toolkit/toolkit/skills-claude/dev/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: dev
+description: Developer workflow for SDTK. Use when you need to implement a feature from ARCH_DESIGN + BACKLOG: create an implementation plan, write code + tests, complete mandatory code review gate, and prepare a QA handoff.
+---
+
+## SDTK Pipeline Rules (always apply)
+1. Pipeline: PM Initiation → BA Analysis → PM Planning → Architecture Design → Development + Review → QA Validation
+2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
+3. If unclear: log OQ-xx in artifact, escalate to PM (PM asks user if needed)
+4. Traceability: REQ → BR/UC/AC → design → backlog → code/tests → QA
+5. Code review must be COMPLETE before QA phase can start
+6. Do not skip phases. If inputs missing, ask focused questions.
+
+## Prerequisites (verify before proceeding)
+Read QUALITY_CHECKLIST.md and verify:
+- Phase 3 ARCH Design gate must show all items [x] Done.
+
+If prerequisites NOT met: report which gate is missing, suggest user run `/arch` first.
+
+## Current Context
+- Config: !`node -e "try{process.stdout.write(require('fs').readFileSync('sdtk.config.json','utf8'))}catch{process.stdout.write('{}')}"`
+- Pipeline: !`node -e "try{process.stdout.write(require('fs').readFileSync('SHARED_PLANNING.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- Gates: !`node -e "try{process.stdout.write(require('fs').readFileSync('QUALITY_CHECKLIST.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- State: !`node -e "try{process.stdout.write(require('fs').readFileSync('.sdtk/orchestration-state.json','utf8'))}catch{process.stdout.write('{}')}"`
+
+## Input
+$ARGUMENTS
+
+If no arguments provided, read current feature context from SHARED_PLANNING.md.
+
+# SDTK DEV (Implementation + Code Review)
+
+## Outputs
+- `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md`
+- Code + tests (follow repo conventions)
+
+## Process
+1. Read `ARCH_DESIGN_*` + backlog.
+2. Read `sdtk.config.json` for project stack + test/lint commands.
+3. Write `FEATURE_IMPL_PLAN_*` (scope, file list, test plan).
+4. If anything is unclear: record OQ-xx in FEATURE_IMPL_PLAN "Open Questions" and escalate to PM (suggest user run `/pm` for a decision if still missing info).
+5. Implement incrementally with tests.
+6. Complete mandatory code review gate (self + peer checklist; AI peer review allowed).
+7. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 4.
+8. Handoff: suggest user run `/qa` to test (only after code review PASS).

package/assets/toolkit/toolkit/skills-claude/dev-backend/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: dev-backend
+description: Generate/modify Python Django REST Framework backend code following the toolkit conventions (models/views/services/serializers/validation/urls/enums). Use when implementing backend features in that project style.
+---
+
+## Input
+$ARGUMENTS
+
+# SDTK Backend (Toolkit conventions)
+
+## Process
+1. Check whether this repository already has a backend reference module and follow its patterns.
+2. Follow module structure: `src/backend/<module>/{models,view,service,serializers,validation,enum,urls.py}`.
+3. Apply conventions:
+   - Soft delete via `del_flg`
+   - Audit fields (creator/updater/del timestamps)
+   - Permission checks before operations
+   - `transaction.atomic()` for writes
+   - Logging decorator on public endpoints
+4. Add tests for critical business rules and state transitions.

package/assets/toolkit/toolkit/skills-claude/dev-frontend/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: dev-frontend
+description: Generate/modify React frontend code following the toolkit conventions (list/register/edit/detail pages, components, services, React Query hooks, permission checks). Use when implementing frontend features in that project style.
+---
+
+## Input
+$ARGUMENTS
+
+# SDTK Frontend (Toolkit conventions)
+
+## Process
+1. Check whether this repository already has a frontend reference module and follow its patterns.
+2. Follow structure:
+   - `src/frontend/features/{feature}/...`
+   - `src/frontend/services/{feature}/{feature}Service.js`
+   - `src/frontend/services/apiHook/{feature}.js`
+3. Implement screens based on `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`.
+4. Preserve patterns: React Query hooks, loading states, permission checks, consistent labels.

package/assets/toolkit/toolkit/skills-claude/orchestrator/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: orchestrator
+description: Orchestrate a full 6-phase SDLC multi-agent workflow (PM/BA/ARCH/DEV/QA) using this repo's conventions: SHARED_PLANNING.md + QUALITY_CHECKLIST.md + docs/* artifacts + phase handoffs.
+---
+
+## SDTK Pipeline Rules (always apply)
+1. Pipeline: PM Initiation → BA Analysis → PM Planning → Architecture Design → Development + Review → QA Validation
+2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
+3. If unclear: log OQ-xx in artifact, escalate to PM (PM asks user if needed)
+4. Traceability: REQ → BR/UC/AC → design → backlog → code/tests → QA
+5. Code review must be COMPLETE before QA phase can start
+6. Do not skip phases. If inputs missing, ask focused questions.
+
+## Current Context
+- Config: !`node -e "try{process.stdout.write(require('fs').readFileSync('sdtk.config.json','utf8'))}catch{process.stdout.write('{}')}"`
+- Pipeline: !`node -e "try{process.stdout.write(require('fs').readFileSync('SHARED_PLANNING.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- Gates: !`node -e "try{process.stdout.write(require('fs').readFileSync('QUALITY_CHECKLIST.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- State: !`node -e "try{process.stdout.write(require('fs').readFileSync('.sdtk/orchestration-state.json','utf8'))}catch{process.stdout.write('{}')}"`
+
+## Input
+$ARGUMENTS
+
+If no arguments provided, read current feature context from SHARED_PLANNING.md.
+
+# SDTK Orchestrator (multi-agent workflow)
+
+## Initialize
+- Ensure feature key + feature name exist (ask if missing).
+- Read `sdtk.config.json` (project stack + commands) if present.
+- Run `sdtk generate --feature-key <KEY> --feature-name "<NAME>"` to create skeleton artifacts.
+
+## Execute pipeline (one phase per turn)
+- Default role: PM (entry point) if user did not specify.
+- Respect role tags: `/pm`, `/ba`, `/arch`, `/dev`, `/qa`.
+- For each phase:
+  - Create/update the phase artifact(s) in `docs/`.
+  - If phase is ARCH and API contract/flow is in scope, invoke `/api-doc` to produce/update `docs/api/[FeaturePascal]_API.yaml`, `docs/api/[FEATURE_KEY]_ENDPOINTS.md`, and `docs/api/[feature_snake]_api_flow_list.txt`.
+  - If phase is ARCH and API detail spec is in scope, invoke `/api-design-spec` to produce/update `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md`.
+  - If phase is ARCH and UI flow behavior is in scope, invoke `/screen-design-spec` to produce/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
+  - If phase is QA and test-case specification is in scope, invoke `/test-case-spec` to produce/update `docs/qa/[FEATURE_KEY]_TEST_CASE.md`.
+  - Update `SHARED_PLANNING.md` (phase row + activity log).
+  - Update `QUALITY_CHECKLIST.md` (mark items PASS/Pending).
+  - Produce one clear handoff message to the next role.
+
+## API design detail mode (Hybrid)
+- Read `sdtk.config.json` key: `orchestration.apiDesignDetailMode`.
+- Supported values:
+  - `auto` (default): run `/api-design-spec` when ARCH has API scope and YAML + flow list are available.
+  - `on`: always run `/api-design-spec` for API scope (fail fast if required inputs are missing).
+  - `off`: skip API design detail generation unless user explicitly requests it.
+
+## Test-case spec mode (Hybrid)
+- Read `sdtk.config.json` key: `orchestration.testCaseSpecMode`.
+- Supported values:
+  - `auto` (default): run `/test-case-spec` when QA phase requires reusable test-case artifact.
+  - `on`: always run `/test-case-spec` for QA phase (fail fast if required inputs are missing).
+  - `off`: skip test-case spec generation unless user explicitly requests it.
+
+## Guardrails
+- Do not skip phases; if prerequisites are missing, ask focused questions.
+- Keep traceability: REQ -> BR/UC/AC -> design -> backlog -> code/tests -> QA report.
+- Require code review completion before QA handoff.
+- If input requirements are VI/JP: preserve original text + add EN translation in appendix for traceability (at least in Project Initiation and BA spec).

package/assets/toolkit/toolkit/skills-claude/pm/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: pm
+description: Product Manager + meta-orchestrator workflow for SDTK. Use when you need to start a new feature (Phase 1) or produce PM planning artifacts (PRD + BACKLOG) and update SHARED_PLANNING.md / QUALITY_CHECKLIST.md with correct phase handoffs.
+---
+
+## SDTK Pipeline Rules (always apply)
+1. Pipeline: PM Initiation → BA Analysis → PM Planning → Architecture Design → Development + Review → QA Validation
+2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
+3. If unclear: log OQ-xx in artifact, escalate to PM (PM asks user if needed)
+4. Traceability: REQ → BR/UC/AC → design → backlog → code/tests → QA
+5. Code review must be COMPLETE before QA phase can start
+6. Do not skip phases. If inputs missing, ask focused questions.
+
+## Prerequisites (verify before proceeding)
+Read QUALITY_CHECKLIST.md and verify:
+- Phase 1 (PM Init): No prerequisites required.
+- Phase 2+ (PM Planning): BA Analysis gate must show all items [x] Done.
+
+If prerequisites NOT met: report which gate is missing, suggest user run the prerequisite phase first.
+
+## Current Context
+- Config: !`node -e "try{process.stdout.write(require('fs').readFileSync('sdtk.config.json','utf8'))}catch{process.stdout.write('{}')}"`
+- Pipeline: !`node -e "try{process.stdout.write(require('fs').readFileSync('SHARED_PLANNING.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- Gates: !`node -e "try{process.stdout.write(require('fs').readFileSync('QUALITY_CHECKLIST.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- State: !`node -e "try{process.stdout.write(require('fs').readFileSync('.sdtk/orchestration-state.json','utf8'))}catch{process.stdout.write('{}')}"`
+
+## Input
+$ARGUMENTS
+
+If no arguments provided, read current feature context from SHARED_PLANNING.md.
+
+# SDTK PM (Entry Point + Planning)
+
+## Outputs
+- Phase 1: `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md`
+- Phase 2+ (after BA spec): `docs/product/PRD_[FEATURE_KEY].md` + `docs/product/BACKLOG_[FEATURE_KEY].md`
+
+## Process
+1. Confirm `FEATURE_KEY` + `FEATURE_NAME` + Phase-1 scope in/out.
+2. Create/update PM artifact(s).
+3. Ensure REQ-xx list is clear and testable.
+4. If requirements are provided in VI/JP: keep the original text in an appendix and add an EN translation (literal) for traceability.
+5. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md`.
+6. Handoff:
+   - After Project Initiation -> suggest user run `/ba` to analyze requirements
+   - After PRD/Backlog -> suggest user run `/arch` to design architecture
+
+## Clarification And Decisions (PM responsibility)
+- Collect OQ-xx items raised by BA/ARCH/DEV/QA in their respective artifacts.
+- Try to resolve OQ-xx using existing docs and reasonable product/tech decisions.
+- If still missing information from the original input: ask the user (final stakeholder) and record the answer as the resolution.
+- Record decisions in PRD `Decision Log` and update OQ-xx `Resolution` fields in the originating docs.

package/assets/toolkit/toolkit/skills-claude/qa/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: qa
+description: QA workflow for SDTK. Use when you need to validate an implemented feature against BA/PRD/Backlog, run quality gates, document defects, and produce a QA_RELEASE_REPORT with a release decision.
+---
+
+## SDTK Pipeline Rules (always apply)
+1. Pipeline: PM Initiation → BA Analysis → PM Planning → Architecture Design → Development + Review → QA Validation
+2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
+3. If unclear: log OQ-xx in artifact, escalate to PM (PM asks user if needed)
+4. Traceability: REQ → BR/UC/AC → design → backlog → code/tests → QA
+5. Code review must be COMPLETE before QA phase can start
+6. Do not skip phases. If inputs missing, ask focused questions.
+
+## Prerequisites (verify before proceeding)
+Read QUALITY_CHECKLIST.md and verify:
+- Phase 4 DEV gate must show all items [x] Done (including code review completion).
+
+If prerequisites NOT met: report which gate is missing, suggest user run `/dev` first to complete code review.
+
+## Current Context
+- Config: !`node -e "try{process.stdout.write(require('fs').readFileSync('sdtk.config.json','utf8'))}catch{process.stdout.write('{}')}"`
+- Pipeline: !`node -e "try{process.stdout.write(require('fs').readFileSync('SHARED_PLANNING.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- Gates: !`node -e "try{process.stdout.write(require('fs').readFileSync('QUALITY_CHECKLIST.md','utf8'))}catch{process.stdout.write('Not initialized')}"`
+- State: !`node -e "try{process.stdout.write(require('fs').readFileSync('.sdtk/orchestration-state.json','utf8'))}catch{process.stdout.write('{}')}"`
+
+## Input
+$ARGUMENTS
+
+If no arguments provided, read current feature context from SHARED_PLANNING.md.
+
+# SDTK QA (Testing + Release Decision)
+
+## Output
+- `docs/qa/QA_RELEASE_REPORT_[FEATURE_KEY].md`
+- Optional (when detailed test design spec is requested):
+  - `docs/qa/[FEATURE_KEY]_TEST_CASE.md` via `/test-case-spec`
+
+## Process
+1. Validate prerequisites: DEV phase completed + code review PASS.
+2. Create test strategy mapped to UC/AC.
+3. If test-case specification artifact is required, invoke `/test-case-spec` and align counts/coverage with release testing scope.
+4. If acceptance criteria / expected behavior is unclear: record OQ-xx in QA report and escalate to PM (suggest user run `/pm` if still missing info).
+5. Execute/record results (unit/integration/e2e as applicable).
+6. Record defects with severity and status.
+7. Decide: APPROVED vs REJECTED (with reasons).
+8. Update shared state + Phase 5 checklist.
+9. Handoff: suggest user run `/pm` to finalize release status if approved.

package/assets/toolkit/toolkit/skills-claude/screen-design-spec/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: screen-design-spec
+description: Create/update screen flow-action specifications from requirement sources (Excel/Figma/spec docs), including screen flow PlantUML, UI item/action tables, API mapping tables, and screen-to-API traceability.
+---
+
+## Required Inputs (read before proceeding)
+Read the following artifacts for the current feature:
+1. `docs/specs/BA_SPEC_*.md` — business rules, use cases
+2. `docs/architecture/ARCH_DESIGN_*.md` — system components
+3. `docs/api/[FEATURE_KEY]_ENDPOINTS.md` — API endpoints (when available)
+
+## Input
+$ARGUMENTS
+
+# SDTK Screen Flow Action Spec
+
+## Outputs
+- `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
+- Optional supporting docs:
+  - `docs/specs/[FEATURE_KEY]_FIGMA_LAYOUT.md`
+  - `docs/specs/[FEATURE_KEY]_DESIGN_SPEC_FROM_EXCEL.md`
+  - `docs/specs/assets/[feature_snake]/screens/*`
+
+## Required Inputs
+- Feature key/name
+- Primary requirement sources (BA spec, architecture, customer design docs)
+- Screen source references (Figma URLs and/or requirement screenshots)
+- API endpoint source (`docs/api/[FEATURE_KEY]_ENDPOINTS.md`) when available
+
+## Process
+1. Read requirement sources and identify in-scope screens, dialogs, and transitions.
+2. Read and apply rules from `.claude/skills/references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
+3. Build/update section `Feature overview` and `Screen flow action` (PlantUML).
+4. For each screen/dialog:
+   - Add metadata (screen ID, source link)
+   - Add screen image reference
+   - Add UI item/action table with `No` column
+   - Add API mapping table (trigger -> API -> data usage)
+5. Build/update `System processing flow` from use-case and process sources.
+6. Build/update `Open questions` for unresolved behavior/API/data points.
+7. Build/update `Screen - API Mapping` summary section.
+8. Validate:
+   - global numbering consistency (no screen-level reset)
+   - no broken image paths
+   - PlantUML renderability
+   - consistency with API endpoints spec
+   - EN artifact hygiene (no VI leftovers, no mojibake, no merged heading lines)
+   - for legacy specs with per-screen reset numbering: run renumber migration first
+9. Update document history and handoff to ARCH/DEV.
+
+## Rule References
+- Core rules: `.claude/skills/references/FLOW_ACTION_SPEC_CREATION_RULES.md`
+- Numbering reference: `.claude/skills/references/numbering-rules.md`
+- Figma reference: `.claude/skills/references/figma-mcp.md`
+- Excel image export reference: `.claude/skills/references/excel-image-export.md`
+
+## Validation Script
+- `scripts/validate_flow_action_spec_numbering.py`
+  - Checks duplicate/resetted numbering in action tables.
+  - Checks encoding/markdown hygiene.
+  - For EN artifacts, run with `--en-check`:
+    - `python scripts/validate_flow_action_spec_numbering.py --spec "docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md" --en-check`
+- `scripts/renumber_flow_action_spec_global.py`
+  - Auto-migrates action table `No` fields to global numbering.
+  - Dry-run:
+    - `python scripts/renumber_flow_action_spec_global.py --spec "docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md"`
+  - Apply:
+    - `python scripts/renumber_flow_action_spec_global.py --spec "docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md" --write`

package/assets/toolkit/toolkit/skills-claude/test-case-spec/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: test-case-spec
+description: Generate screen-based QA test-case markdown in Excel-aligned layout (Statistic + per-screen UTC/ITC worksheets). Use when QA needs reusable test design artifacts before or during execution.
+---
+
+## Required Inputs (read before proceeding)
+Read the following artifacts for the current feature:
+1. `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md` — screen/flow references
+2. `docs/specs/BA_SPEC_[FEATURE_KEY].md` — business rules, use cases
+3. `docs/api/[FEATURE_KEY]_ENDPOINTS.md` — API reference
+4. `docs/specs/Q&A.md` or `docs/en/specs/Q&A.md` — clarification source (when available)
+
+## Input
+$ARGUMENTS
+
+# SDTK Test Case Spec
+
+## Outputs
+- `docs/qa/[FEATURE_KEY]_TEST_CASE.md`
+- Optional project variant:
+  - `docs/en/qa/[FEATURE_KEY]_TEST_CASE.md` (only when project uses `docs/en/**`)
+
+## Core Rules
+1. Apply `.claude/skills/references/TEST_CASE_CREATION_RULES.md` first.
+2. Keep section order fixed (Statistic -> Abbreviations -> Scope -> References -> Environment -> Coverage -> Screen-based UTC/ITC -> OQ -> STC/UAT note).
+3. Use screen-first layout to mirror worksheet structure:
+   - each screen can have `[SCREEN_KEY]_UTC` and `[SCREEN_KEY]_ITC`.
+4. Keep one unified 18-column schema for UTC/ITC rows.
+5. Keep stable case IDs; do not renumber only because of regrouping.
+6. Track unresolved decisions via `OQ-xx`.
+
+## Procedure
+1. Resolve output path:
+   - default `docs/qa/[FEATURE_KEY]_TEST_CASE.md`
+   - use `docs/en/qa/...` only if the repo already follows `docs/en/**`.
+2. Build/refresh `Statistic Summary (Excel-aligned)`:
+   - include UT total, IT total, grand total.
+3. Build `Feature Coverage Matrix` from flow/action and API docs.
+4. Split UTC/ITC by screen sections (`screen-first`), not by test type only.
+5. Fill conflict/permission/error-path cases from Q&A decisions and API contracts.
+6. Record unresolved items in section `Open Questions`.
+7. Validate:
+   - counts in summary match table rows
+   - no placeholder tokens like `??`
+   - out-of-scope boundaries are explicit
+
+## Role Integration
+- Primary owner: `/qa`.
+- `/qa` uses this skill to design/update reusable test-case specs.
+- `/qa` still owns release decision artifact (`QA_RELEASE_REPORT_*`).
+
+## Notes
+- This skill is for test-case specification artifacts, not test execution logs.
+- For release approval and defect triage, continue with `/qa`.
+
+## Validator Script
+- `scripts/validate_test_case_spec.py`
+
+### Typical command
+```bash
+python scripts/validate_test_case_spec.py \
+  --file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
+```

package/assets/toolkit/toolkit/templates/README.md

@@ -51,6 +51,9 @@ The script renders templates into `docs/**` and updates:
 
 ## Rules Used by Toolkit
 - API design/flowchart rules:
+  - `templates/docs/api/YAML_CREATION_RULES.md`
+  - `templates/docs/api/API_DESIGN_FLOWCHART_CREATION_RULES.md`
+- Compatibility notes kept for legacy references:
   - `templates/docs/api/FLOWCHART_CREATION_RULES.md`
   - `templates/docs/api/API_DESIGN_CREATION_RULES.md`
 - Screen flow-action spec rules:
@@ -58,5 +61,3 @@ The script renders templates into `docs/**` and updates:
   - Numbering mode is fixed: global numbering across full document (no screen-level reset).
 - QA test-case spec rules:
   - `templates/docs/qa/TEST_CASE_CREATION_RULES.md`
-
-