sdtk-kit 0.3.3 → 0.3.5

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

@@ -17,18 +17,19 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
   - `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
 
 ## Process
-1. Read BA spec + PRD/backlog.
+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 the split API rule sources before defining endpoints/flows:
+3. If architecture output includes API contracts/flows, read and apply:
    - `./references/YAML_CREATION_RULES.md`
    - `./references/API_DESIGN_FLOWCHART_CREATION_RULES.md`
-4. If architecture output includes screen flow-action specs, read and apply rules from `./references/FLOW_ACTION_SPEC_CREATION_RULES.md` (global numbering policy).
-5. If API detail spec is required, use skill `sdtk-api-design-spec` to build/update `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md` using YAML + flow list.
-6. For complex UI flow-action specs, use skill `sdtk-screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.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 `./references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
+5. If API detail spec is required, use `sdtk-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 `sdtk-screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
 7. Define:
    - System components + data model
-   - API endpoints and flows (if backend changes)
-   - Screen layouts (if UI changes)
+   - API endpoints and flows
+   - Screen layouts
    - Security/authz decisions
 8. Create/update:
    - OpenAPI YAML + API endpoint markdown
@@ -37,8 +38,9 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
    - Database spec (if DB impact exists)
    - Flow-action spec and design layout (if UI impact exists)
 9. Ensure mapping UC/BR -> DB/API/screens and run output hygiene checks:
-   - EN artifacts use English narrative text (except clearly marked original-language appendix blocks).
-   - No mojibake/encoding corruption in markdown/yaml/txt outputs.
-10. If anything is unclear: record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to `@pm` for a decision (PM asks the user if still missing info).
-11. Update shared state + Phase 3 checklist.
-12. Handoff: `@dev please implement ...`.
+   - 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` for a decision.
+12. Update shared state + Phase 3 checklist.
+13. Handoff: `@dev please implement ...`.

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

@@ -9,7 +9,7 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
 - `docs/specs/BA_SPEC_[FEATURE_KEY].md`
 
 ## Process
-1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` (and any source requirements).
+1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` and any source requirements.
 2. Produce:
    - Glossary
    - BR-xx (numbered)
@@ -17,8 +17,9 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
    - AC-xx (mapped to UC/BR)
    - NFR-xx
    - Risks + Open Questions
-   - Traceability summary table (REQ → UC/BR/AC)
-3. If source requirements are VI/JP: preserve the original text and add a literal EN translation in appendices.
-4. If anything is unclear: record OQ-xx in BA_SPEC “Open Questions” and escalate to `@pm` for a decision (PM asks the user if still missing info).
-5. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 2.
-6. Handoff: `@pm specs ready for PRD`.
+   - 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` for a decision.
+6. Update `SHARED_PLANNING.md` and `QUALITY_CHECKLIST.md` Phase 2.
+7. Handoff: `@pm specs ready for PRD`.

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

@@ -13,10 +13,11 @@ description: QA workflow for SDTK. Use when you need to validate an implemented
 ## 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 `sdtk-test-case-spec` and align counts/coverage with release testing scope.
-4. If acceptance criteria / expected behavior is unclear: record OQ-xx in QA report and escalate to `@pm` (PM asks the user if still missing info).
-5. Execute/record results (unit/integration/e2e as applicable).
-6. Record defects with severity and status.
-7. Decide: APPROVED vs REJECTED (with reasons).
-8. Update shared state + Phase 5 checklist.
-9. Handoff: `@pm please finalize release status ...` if approved.
+3. If test-case specification artifact is required, invoke `sdtk-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` if still missing info.
+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: `@pm please finalize release status ...` if approved.

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

@@ -24,24 +24,23 @@ description: Generate screen-based QA test-case markdown (`[FEATURE_KEY]_TEST_CA
 ## Core Rules
 1. Apply `./references/TEST_CASE_CREATION_RULES.md` first.
 2. Keep section order fixed (Statistic -> Abbreviations -> Scope -> References -> Environment -> Coverage -> Screen-based UTC/ITC -> OQ -> STC/UAT note).
