sdtk-kit 0.3.8 → 1.0.0

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

@@ -1,63 +0,0 @@
----
-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

@@ -1,52 +0,0 @@
----
-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

@@ -1,48 +0,0 @@
----
-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
-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 are 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 are not met, report which gate is missing and 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 are 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. Keep the structured TEST_CASE total consistent with the release-report baseline; track E2E separately if needed.
-4. Apply `governance/ai/core/SDTK_BENCHMARK_QA_MODE_POLICY.md` for benchmark-mode verdict rules when no executable build exists.
-5. If acceptance criteria / expected behavior is unclear, record OQ-xx in QA report and preserve benchmark-expected ambiguity per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`; escalate to PM.
-6. Execute/record results (unit/integration/e2e as applicable).
-7. Record defects with severity and status.
-8. Decide: APPROVED vs REJECTED (with reasons).
-9. Update shared state + Phase 5 checklist.
-10. Handoff: suggest user run `/pm` to finalize release status if approved.

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

@@ -1,68 +0,0 @@
----
-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

@@ -1,61 +0,0 @@
----
-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.
-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` and keep benchmark-expected OQs explicitly OPEN per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`.
-
-## 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)` with UT total, IT total, and 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
-   - structured TEST_CASE total stays aligned with the QA release-report baseline; if E2E is tracked separately, label it separately instead of inflating grand total
-   - 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/QUALITY_CHECKLIST.md

