sdtk-kit 0.3.8 → 1.0.0

package/assets/toolkit/toolkit/skills/skills.catalog.yaml

@@ -1,302 +0,0 @@
-schema_version: 1
-skills:
-  - name: sdtk-pm
-    phase: pm
-    role_tag: /pm
-    use_when: Start feature scope or produce PM planning artifacts before BA or ARCH handoff.
-    primary_inputs:
-      - source requirements
-      - docs/product/PROJECT_INITIATION_[FEATURE_KEY].md
-      - docs/specs/BA_SPEC_[FEATURE_KEY].md
-    primary_outputs:
-      - docs/product/PROJECT_INITIATION_[FEATURE_KEY].md
-      - docs/product/PRD_[FEATURE_KEY].md
-      - docs/product/BACKLOG_[FEATURE_KEY].md
-    hard_gates:
-      - Do not hand off without updating SHARED_PLANNING.md and QUALITY_CHECKLIST.md.
-      - Keep unresolved OQ items explicit instead of silently deciding for other roles.
-    references: []
-    prompts: []
-    scripts: []
-    runtime_support: [claude, codex]
-    dependencies: []
-    pack: core
-
-  - name: sdtk-ba
-    phase: ba
-    role_tag: /ba
-    use_when: Convert PM initiation into a BA spec with glossary, BR, UC, AC, NFR, and traceability.
-    primary_inputs:
-      - docs/product/PROJECT_INITIATION_[FEATURE_KEY].md
-      - source requirements
-    primary_outputs:
-      - docs/specs/BA_SPEC_[FEATURE_KEY].md
-    hard_gates:
-      - Do not close BA output without explicit REQ to UC or BR or AC traceability.
-      - Keep unresolved OQ items visible for PM resolution.
-    references: []
-    prompts: []
-    scripts: []
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-pm]
-    pack: core
-
-  - name: sdtk-arch
-    phase: arch
-    role_tag: /arch
-    use_when: Convert BA spec and PM backlog into architecture, API, DB, and UI design artifacts.
-    primary_inputs:
-      - docs/specs/BA_SPEC_[FEATURE_KEY].md
-      - docs/product/PRD_[FEATURE_KEY].md
-      - docs/product/BACKLOG_[FEATURE_KEY].md
-    primary_outputs:
-      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
-      - docs/api/[FeaturePascal]_API.yaml
-      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
-      - docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md
-      - docs/database/DATABASE_SPEC_[FEATURE_KEY].md
-      - docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md
-      - docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md
-    hard_gates:
-      - For UI scope, DESIGN_LAYOUT must exist before FLOW_ACTION_SPEC.
-      - Keep API, DB, and screen outputs aligned to the same source requirements.
-    references:
-      - toolkit/skills/sdtk-arch/references/YAML_CREATION_RULES.md
-      - toolkit/skills/sdtk-arch/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
-      - toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md
-    prompts: []
-    scripts: []
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-pm, sdtk-ba]
-    pack: core
-
-  - name: sdtk-dev
-    phase: dev
-    role_tag: /dev
-    use_when: Implement a feature from approved architecture and backlog, then prepare QA handoff.
-    primary_inputs:
-      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
-      - docs/product/BACKLOG_[FEATURE_KEY].md
-      - docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md
-    primary_outputs:
-      - docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md
-      - code changes
-      - tests
-    hard_gates:
-      - Do not implement before the current FEATURE_IMPL_PLAN slice is approved.
-      - Run Stage 1 spec review before Stage 2 code-quality review.
-    references: []
-    prompts:
-      - toolkit/skills/sdtk-dev/prompts/implementer.md
-      - toolkit/skills/sdtk-dev/prompts/spec-reviewer.md
-      - toolkit/skills/sdtk-dev/prompts/code-quality-reviewer.md
-    scripts: []
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-arch]
-    pack: core
-
-  - name: sdtk-qa
-    phase: qa
-    role_tag: /qa
-    use_when: Validate implementation against specs, run quality gates, and produce a release decision.
-    primary_inputs:
-      - docs/specs/BA_SPEC_[FEATURE_KEY].md
-      - docs/product/PRD_[FEATURE_KEY].md
-      - docs/product/BACKLOG_[FEATURE_KEY].md
-      - docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md
-    primary_outputs:
-      - docs/qa/QA_RELEASE_REPORT_[FEATURE_KEY].md
-      - docs/qa/[FEATURE_KEY]_TEST_CASE.md
-    hard_gates:
-      - QA handoff is blocked until DEV Stage 1 and Stage 2 review gates PASS.
-      - Do not issue APPROVED without fresh verification evidence.
-    references: []
-    prompts: []
-    scripts: []
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-dev]
-    pack: core
-
-  - name: sdtk-orchestrator
-    phase: orchestration
-    role_tag: /orchestrator
-    use_when: Coordinate the full six-phase workflow and keep phase handoffs in order.
-    primary_inputs:
-      - feature key
-      - feature name
-      - sdtk.config.json
-      - SHARED_PLANNING.md
-      - QUALITY_CHECKLIST.md
-    primary_outputs:
-      - phase handoffs
-      - updated SHARED_PLANNING.md
-      - updated QUALITY_CHECKLIST.md
-    hard_gates:
-      - Do not skip mandatory PM or BA or ARCH or DEV or QA phases.
-      - Do not hand off the next phase without evidence from the current phase.
-    references: []
-    prompts: []
-    scripts:
-      - toolkit/scripts/init-feature.ps1
-    runtime_support: [claude, codex]
-    dependencies: []
-    pack: core
-
-  - name: sdtk-dev-backend
-    phase: dev
-    role_tag: /dev-backend
-    use_when: Implement backend code that follows SDTK backend conventions for a scoped feature slice.
-    primary_inputs:
-      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
-      - docs/api/[FeaturePascal]_API.yaml
-      - docs/database/DATABASE_SPEC_[FEATURE_KEY].md
-    primary_outputs:
-      - backend code
-      - backend tests
-    hard_gates:
-      - Do not generate backend code without approved API and data-contract sources.
-      - Follow existing repository patterns before introducing new module structure.
-    references: []
-    prompts: []
-    scripts: []
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-dev, sdtk-api-doc]
-    pack: core
-
-  - name: sdtk-dev-frontend
-    phase: dev
-    role_tag: /dev-frontend
-    use_when: Implement frontend code that follows SDTK frontend conventions for a scoped feature slice.
-    primary_inputs:
-      - docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md
-      - docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md
-      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
-    primary_outputs:
-      - frontend code
-      - frontend tests
-    hard_gates:
-      - Do not implement screens without the current design and flow-action source.
-      - Preserve existing frontend patterns before introducing new abstractions.
-    references: []
-    prompts: []
-    scripts: []
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-dev, sdtk-design-layout, sdtk-screen-design-spec]
-    pack: core
-
-  - name: sdtk-api-doc
-    phase: arch
-    role_tag: /api-doc
-    use_when: Generate or update OpenAPI YAML, API endpoints markdown, and flow-list files from architecture scope.
-    primary_inputs:
-      - docs/specs/BA_SPEC_[FEATURE_KEY].md
-      - docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md
-    primary_outputs:
-      - docs/api/[FeaturePascal]_API.yaml
-      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
-      - docs/api/[feature_snake]_api_flow_list.txt
-    hard_gates:
-      - Do not invent API paths or schemas that contradict BA or ARCH source.
-      - Keep YAML, endpoint markdown, and flow list synchronized.
-    references:
-      - toolkit/skills/sdtk-api-doc/references/YAML_CREATION_RULES.md
-      - toolkit/skills/sdtk-api-doc/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
-    prompts: []
-    scripts: []
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-arch, sdtk-ba]
-    pack: core
-
-  - name: sdtk-api-design-spec
-    phase: arch
-    role_tag: /api-design-spec
-    use_when: Generate API design detail markdown from OpenAPI YAML and API flow list.
-    primary_inputs:
-      - docs/api/[FeaturePascal]_API.yaml
-      - docs/api/[feature_snake]_api_flow_list.txt
-    primary_outputs:
-      - docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md
-      - docs/api/flows/*.puml
-      - docs/api/images/*.svg
-    hard_gates:
-      - Do not drift from the source YAML or flow list.
-      - Do not leave broken flow image embeds in the generated markdown.
-    references:
-      - toolkit/skills/sdtk-api-design-spec/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
-      - toolkit/skills/sdtk-api-design-spec/references/API_DESIGN_CREATION_RULES.md
-    prompts: []
-    scripts:
-      - toolkit/skills/sdtk-api-design-spec/scripts/generate_api_design_detail.py
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-api-doc]
-    pack: core
-
-  - name: sdtk-design-layout
-    phase: arch
-    role_tag: /design-layout
-    use_when: Generate design-layout docs with PlantUML salt wireframes and item tables for UI scope.
-    primary_inputs:
-      - docs/specs/BA_SPEC_[FEATURE_KEY].md
-      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
-    primary_outputs:
-      - docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md
-      - docs/specs/assets/<feature_snake>/screens/*.svg
-    hard_gates:
-      - Do not skip screen IDs or item numbering alignment with the wireframe.
-      - If rendering is unavailable, record that explicitly instead of pretending render assets exist.
-    references: []
-    prompts: []
-    scripts:
-      - toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-arch, sdtk-ba]
-    pack: core
-
-  - name: sdtk-screen-design-spec
-    phase: arch
-    role_tag: /screen-design-spec
-    use_when: Build flow-action specs from requirement sources, design source references, and API mappings.
-    primary_inputs:
-      - docs/specs/BA_SPEC_[FEATURE_KEY].md
-      - docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md
-      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
-    primary_outputs:
-      - docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md
-      - docs/specs/assets/<feature_snake>/screens/*
-    hard_gates:
-      - Do not finalize UI-scope screens without a valid design source type and reference.
-      - Do not leave broken image paths or missing API mappings in the spec.
-    references:
-      - toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md
-      - toolkit/skills/sdtk-screen-design-spec/references/numbering-rules.md
-      - toolkit/skills/sdtk-screen-design-spec/references/figma-mcp.md
-      - toolkit/skills/sdtk-screen-design-spec/references/excel-image-export.md
-    prompts: []
-    scripts:
-      - toolkit/skills/sdtk-screen-design-spec/scripts/validate_flow_action_spec_numbering.py
-      - toolkit/skills/sdtk-screen-design-spec/scripts/renumber_flow_action_spec_global.py
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-arch, sdtk-design-layout]
-    pack: core
-
-  - name: sdtk-test-case-spec
-    phase: qa
-    role_tag: /test-case-spec
-    use_when: Generate reusable screen-based test-case specifications before or during QA execution.
-    primary_inputs:
-      - docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md
-      - docs/specs/BA_SPEC_[FEATURE_KEY].md
-      - docs/api/[FEATURE_KEY]_ENDPOINTS.md
-    primary_outputs:
-      - docs/qa/[FEATURE_KEY]_TEST_CASE.md
-    hard_gates:
-      - Do not invent test coverage that is not grounded in BA, flow-action, or API sources.
-      - Keep totals and structured coverage counts consistent with the QA baseline.
-    references:
-      - toolkit/skills/sdtk-test-case-spec/references/TEST_CASE_CREATION_RULES.md
-    prompts: []
-    scripts:
-      - toolkit/skills/sdtk-test-case-spec/scripts/validate_test_case_spec.py
-    runtime_support: [claude, codex]
-    dependencies: [sdtk-qa, sdtk-screen-design-spec]
-    pack: core

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

@@ -1,76 +0,0 @@
----
-name: api-design-spec
-description: Generate detailed API design markdown from OpenAPI YAML and API flow list using Excel-style structure rules. Use when you need field-level request/response tables + per-endpoint process flow images for implementation/review handoff.
----
-
-## Required Inputs (read before proceeding)
-Read the following artifacts for the current feature:
-1. `docs/api/[FeaturePascal]_API.yaml` — API contract
-2. `docs/api/[feature_snake]_api_flow_list.txt` — flow list
-
-## Input
-$ARGUMENTS
-
-# SDTK API Design Detail Spec
-
-## Outputs
-- `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md`
-- Supporting generated assets:
-  - `docs/api/flows/*.puml`
-  - `docs/api/images/*.svg`
-
-## Required Inputs
-- Feature key (`FEATURE_KEY`)
-- API contract YAML:
-  - Preferred: `docs/api/[FeaturePascal]_API.yaml`
-  - Fallback: a specified YAML file path
-- API flow list:
-  - Preferred: `docs/api/[feature_snake]_api_flow_list.txt`
-  - Fallback: a specified flow list path
-
-## Core Rules
-- Apply `.claude/skills/references/API_DESIGN_FLOWCHART_CREATION_RULES.md` first.
-- Keep endpoint contracts consistent with source YAML.
-- Keep process flow source synchronized with flow list (`*_api_flow_list.txt`).
-- Keep one visible flowchart per API section (embed image), avoid duplicate preview rendering.
-- Keep `Process Flow` sections implementation-readable:
-  - include YAML-derived flow summary / notes / login bullets
-  - keep error sections aligned with actual flow exits, not `None`
-
-## Generation Procedure
-1. Resolve input files (`yaml`, `flow_list`, `output`).
-2. Parse YAML endpoints (method, path, request schema, success/error schema).
-3. Parse flow blocks from flow list (`@startuml ... @enduml`) and map by `METHOD + path`.
-4. Generate detailed markdown sections per API:
-   - Flow summary / notes / login bullets from YAML `description`
-   - Process flow source block (`text` fenced block)
-   - Embedded flowchart image
-   - Path parameter table
-   - Request table (hierarchy levels + type + format + required)
-   - Success response table
-   - Error response table (explicit schema if defined, otherwise shared envelope + inferred business statuses from flow)
-5. Generate/update `.puml` per API under `docs/api/flows`.
-6. Render `.svg` images under `docs/api/images`.
-7. Validate:
-   - every API section has one embedded image
-   - every embed path exists
-   - no render error image output
-   - markdown tables keep `No` sequential numbering
-
-## Script
-- `scripts/generate_api_design_detail.py`
-
-### Typical command
-```bash
-python scripts/generate_api_design_detail.py \
-  --feature-key SCHEDULE_WHITEBOARD \
-  --yaml "docs/api/ScheduleWhiteboard_API.yaml" \
-  --flow-list "docs/api/schedule_whiteboard_api_flow_list.txt" \
-  --output "docs/api/SCHEDULE_WHITEBOARD_API_DESIGN_DETAIL.md"
-```
-
-## Orchestrator Integration (Hybrid)
-- `apiDesignDetailMode` in `sdtk.config.json` controls orchestration behavior:
-  - `auto` (default): generate API design detail when ARCH has API scope and YAML/flow sources are available.
-  - `on`: always generate API design detail for API scope (fail if required sources are missing).
-  - `off`: skip unless user explicitly requests.

package/assets/toolkit/toolkit/skills-claude/api-doc/SKILL.md

@@ -1,47 +0,0 @@
----
-name: api-doc
-description: Generate OpenAPI 3.x YAML and PlantUML flow diagrams for a feature following this toolkit's API conventions. Use when you need to create/update docs/api/* (API spec + flow list) from BA_SPEC/ARCH_DESIGN.
----
-
-## 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, data model
-
-## Input
-$ARGUMENTS
-
-# SDTK API Documentation
-
-## Outputs
-- `docs/api/[FeaturePascal]_API.yaml`
-- `docs/api/[FEATURE_KEY]_ENDPOINTS.md`
-- `docs/api/[feature_snake]_api_flow_list.txt`
-- Optional downstream (via `/api-design-spec`):
-  - `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md`
-
-## Inputs (minimum)
-- Feature name/key
-- Entities + key fields
-- Use cases (UC-xx) + business rules (BR-xx)
-- Auth/permission model
-
-## Process
-1. Read `docs/specs/BA_SPEC_[FEATURE_KEY].md` and/or `docs/architecture/ARCH_DESIGN_[FEATURE_KEY].md`.
-2. Read and apply split API rule sources:
-   - `.claude/skills/references/YAML_CREATION_RULES.md` for YAML contract rules
-   - `.claude/skills/references/API_DESIGN_FLOWCHART_CREATION_RULES.md` for flow list / flowchart rules
-3. Define endpoints mapped to UC-xx; keep path naming consistent across CRUD/search/list/mst patterns and apply `governance/ai/core/SDTK_API_PATH_STYLE_POLICY.md` for canonical resource naming.
-4. For each endpoint, document request/response schema and error cases.
-5. Generate/update endpoint markdown (`[FEATURE_KEY]_ENDPOINTS.md`) with summary tables, API type grouping, and screen-logic mapping.
-6. Generate PlantUML flows including auth, permission check, validation, main logic, and error exits.
-7. Ensure traceability notes reference UC/BR where relevant.
-8. For benchmark runs, if the requirement or upstream artifacts mark an OQ as expected OPEN, keep that ambiguity explicit in flow list / endpoint docs instead of silently collapsing it.
-9. Validate English output hygiene when generating English artifacts:
-   - no mixed-language leftovers in narrative text
-   - no mojibake/encoding corruption markers
-   - terminology consistency across endpoint detail, summary tables, and flow labels
-10. If orchestrator mode requires API design detail generation (`apiDesignDetailMode=auto/on`), handoff to `/api-design-spec` after YAML + flow list are updated.
-
-## Reference
-- Deeper analysis: `docs/specs/API_DOC_SKILL_ANALYSIS.md` (if present).

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

@@ -1,72 +0,0 @@
----
-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
-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 2 BA Analysis gate must show all items [x] Done.
-- Phase 2+ PM Planning gate must show all items [x] Done.
-
-If prerequisites are not met, report which gate is missing and 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 are 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 and 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:
-   - `.claude/skills/references/YAML_CREATION_RULES.md`
-   - `.claude/skills/references/API_DESIGN_FLOWCHART_CREATION_RULES.md`
-   - `governance/ai/core/SDTK_API_PATH_STYLE_POLICY.md` for canonical resource naming and multi-word path style
-4. If architecture output includes screen flow-action specs, read and apply `.claude/skills/references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
-5. If API detail spec is required, use `/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 `/screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
-7. Define:
-   - System components + data model
-   - API endpoints and flows
-   - Screen layouts
-   - 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. For benchmark runs, apply `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`: keep benchmark-expected open questions explicitly OPEN unless the requirement source resolves them.
-11. If anything is unclear, record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to PM.
-12. Update shared state + Phase 3 checklist.
-13. Handoff: suggest user run `/dev` to implement the design.

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

@@ -1,50 +0,0 @@
----
-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
-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 1 PM Init gate must show all items [x] Done.
-
-If prerequisites are not met, report which gate is missing and 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 are 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. For benchmark runs, apply `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`: keep benchmark-expected open questions explicitly OPEN and do not silently resolve them in BA output.
-5. If anything is unclear, record OQ-xx in BA_SPEC "Open Questions" and escalate to PM.
-6. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 2.
-7. Handoff: suggest user run `/pm` to proceed with PRD planning.

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

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

@@ -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.