sdtk-kit 0.3.9 → 1.0.0

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

@@ -1,57 +0,0 @@
----
-name: design-layout
-description: Generate UI screen layout documentation for a feature, including PlantUML SALT wireframes and item tables. Use when a feature includes frontend or 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 and fields
-2. `docs/api/[FEATURE_KEY]_ENDPOINTS.md` - API list
-
-## Input
-$ARGUMENTS
-
-# SDTK Screen Layout Design
-
-## Critical Constraints
-- I do not skip screen IDs or item numbering alignment with the wireframe.
-- I do not hide render limitations; I record when screen preview rendering is unavailable.
-- I do not leave rendered wireframes without visible local item markers that map back to the `Items` table.
-- I do not pretend wireframe markers are the same thing as `FLOW_ACTION_SPEC` global action-table numbers.
-
-## 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, with visible screen-local markers embedded directly in the SALT labels
-   - API list table
-   - Item table whose `No` values exactly match the local marker sequence used in the wireframe for that screen
-3. Use this wireframe-marker convention so the rendered SVG can be cross-referenced visually:
-   - markers are screen-local visual references and reset per screen
-   - prefer Unicode circled-number markers in generated docs; avoid parenthetical `(N)` markers because they blend into UI text and can conflict with SALT parsing
-   - text label or input prompt: prefix the visible label with the local marker
-   - button: place the local marker inside the visible button label
-   - table header: prefix the header text with the local marker
-   - standalone control, pagination, toggle, or status chip: prefix the visible label with the local marker
-   - do not rely on prose, comments, or a separate legend; the marker must be visible inside the rendered wireframe itself
-   - the local marker does not need to equal the `FLOW_ACTION_SPEC` global `No`; `screen-design-spec` publishes the mapping table
-4. Keep screen IDs consistent (A-*, B-*, C-*).
-5. After writing `DESIGN_LAYOUT`, attempt to render screen preview images by default:
-   - Run `.claude/skills/design-layout/scripts/render_design_layout_images.py` to extract `@startsalt` blocks and render `.svg` files.
-   - Output path: `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
-   - The renderer warns if a screen wireframe has no visible local markers or still uses legacy `(N)` markers.
-   - If PlantUML is unavailable, rendering is skipped with a warning and the render-skipped note is used in `FLOW_ACTION_SPEC`.
-
-## Screen Image Renderer
-- Script: `.claude/skills/design-layout/scripts/render_design_layout_images.py`
-- Usage:
-  ```
-  python ".claude/skills/design-layout/scripts/render_design_layout_images.py" \
-    --design-layout "docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md" \
-    --feature-key [FEATURE_KEY]
-  ```
-- Requires: Java + `plantuml.jar`
-- Output: `.svg` files under `docs/specs/assets/<feature_snake>/screens/`
-- Failure policy: non-blocking. Warns and continues if rendering is unavailable.

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

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

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

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

@@ -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,90 +0,0 @@
----
-name: screen-design-spec
-description: Create or update screen flow-action specifications from requirement sources, including screen flow PlantUML, UI item 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 and 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
-
-## Critical Constraints
-- I do not finalize UI-scope screens without a valid design source type and reference.
-- I do not leave broken image paths or incomplete API mappings in the flow-action spec.
-- I use new-style PlantUML activity diagram syntax only for the screen flow diagram.
-- I do not mix legacy and new-style PlantUML activity syntax in the screen flow diagram.
-- Do not mix legacy activity syntax such as `(*)`, `-->`, or `[edge label]` with new-style activity actions like `:Activity;`.
-- I keep action-table numbering global across the document even when wireframe markers reset per screen.
-
-## 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, using one of these design source modes:
-  - `source-backed`: Figma URLs and/or requirement screenshots
-  - `generated-draft`: generated layout from `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`
-- 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. Determine design source mode per screen:
-   - If Figma URL or screenshot exists: use `source-backed`.
-   - If no Figma/screenshot but feature has UI scope: use `generated-draft` and reference the corresponding section in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`.
-   - If screen has no UI scope: use `none`.
-4. Build/update section `Feature overview` and `Screen flow action` (PlantUML).
-5. For each screen/dialog:
-   - Add metadata (screen ID, Design Source Type, Design Source Reference)
-   - Add screen image reference (from Figma, screenshot, or rendered `.svg` from generated layout)
-   - For generated-draft wireframes, add a wireframe-marker mapping table from the screen-local wireframe markers to the global action-table `No`
-   - Add UI item/action table with `No` column
-   - Add API mapping table (trigger -> API -> data usage)
-6. Build/update `System processing flow` from use-case and process sources.
-7. Build/update `Open questions` for unresolved behavior/API/data points.
-8. Build/update `Screen - API Mapping` summary section.
-9. Validate:
-   - global numbering consistency (no screen-level reset)
-   - no broken image paths (for `generated-draft` screens, verify `.svg` exists or use render-skipped note)
-   - PlantUML renderability and new-style activity syntax consistency (no `(*)`, `-->`, or `[edge label]` mixing)
-   - 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
-   - every UI-scope screen declares a Design Source Type (`source-backed` or `generated-draft`)
-   - every generated-draft screen with an embedded wireframe image includes a wireframe-marker mapping table to the global action-table `No`
-10. For `generated-draft` screens, set `Screen image:` to the rendered `.svg` path if the file exists:
-    - Expected path (filesystem): `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
-    - Markdown image path (file-relative): `assets/<feature_snake>/screens/<screen_id>.svg`
-    - If the `.svg` does not exist, replace the image reference with:
-      `> Screen image not rendered in this environment. See Design Source Reference for layout.`
-11. For generated-draft screens, treat wireframe markers as screen-local visual references:
-    - the local marker sequence may reset per screen
-    - do not renumber the wireframe to fake equality with the global action-table `No`
-    - publish the mapping table directly under the screen image so reviewers can cross-reference local markers to global action-table numbers
-12. 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
-- `.claude/skills/screen-design-spec/scripts/validate_flow_action_spec_numbering.py`
-  - `python ".claude/skills/screen-design-spec/scripts/validate_flow_action_spec_numbering.py" --spec "docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md" --en-check`
-- `.claude/skills/screen-design-spec/scripts/renumber_flow_action_spec_global.py`
-  - Dry-run:
-    - `python ".claude/skills/screen-design-spec/scripts/renumber_flow_action_spec_global.py" --spec "docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md"`
-  - Apply:
-    - `python ".claude/skills/screen-design-spec/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`