@@ -1,124 +0,0 @@
-# QUALITY CHECKLIST
-## Multi-Agent Development Pipeline Gates (v2.1 - 6 Phases)
-
-**Current Feature:** `{{FEATURE_KEY}}`
-**Last Updated:** `{{DATETIME}}`
-**Overall Status:** `PHASE 1 PM INITIATION - IN PROGRESS`
-
----
-
-## PHASE 1: PM INITIATION (Project Kickoff) CHECKLIST
-
-| # | Criteria | Status | Verified By | Notes/Issues | Date |
-|---|----------|--------|-------------|--------------|------|
-| 1 | Requirements received from stakeholders | [ ] Pending | PM Agent | | |
-| 2 | Business problem clearly defined | [ ] Pending | PM Agent | | |
-| 3 | High-level scope documented (REQ-xx) + Open Questions (OQ-xx) captured | [ ] Pending | PM Agent | | |
-| 4 | Stakeholders identified | [ ] Pending | PM Agent | | |
-| 5 | Success criteria defined (measurable) | [ ] Pending | PM Agent | | |
-| **6** | **PM INITIATION COMPLETE** | [ ] Pending | **PM Gate** | **@ba please analyze** | |
-
----
-
-## PHASE 2: BA (Business Analysis) CHECKLIST
-
-| # | Criteria | Status | Verified By | Notes/Issues | Date |
-|---|----------|--------|-------------|--------------|------|
-| 1 | Domain Glossary complete (all terms defined) | [ ] Pending | BA Agent | | |
-| 2 | Business Rules numbered and complete (BR-01...) | [ ] Pending | BA Agent | | |
-| 3 | Use Cases cover 100% requirements (UC-01...) | [ ] Pending | BA Agent | | |
-| 4 | Data entities and relationships documented | [ ] Pending | BA Agent | | |
-| 5 | Risks identified + prioritized (High/Med/Low) | [ ] Pending | BA Agent | | |
-| 6 | Open questions listed for PM/ARCH review | [ ] Pending | BA Agent | | |
-| **7** | **BA SPECS READY** | [ ] Pending | **BA Gate** | **@pm specs ready for PRD** | |
-
----
-
-## PHASE 2+: PM PLANNING CHECKLIST
-
-| # | Criteria | Status | Verified By | Notes/Issues | Date |
-|---|----------|--------|-------------|--------------|------|
-| 1 | PRD aligns 100% with BA specs + resolves/records OQ decisions | [ ] Pending | PM Agent | | |
-| 2 | Backlog 100% traceable to BA Use Cases | [ ] Pending | PM Agent | | |
-| 3 | Story priorities reflect business value (MoSCoW) | [ ] Pending | PM Agent | | |
-| 4 | Success metrics defined and measurable | [ ] Pending | PM Agent | | |
-| 5 | Release criteria objective and testable | [ ] Pending | PM Agent | | |
-| 6 | Effort estimates realistic (Fibonacci story points) | [ ] Pending | PM Agent | | |
-| **7** | **PM BACKLOG READY** | [ ] Pending | **PM Gate** | **@arch please design** | |
-
----
-
-## PHASE 3: ARCH (Solution Architecture) CHECKLIST
-
-| # | Criteria | Status | Verified By | Notes/Issues | Date |
-|---|----------|--------|-------------|--------------|------|
-| 1 | System architecture diagram complete + assumptions/OQ documented | [ ] Pending | ARCH Agent | | |
-| 2 | Database schema/ERD documented + `DATABASE_SPEC_[FEATURE_KEY].md` updated (if DB scope) | [ ] Pending | ARCH Agent | | |
-| 3 | API contract docs updated (`[FeaturePascal]_API.yaml` + `[FEATURE_KEY]_ENDPOINTS.md`) when API scope exists | [ ] Pending | ARCH Agent | | |
-| 4 | API flow list updated (`[feature_snake]_api_flow_list.txt`) when API scope exists | [ ] Pending | ARCH Agent | | |
-| 5 | API design detail updated (`[FEATURE_KEY]_API_DESIGN_DETAIL.md`) when API scope exists and mode is `auto/on` | [ ] Pending | ARCH Agent | Mode from `sdtk.config.json` | |
-| 6 | Flow-action screen spec updated (`[FEATURE_KEY]_FLOW_ACTION_SPEC.md`) when UI flow scope exists | [ ] Pending | ARCH Agent | | |
-| 7 | Screen layout spec updated (`DESIGN_LAYOUT_[FEATURE_KEY].md`) when UI scope exists | [ ] Pending | ARCH Agent | | |
-| 8 | Security model documented (auth/authz) | [ ] Pending | ARCH Agent | | |
-| **9** | **ARCH DESIGN READY** | [ ] Pending | **ARCH Gate** | **@dev please implement** | |
-
----
-
-## PHASE 4: DEV (Development + Code Review) CHECKLIST
-
-| # | Criteria | Status | Verified By | Notes/Issues | Date |
-|---|----------|--------|-------------|--------------|------|
-| 1 | Implementation Plan matches ARCH design + backlog + clarifications logged (OQ-xx) | [ ] Pending | Dev Agent | | |
-| 2 | **Unit Tests:** coverage meets target | [ ] Pending | Dev Agent | | |
-| 3 | **Integration Tests:** critical flows covered | [ ] Pending | Dev Agent | | |
-| 4 | Linting and type checking passes | [ ] Pending | Dev Agent | | |
-| 5 | Security checklist passed | [ ] Pending | Dev Agent | | |
-| 6 | Performance baseline established | [ ] Pending | Dev Agent | | |
-| 7 | **Self Code Review:** Complete | [ ] Pending | Dev Agent | MANDATORY | |
-| 8 | **Peer Code Review:** Requested | [ ] Pending | Dev Agent | MANDATORY (AI allowed) | |
-| 9 | **Peer Code Review:** All comments addressed | [ ] Pending | Dev Agent | MANDATORY (AI allowed) | |
-| **10** | **DEV READY FOR QA** | [ ] Pending | **Dev Gate** | **Code Review [x] then @qa please test** | |
-
----
-
-## PHASE 5: QA (Quality Assurance) CHECKLIST
-
-| # | Criteria | Status | Verified By | Notes/Issues | Date |
-|---|----------|--------|-------------|--------------|------|
-| 1 | Test Strategy covers all critical paths + unclear ACs escalated (OQ-xx) | [ ] Pending | QA Agent | | |
-| 2 | Test case specification updated (`[FEATURE_KEY]_TEST_CASE.md`) when detailed test design scope exists | [ ] Pending | QA Agent | | |
-| 3 | **E2E Tests:** P1 flows PASS (if applicable) | [ ] Pending | QA Agent | | |
-| 4 | **Defects:** 0 HIGH severity open | [ ] Pending | QA Agent | | |
-| 5 | **Coverage:** meets targets | [ ] Pending | QA Agent | | |
-| 6 | No flaky tests | [ ] Pending | QA Agent | | |
-| 7 | Performance meets NFRs | [ ] Pending | QA Agent | | |
-| 8 | Release Report complete | [ ] Pending | QA Agent | | |
-| **9** | **QA APPROVED** | [ ] Pending | **QA Gate** | **@pm please finalize release status** | |
-
----
-
-## PHASE 6: PM CLOSURE CHECKLIST
-
-| # | Criteria | Status | Verified By | Notes/Issues | Date |
-|---|----------|--------|-------------|--------------|------|
-| 1 | QA release decision reviewed by PM | [ ] Pending | PM Agent | | |
-| 2 | Outstanding OQ/risks triaged for next iteration | [ ] Pending | PM Agent | | |
-| 3 | Final status communicated to stakeholders | [ ] Pending | PM Agent | | |
-| **4** | **FEATURE CLOSURE COMPLETE** | [ ] Pending | **PM Gate** | **Pipeline complete** | |
-
----
-
-## FINAL RELEASE GATE
-
-```
-RELEASE STATUS: IN PROGRESS
-
-FINAL VERIFICATION:
-[ ] Phase 1 PM Init
-[ ] Phase 2 BA
-[ ] Phase 2+ PM Plan
-[ ] Phase 3 ARCH
-[ ] Phase 4 DEV + Code Review
-[ ] Phase 5 QA
-[ ] Phase 6 PM Closure
-```

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