-3. Use screen-first layout to mirror worksheet structure:
-   - each screen can have `[SCREEN_KEY]_UTC` and `[SCREEN_KEY]_ITC`.
+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`.
+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)`:
-   - include UT total, IT total, grand total.
+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
 
@@ -62,4 +61,3 @@ description: Generate screen-based QA test-case markdown (`[FEATURE_KEY]_TEST_CA
 python "toolkit/skills/sdtk-test-case-spec/scripts/validate_test_case_spec.py" `
   --file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
 ```
-

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

@@ -5,8 +5,8 @@ description: Generate OpenAPI 3.x YAML and PlantUML flow diagrams for a feature
 
 ## 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
+1. `docs/specs/BA_SPEC_*.md` - business rules, use cases
+2. `docs/architecture/ARCH_DESIGN_*.md` - system components, data model
 
 ## Input
 $ARGUMENTS
@@ -31,16 +31,17 @@ $ARGUMENTS
 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.
+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, error exits.
+6. Generate PlantUML flows including auth, permission check, validation, main logic, and error exits.
 7. Ensure traceability notes reference UC/BR where relevant.
-8. Validate English output hygiene when generating English artifacts:
+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
-9. If orchestrator mode requires API design detail generation (`apiDesignDetailMode=auto/on`), handoff to `/api-design-spec` after YAML + flow list are updated.
+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

@@ -4,19 +4,19 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
 ---
 
 ## SDTK Pipeline Rules (always apply)
-1. Pipeline: PM Initiation → BA Analysis → PM Planning → Architecture Design → Development + Review → QA Validation
+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
+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 missing, ask focused questions.
+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 NOT met: report which gate is missing, suggest user run the prerequisite phase first.
+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('{}')}"`
@@ -27,7 +27,7 @@ If prerequisites NOT met: report which gate is missing, suggest user run the pre
 ## Input
 $ARGUMENTS
 
-If no arguments provided, read current feature context from SHARED_PLANNING.md.
+If no arguments are provided, read current feature context from SHARED_PLANNING.md.
 
 # SDTK ARCH (Solution Architecture)
 
@@ -43,18 +43,19 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
   - `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
 
 ## Process
-1. Read BA spec + PRD/backlog.
+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 the split API rule sources before defining endpoints/flows:
+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`
-4. If architecture output includes screen flow-action specs, read and apply rules from `.claude/skills/references/FLOW_ACTION_SPEC_CREATION_RULES.md` (global numbering policy).
-5. If API detail spec is required, use skill `/api-design-spec` to build/update `docs/api/[FEATURE_KEY]_API_DESIGN_DETAIL.md` using YAML + flow list.
-6. For complex UI flow-action specs, use skill `/screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
+   - `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 (if backend changes)
-   - Screen layouts (if UI changes)
+   - API endpoints and flows
+   - Screen layouts
    - Security/authz decisions
 8. Create/update:
    - OpenAPI YAML + API endpoint markdown
@@ -63,8 +64,9 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
    - Database spec (if DB impact exists)
    - Flow-action spec and design layout (if UI impact exists)
 9. Ensure mapping UC/BR -> DB/API/screens and run output hygiene checks:
-   - EN artifacts use English narrative text (except clearly marked original-language appendix blocks).
-   - No mojibake/encoding corruption in markdown/yaml/txt outputs.
-10. If anything is unclear: record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to PM (suggest user run `/pm` for a decision if still missing info).
-11. Update shared state + Phase 3 checklist.
-12. Handoff: suggest user run `/dev` to implement the design.
+   - 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

@@ -4,18 +4,18 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
 ---
 
 ## SDTK Pipeline Rules (always apply)
-1. Pipeline: PM Initiation → BA Analysis → PM Planning → Architecture Design → Development + Review → QA Validation
+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
+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 missing, ask focused questions.
+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 NOT met: report which gate is missing, suggest user run `/pm` first.
+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('{}')}"`
@@ -26,7 +26,7 @@ If prerequisites NOT met: report which gate is missing, suggest user run `/pm` f
 ## Input
 $ARGUMENTS
 
-If no arguments provided, read current feature context from SHARED_PLANNING.md.
+If no arguments are provided, read current feature context from SHARED_PLANNING.md.
 
 # SDTK BA (Business Analysis)
 