@@ -1,63 +0,0 @@
-# Templates (SDTK)
-
-Files in `toolkit/templates/` are skeleton artifacts used by `init-feature.ps1`
-to bootstrap a new feature across the SDLC phases.
-
-**Note:** These templates produce *scaffold* files with TBD placeholders.
-The scaffolds define the document structure for each SDLC phase. Content is
-expected to be filled in by human authors or AI agents working through the
-6-phase pipeline (PM Init -> BA -> PM Planning -> ARCH -> DEV -> QA).
-See `SHARED_PLANNING.md` (generated) for the phase pipeline tracker.
-
-## Tokens
-- `{{FEATURE_KEY}}` (UPPER_SNAKE_CASE), example: `WORKFLOW_ENGINE`
-- `{{FEATURE_NAME}}`, example: `Workflow Engine`
-- `{{FEATURE_PASCAL}}`, example: `WorkflowEngine`
-- `{{FEATURE_SNAKE}}` (lower_snake_case), example: `workflow_engine`
-- `{{DATE}}` format: `YYYY-MM-DD`
-- `{{DATETIME}}` format: `YYYY-MM-DD HH:mm`
-
-## Generate
-Run from project root:
-
-`powershell -ExecutionPolicy Bypass -File ".\\toolkit\\\scripts\\init-feature.ps1" -FeatureKey YOUR_FEATURE -FeatureName "Your Feature"`
-
-The script renders templates into `docs/**` and updates:
-- `SHARED_PLANNING.md`
-- `QUALITY_CHECKLIST.md`
-
-## Stack Configuration
-- Stack and command values come from `sdtk.config.json` (project root).
-- `init-feature.ps1` reads config values and injects them into templates.
-
-## Added Architecture Outputs
-- `docs/api/[FEATURE_KEY]_ENDPOINTS.md`
-- `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md`
-- `docs/database/DATABASE_SPEC_[FEATURE_KEY].md`
-- `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
-
-## Added QA Outputs
-- `docs/qa/[FEATURE_KEY]_TEST_CASE.md`
-- `docs/qa/QA_RELEASE_REPORT_[FEATURE_KEY].md`
-
-## ARCH Orchestration Mapping
-- API scope: use `sdtk-api-doc`.
-- API detail scope (from YAML + flow list): use `sdtk-api-design-spec` (mode `apiDesignDetailMode: auto|on|off`).
-- UI flow-action scope: use `sdtk-screen-design-spec`.
-
-## QA Orchestration Mapping
-- QA release decision/report scope: use `sdtk-qa`.
-- QA detailed test-case spec scope: use `sdtk-test-case-spec` (mode `testCaseSpecMode: auto|on|off`).
-
-## 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:
-  - `templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md`
-  - 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`