@@ -34,7 +34,7 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
 - `docs/specs/BA_SPEC_[FEATURE_KEY].md`
 
 ## Process
-1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` (and any source requirements).
+1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` and any source requirements.
 2. Produce:
    - Glossary
    - BR-xx (numbered)
@@ -42,8 +42,9 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
    - AC-xx (mapped to UC/BR)
    - NFR-xx
    - Risks + Open Questions
-   - Traceability summary table (REQ → UC/BR/AC)
-3. If source requirements are VI/JP: preserve the original text and add a literal EN translation in appendices.
-4. If anything is unclear: record OQ-xx in BA_SPEC "Open Questions" and escalate to PM (suggest user run `/pm` for a decision if still missing info).
-5. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 2.
-6. Handoff: suggest user run `/pm` to proceed with PRD planning.
+   - 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/qa/SKILL.md

@@ -4,18 +4,18 @@ description: QA workflow for SDTK. Use when you need to validate an implemented
 ---
 
 ## SDTK Pipeline Rules (always apply)
-1. Pipeline: PM Initiation → BA Analysis → PM Planning → Architecture Design → Development + Review → QA Validation
+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
+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 missing, ask focused questions.
+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 NOT met: report which gate is missing, suggest user run `/dev` first to complete code review.
+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('{}')}"`
@@ -26,7 +26,7 @@ If prerequisites NOT met: report which gate is missing, suggest user run `/dev`
 ## Input
 $ARGUMENTS
 
-If no arguments provided, read current feature context from SHARED_PLANNING.md.
+If no arguments are provided, read current feature context from SHARED_PLANNING.md.
 
 # SDTK QA (Testing + Release Decision)
 
@@ -38,10 +38,11 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
 ## Process
 1. Validate prerequisites: DEV phase completed + code review PASS.
 2. Create test strategy mapped to UC/AC.
-3. If test-case specification artifact is required, invoke `/test-case-spec` and align counts/coverage with release testing scope.
-4. If acceptance criteria / expected behavior is unclear: record OQ-xx in QA report and escalate to PM (suggest user run `/pm` if still missing info).
-5. Execute/record results (unit/integration/e2e as applicable).
-6. Record defects with severity and status.
-7. Decide: APPROVED vs REJECTED (with reasons).
-8. Update shared state + Phase 5 checklist.
-9. Handoff: suggest user run `/pm` to finalize release status if approved.
+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/test-case-spec/SKILL.md

@@ -5,10 +5,10 @@ description: Generate screen-based QA test-case markdown in Excel-aligned layout
 
 ## 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)
+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
@@ -23,24 +23,23 @@ $ARGUMENTS
 ## Core Rules
 1. Apply `.claude/skills/references/TEST_CASE_CREATION_RULES.md` first.
 2. Keep section order fixed (Statistic -> Abbreviations -> Scope -> References -> Environment -> Coverage -> Screen-based UTC/ITC -> OQ -> STC/UAT note).
-3. Use screen-first layout to mirror worksheet structure:
-   - each screen can have `[SCREEN_KEY]_UTC` and `[SCREEN_KEY]_ITC`.
+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`.
+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)`:
-   - include UT total, IT total, grand total.
+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
 
@@ -58,6 +57,5 @@ $ARGUMENTS
 
 ### Typical command
 ```bash
-python scripts/validate_test_case_spec.py \
-  --file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
+python scripts/validate_test_case_spec.py   --file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
 ```

package/package.json