package/assets/toolkit/toolkit/templates/SHARED_PLANNING.md

@@ -1,80 +0,0 @@
-# SHARED PLANNING DOCUMENT
-## Multi-Agent Development Pipeline Tracker (v2.1 - 6 Phases)
-
-**Current Feature:** `{{FEATURE_KEY}}`
-**Feature Name:** `{{FEATURE_NAME}}`
-**Last Updated:** `{{DATETIME}}`
-**Pipeline Status:** `PHASE 1 - PM INITIATION (IN PROGRESS)`
-
----
-
-## PIPELINE STATUS TABLE (6 Phases)
-
-| Phase | Status | Owner | Start Date | Finish Date | Primary Artifact | Secondary Artifacts | Notes/Blockers |
-|-------|--------|-------|------------|-------------|------------------|-------------------|---------------|
-| **1. PM Init** | IN_PROGRESS | `@pm` | {{DATE}} | - | `PROJECT_INITIATION_{{FEATURE_KEY}}.md` | Scope + REQ-xx | |
-| **2. BA** | Pending | `@ba` | - | - | `BA_SPEC_{{FEATURE_KEY}}.md` | BR/UC/AC/NFR | |
-| **2+. PM Plan** | Pending | `@pm` | - | - | `PRD_{{FEATURE_KEY}}.md` | `BACKLOG_{{FEATURE_KEY}}.md` | |
-| **3. ARCH** | Pending | `@arch` | - | - | `ARCH_DESIGN_{{FEATURE_KEY}}.md` | API + API_DETAIL + DB + UI specs | |
-| **4. Dev** | Pending | `@dev` | - | - | `FEATURE_IMPL_PLAN_{{FEATURE_KEY}}.md` | Code + Tests + Code Review | |
-| **5. QA** | Pending | `@qa` | - | - | `QA_RELEASE_REPORT_{{FEATURE_KEY}}.md` | `{{FEATURE_KEY}}_TEST_CASE.md` + Test results | |
-| **6. PM Closure** | Pending | `@pm` | - | - | Release decision recorded | Handoff complete | |
-
----
-
-## VISUAL PIPELINE STATUS
-```
-[PM Init] IN_PROGRESS --> [BA] PENDING --> [PM Plan] PENDING --> [ARCH] PENDING --> [Dev] PENDING --> [QA] PENDING --> [PM Closure] PENDING
-```
-
----
-
-## ARTIFACTS LOCATION GUIDE
-
-```
-PM OUTPUTS:          docs/product/PROJECT_INITIATION_{{FEATURE_KEY}}.md
-                     docs/product/PRD_{{FEATURE_KEY}}.md
-                     docs/product/BACKLOG_{{FEATURE_KEY}}.md
-BA OUTPUTS:          docs/specs/BA_SPEC_{{FEATURE_KEY}}.md
-ARCH OUTPUTS:        docs/architecture/ARCH_DESIGN_{{FEATURE_KEY}}.md
-                     docs/api/{{FEATURE_PASCAL}}_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/specs/{{FEATURE_KEY}}_FLOW_ACTION_SPEC.md
-                     docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md
-DEV OUTPUTS:         docs/dev/FEATURE_IMPL_PLAN_{{FEATURE_KEY}}.md
-QA OUTPUTS:          docs/qa/{{FEATURE_KEY}}_TEST_CASE.md
-                     docs/qa/QA_RELEASE_REPORT_{{FEATURE_KEY}}.md
-SHARED STATE:        SHARED_PLANNING.md + QUALITY_CHECKLIST.md
-```
-
----
-
-## CURRENT BLOCKERS / ISSUES
-```
-NO BLOCKERS
-```
-
----
-
-## OPEN QUESTIONS (Summary)
-List any unresolved OQ-xx items here with a pointer to the owning artifact (PM consolidates).
-
-| Q-ID | Summary | Owner | Source Doc | Status |
-|------|---------|-------|------------|--------|
-| OQ-01 | TBD | PM | docs/specs/BA_SPEC_{{FEATURE_KEY}}.md | OPEN |
-
----
-
-## RECENT ACTIVITY LOG (Agent Updates)
-
-```
-{{DATETIME}} | [SYSTEM] | INIT | Toolkit initialized for {{FEATURE_KEY}} | @pm please create PROJECT_INITIATION
-```
-
-**Append updates with format:**
-```
-YYYY-MM-DD HH:MM | [PM/BA/ARCH/DEV/QA] | [Status] | [Artifact] | @next_agent
-```