@@ -1,46 +1,46 @@
 {
-    "name":  "sdtk-kit",
-    "version":  "0.3.3",
-    "description":  "SDTK CLI toolkit for deterministic software documentation workflows",
-    "bin":  {
-                "sdtk":  "./bin/sdtk.js"
-            },
-    "main":  "src/index.js",
-    "type":  "commonjs",
-    "files":  [
-                  "bin/",
-                  "src/",
-                  "assets/"
-              ],
-    "scripts":  {
-                    "test":  "node -e \"console.log(\u0027No tests configured yet\u0027)\"",
-                    "build:payload":  "powershell -ExecutionPolicy Bypass -File scripts/sync-toolkit-assets.ps1 \u0026\u0026 powershell -ExecutionPolicy Bypass -File scripts/build-toolkit-manifest.ps1",
-                    "verify:payload":  "node -e \"require(\u0027./src/lib/toolkit-payload\u0027).verify()\"",
-                    "pack:smoke":  "npm pack --dry-run",
-                    "pack:release":  "npm pack",
-                    "prepublishOnly":  "node -e \"require(\u0027./src/lib/toolkit-payload\u0027).verify()\""
-                },
-    "engines":  {
-                    "node":  "\u003e=18.13.0"
-                },
-    "keywords":  [
-                     "sdtk",
-                     "cli",
-                     "documentation",
-                     "toolkit",
-                     "dockkit"
-                 ],
-    "license":  "MIT",
-    "repository":  {
-                       "type":  "git",
-                       "url":  "https://github.com/codexsdtk/sdtk-toolkit.git",
-                       "directory":  "distribution/sdtk-cli"
-                   },
-    "homepage":  "https://agenttoolkits.dev",
-    "bugs":  {
-                 "url":  "https://github.com/codexsdtk/sdtk-toolkit/issues"
-             },
-    "publishConfig":  {
-                          "access":  "public"
-                      }
+    "name": "sdtk-kit",
+    "version": "0.3.5",
+    "description": "SDTK CLI toolkit for deterministic software documentation workflows",
+    "bin": {
+        "sdtk": "./bin/sdtk.js"
+    },
+    "main": "src/index.js",
+    "type": "commonjs",
+    "files": [
+        "bin/",
+        "src/",
+        "assets/"
+    ],
+    "scripts": {
+        "test": "node -e \"console.log('No tests configured yet')\"",
+        "build:payload": "powershell -ExecutionPolicy Bypass -File scripts/sync-toolkit-assets.ps1 && powershell -ExecutionPolicy Bypass -File scripts/build-toolkit-manifest.ps1",
+        "verify:payload": "node -e \"require('./src/lib/toolkit-payload').verify()\"",
+        "pack:smoke": "npm pack --dry-run",
+        "pack:release": "npm pack",
+        "prepublishOnly": "node -e \"require('./src/lib/toolkit-payload').verify()\""
+    },
+    "engines": {
+        "node": ">=18.13.0"
+    },
+    "keywords": [
+        "sdtk",
+        "cli",
+        "documentation",
+        "toolkit",
+        "dockkit"
+    ],
+    "license": "MIT",
+    "repository": {
+        "type": "git",
+        "url": "https://github.com/codexsdtk/sdtk-toolkit.git",
+        "directory": "distribution/sdtk-cli"
+    },
+    "homepage": "https://agenttoolkits.dev",
+    "bugs": {
+        "url": "https://github.com/codexsdtk/sdtk-toolkit/issues"
+    },
+    "publishConfig": {
+        "access": "public"
+    }
 }

package/src/commands/help.js

@@ -9,15 +9,36 @@ function cmdHelp() {
     "",
     "Commands:",
     "  init      Initialize SDTK workspace (runtime adapter + config)",
+    "  runtime   Manage runtime asset installation (install, uninstall, status)",
     "  auth      Manage GitHub authentication and entitlement",
     "  generate  Scaffold feature documentation from templates (17 files)",
     "",
     "Init options:",
-    "  --runtime <codex|claude>   Runtime adapter (default: codex)",
+    "  --runtime <codex|claude>       Runtime adapter (default: codex)",
+    "  --runtime-scope <project|user> Install scope (default: project for claude, user for codex)",
+    "  --project-path <path>          Target project directory (default: cwd)",
+    "  --force                        Overwrite existing files",
+    "  --skip-runtime-assets          Skip runtime asset installation",
+    "  --skip-skills                  (deprecated, use --skip-runtime-assets)",
+    "  --verbose                      Show detailed PowerShell script output",
+    "",
+    "Runtime subcommands:",
+    "  sdtk runtime install   --runtime <codex|claude> [--scope <project|user>]",
+    "  sdtk runtime uninstall --runtime <codex|claude> [--scope <project|user>] [--all]",
+    "  sdtk runtime status    --runtime <codex|claude>",
+    "",
+    "Runtime options:",
+    "  --runtime <codex|claude>   Target runtime (required)",
+    "  --scope <project|user>     Install scope (default: project for claude, user for codex)",
     "  --project-path <path>      Target project directory (default: cwd)",
-    "  --force                    Overwrite existing files",
-    "  --skip-skills              Skip skill installation (Codex and Claude)",
-    "  --verbose                  Show detailed PowerShell script output",
+    "  --force                    Overwrite existing skills",
+    "  --all                      Uninstall all managed skills",
+    "  --verbose                  Show detailed script output",
+    "",
+    "Scope behavior:",
+    "  project  Skills are installed inside the repo (Claude only: .claude/skills/)",
+    "  user     Skills are installed in the runtime home (~/.claude/skills/ or ~/.codex/skills/)",
+    "  Note: Codex supports user scope only. Project scope is not available for Codex.",
     "",
     "Auth options:",
     "  --token <value>            Store GitHub PAT",
@@ -60,6 +81,11 @@ function cmdHelp() {
     "  sdtk auth --verify",
     '  sdtk generate --feature-key USER_PROFILE --feature-name "User Profile"',
     "  sdtk generate --feature-key ORDER_MGMT --feature-name \"Order Management\" --validate-only",
+    "  sdtk init --runtime claude --runtime-scope user",
+    "  sdtk runtime install --runtime claude --scope project",
+    "  sdtk runtime install --runtime codex --scope user",
+    "  sdtk runtime status --runtime claude",
+    "  sdtk runtime uninstall --runtime claude --scope project --all",
     "",
     "  # Override entitlement repo (bash/zsh):",
     "  export SDTK_ENTITLEMENT_REPO=owner/repo",

package/src/commands/init.js

@@ -5,12 +5,15 @@ const { parseFlags, validateChoice } = require("../lib/args");
 const { verify, resolvePayloadFile } = require("../lib/toolkit-payload");
 const { runScript } = require("../lib/powershell");
 const { ValidationError } = require("../lib/errors");
+const { VALID_SCOPES, defaultScope, isProjectScopeSupported } = require("../lib/scope");
 
 const FLAG_DEFS = {
   runtime: { type: "string" },
   "project-path": { type: "string" },
+  "runtime-scope": { type: "string" },
   force: { type: "boolean" },
   "skip-skills": { type: "boolean" },
+  "skip-runtime-assets": { type: "boolean" },
   verbose: { type: "boolean" },
 };
 
@@ -23,6 +26,25 @@ async function cmdInit(args) {
   const runtime = flags.runtime || "codex";
   validateChoice(runtime, VALID_RUNTIMES, "runtime");
 
+  // Resolve scope
+  const scope = flags["runtime-scope"] || defaultScope(runtime);
+  validateChoice(scope, VALID_SCOPES, "runtime-scope");
+
+  // Gate C0: Codex does not support project-local skills
+  if (scope === "project" && !isProjectScopeSupported(runtime)) {
+    throw new ValidationError(
+      "Codex does not support project-local skills. Use --runtime-scope user instead."
+    );
+  }
+
+  // Handle deprecated --skip-skills
+  const skipAssets = flags["skip-runtime-assets"] || flags["skip-skills"];
+  if (flags["skip-skills"] && !flags["skip-runtime-assets"]) {
+    console.warn(
+      "Warning: --skip-skills is deprecated. Use --skip-runtime-assets instead."
+    );
+  }
+
   // Resolve project path
   const projectPath = flags["project-path"]
     ? path.resolve(flags["project-path"])
@@ -38,13 +60,15 @@ async function cmdInit(args) {
   const params = {
     ProjectPath: projectPath,
     Runtime: runtime,
+    Scope: scope,
   };
   if (flags.force) params.Force = true;
-  if (flags["skip-skills"]) params.SkipSkills = true;
+  if (skipAssets) params.SkipRuntimeAssets = true;
   if (!flags.verbose) params.Quiet = true;
 
   console.log(`Initializing SDTK workspace...`);
   console.log(`  Runtime: ${runtime}`);
+  console.log(`  Scope:   ${scope}`);
   console.log(`  Project: ${projectPath}`);
   console.log("");