package/assets/toolkit/toolkit/templates/docs/api/API_DESIGN_CREATION_RULES.md

@@ -1,22 +0,0 @@
-# API DESIGN CREATION RULES (Compatibility Note)
-
-This file is kept only for backward compatibility.
-
-Do not use this file as the primary source of truth anymore.
-The active rule source for API design detail and API flowchart behavior is now:
-- `API_DESIGN_FLOWCHART_CREATION_RULES_FINAL.md` (root)
-- `templates/docs/api/API_DESIGN_FLOWCHART_CREATION_RULES.md` (toolkit)
-
-Even in compatibility mode, generated API design detail docs must still include:
-- a top-level `## Assumptions` section
-- this table format: `| # | Assumption | Verified | Risk if wrong |`
-- explicit unresolved assumptions when downstream review depends on them
-
-Use the active rule file for:
-- API design detail markdown structure
-- flowchart integration and synchronization rules
-- error section rules
-- flow summary / notes / login rules
-- assumptions-section requirements
-
-This compatibility note should remain only until all references are migrated.

package/assets/toolkit/toolkit/templates/docs/api/API_DESIGN_DETAIL_TEMPLATE.md

@@ -1,67 +0,0 @@
-# {{FEATURE_KEY}} API DESIGN DETAIL
-
-## 0. Abbreviations
-
-| No | Term | Meaning |
-| ---: | --- | --- |
-| 1 | API | Application Programming Interface |
-| 2 | UUID | Universally Unique Identifier |
-| 3 | FE | Frontend |
-| 4 | BE | Backend |
-| 5 | DT | Datetime |
-
-## 1. Document Scope
-
-| No | Method | Endpoint | Reference Template |
-| ---: | --- | --- | --- |
-| 1 | TBD | TBD | `API_design.xlsx` |
-
-## Assumptions
-
-| # | Assumption | Verified | Risk if wrong |
-| ---: | --- | --- | --- |
-| 1 | TBD | No | TBD |
-
-## 2. API Detail 1 - TBD
-
-**Endpoint:** `TBD`
-
-### 2.1 Process Flow
-
-Source of truth: `docs/api/{{FEATURE_SNAKE}}_api_flow_list.txt`
-
-```text
-@startuml
-partition "TBD" {
-start
-:TBD;
-stop
-}
-@enduml
-```
-
-![Flowchart - API 1](./images/{{FEATURE_SNAKE}}__api_1.svg)
-
-### 2.2 Parameters
-
-`None`
-
-### 2.3 Request Parameters (JSON format)
-
-`None`
-
-### 2.4 Success Response (JSON format)
-
-`None`
-
-### 2.5 Error Response (JSON format)
-
-`None`
-
-## 3. Generation Notes
-
-- This file should be generated/updated by skill `sdtk-api-design-spec`.
-- Rules source: `templates/docs/api/API_DESIGN_FLOWCHART_CREATION_RULES.md`.
-- Contract source:
-  - `docs/api/{{FEATURE_PASCAL}}_API.yaml`
-  - `docs/api/{{FEATURE_SNAKE}}_api_flow_list.txt`