sdtk-kit 0.3.5 → 0.3.7

package/README.md

@@ -4,6 +4,10 @@ SDTK CLI -- deterministic documentation toolkit for software teams.
 
 Wraps the SDTK PowerShell toolkit for portable, reproducible feature documentation scaffolding.
 
+Canonical install/runtime source in the source repo: `governance/ai/cli/SDTK_RUNTIME_AND_FEATURE_STATUS.md`
+
+Generated skills include verification gates and two-stage review hard gates. See `toolkit/SDTK_TOOLKIT.md` for workflow quality contracts.
+
 ## Install
 
 ```bash
@@ -166,3 +170,6 @@ npm run verify:payload
 # Smoke test npm pack
 npm run pack:smoke
 ```
+
+Run `tests/skill_triggering/` to validate skill routing behavior.
+

package/assets/manifest/toolkit-bundle.manifest.json

@@ -1,13 +1,13 @@
 {
-    "version":  "0.3.5",
-    "sourceCommit":  "537f76cfcb2d42882cc5fb19946f0389279e1583",
-    "buildTimestamp":  "2026-03-11T08:51:43Z",
-    "fileCount":  81,
+    "version":  "0.3.7",
+    "sourceCommit":  "65389f67329cb7379a816963ccdc039dfca74b86",
+    "buildTimestamp":  "2026-03-17T07:28:34Z",
+    "fileCount":  85,
     "files":  [
                   {
                       "path":  "toolkit/AGENTS.md",
-                      "sha256":  "868430474b46e4e8d27ed26b780a794936e84cf4f0278f2cc3d061f54877f498",
-                      "size":  5113
+                      "sha256":  "6abad956dae1c20f14d78319282141963e544c24da7ad4d3c22250ff9ebdb783",
+                      "size":  5887
                   },
                   {
                       "path":  "toolkit/install.ps1",
@@ -116,8 +116,8 @@
                   },
                   {
                       "path":  "toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md",
-                      "sha256":  "b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0",
-                      "size":  5741
+                      "sha256":  "a9b8a776ec57a29363924f3f1aef324567292ae17b3bb2ba9d43c83760d926bc",
+                      "size":  7546
                   },
                   {
                       "path":  "toolkit/skills/sdtk-arch/references/FLOWCHART_CREATION_RULES.md",
@@ -131,23 +131,43 @@
                   },
                   {
                       "path":  "toolkit/skills/sdtk-arch/SKILL.md",
-                      "sha256":  "78275557bbea966134422423fb6910cecdc5468e7bf2abb777ff1c4233345639",
-                      "size":  2597
+                      "sha256":  "bd7c67ed7d4caf130939fb2dd373fa7e4823b9d85bd45dffbb90761b0510c33a",
+                      "size":  4876
                   },
                   {
                       "path":  "toolkit/skills/sdtk-ba/SKILL.md",
                       "sha256":  "0a7c6aa20be2e29aa2124355264ee45847df76f635437c2d05ddd26f7121f12e",
                       "size":  1177
                   },
+                  {
+                      "path":  "toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py",
+                      "sha256":  "ee01a3daeeb4822429f4dcf530c11f15ac65df6700615beefd6c04c3fb41bbbc",
+                      "size":  6832
+                  },
                   {
                       "path":  "toolkit/skills/sdtk-design-layout/SKILL.md",
-                      "sha256":  "8eabb7bdb821a91766ccd5b5fdcc1a4e876b51052cd6c6429b98b4d9946e2b1a",
-                      "size":  718
+                      "sha256":  "24f24cc3561342b4e19ca076ad557dd09a5da380ef979dad68664ab671dd8452",
+                      "size":  1733
+                  },
+                  {
+                      "path":  "toolkit/skills/sdtk-dev/prompts/code-quality-reviewer.md",
+                      "sha256":  "3d44bc436dab6201beeb4fed52ab3aa94791c51baca7b7b8e2e8a5ecd6c08baf",
+                      "size":  1125
+                  },
+                  {
+                      "path":  "toolkit/skills/sdtk-dev/prompts/implementer.md",
+                      "sha256":  "9bed2859fbeee84257199e63eb471874975d26d57f5a19dcedab0c06980e24ad",
+                      "size":  1844
+                  },
+                  {
+                      "path":  "toolkit/skills/sdtk-dev/prompts/spec-reviewer.md",
+                      "sha256":  "1dc33dd59afe48c4c78564bdb32999b9a4f34958361ad8f5580cef0e77c953ef",
+                      "size":  1222
                   },
                   {
                       "path":  "toolkit/skills/sdtk-dev/SKILL.md",
-                      "sha256":  "7a7f5a799247896a8ddebc5cefec25450bf9284d34044b6b69b13e4535c005a1",
-                      "size":  1006
+                      "sha256":  "785bdb7e35d6b1c58eee35cda1bd9c7f16f543c302c65287a1484b32fc9e8717",
+                      "size":  5426
                   },
                   {
                       "path":  "toolkit/skills/sdtk-dev-backend/SKILL.md",
@@ -161,8 +181,8 @@
                   },
                   {
                       "path":  "toolkit/skills/sdtk-orchestrator/SKILL.md",
-                      "sha256":  "e6560b5a0c893d66117eedac3762bb0758553a80bcd1e7c24c84ba91f6ab7f9c",
-                      "size":  2868
+                      "sha256":  "5dbd257f32f0b72ac8968f392bb20789a7e488a612a0f01e8debed80999d0ffa",
+                      "size":  4352
                   },
                   {
                       "path":  "toolkit/skills/sdtk-pm/SKILL.md",
@@ -171,8 +191,8 @@
                   },
                   {
                       "path":  "toolkit/skills/sdtk-qa/SKILL.md",
-                      "sha256":  "564c536395227511ac9be215e41a3b5604e2f249da28319417ca75a6bfe8ed3b",
-                      "size":  1459
+                      "sha256":  "4330fcec7b9dcb59ff4a10fb9f39a5c056a0e24ae66655a509e7f79fef6936c0",
+                      "size":  2568
                   },
                   {
                       "path":  "toolkit/skills/sdtk-screen-design-spec/references/excel-image-export.md",
@@ -186,8 +206,8 @@
                   },
                   {
                       "path":  "toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md",
-                      "sha256":  "b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0",
-                      "size":  5741
+                      "sha256":  "a9b8a776ec57a29363924f3f1aef324567292ae17b3bb2ba9d43c83760d926bc",
+                      "size":  7546
                   },
                   {
                       "path":  "toolkit/skills/sdtk-screen-design-spec/references/numbering-rules.md",
@@ -206,8 +226,8 @@
                   },
                   {
                       "path":  "toolkit/skills/sdtk-screen-design-spec/SKILL.md",
-                      "sha256":  "876d546e077ce451082792776360a4a309cc79a34c74234f1b55f80c56b159d1",
-                      "size":  2996
+                      "sha256":  "6a7149d761ca3e76353a9b78f7ad8195360e8d43dae6e4fa5d1035ef27f0462e",
+                      "size":  4242
                   },
                   {
                       "path":  "toolkit/skills/sdtk-test-case-spec/references/TEST_CASE_CREATION_RULES.md",
@@ -386,13 +406,13 @@
                   },
                   {
                       "path":  "toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md",
-                      "sha256":  "b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0",
-                      "size":  5741
+                      "sha256":  "a9b8a776ec57a29363924f3f1aef324567292ae17b3bb2ba9d43c83760d926bc",
+                      "size":  7546
                   },
                   {
                       "path":  "toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md",
-                      "sha256":  "afa6ac33875037495e28238a2c3fae2f4dcbb12f318c3cec0696fe45465cdf2a",
-                      "size":  4135
+                      "sha256":  "b045989fb4eb6b4a0f62341019c4388f498d18027ec09a0d8da91f3fe310fd51",
+                      "size":  4760
                   },
                   {
                       "path":  "toolkit/templates/QUALITY_CHECKLIST.md",

package/assets/manifest/toolkit-bundle.sha256.txt

@@ -1,4 +1,4 @@
-868430474b46e4e8d27ed26b780a794936e84cf4f0278f2cc3d061f54877f498  toolkit/AGENTS.md
+6abad956dae1c20f14d78319282141963e544c24da7ad4d3c22250ff9ebdb783  toolkit/AGENTS.md
 e717a2791fb597d7a21f57f4c4790dbc545e954f0af3ca0c47f160f78c8a2474  toolkit/install.ps1
 0f3e0bfe1b5165250f0da4da5790a9e6220023752713088a0076eb7f17fd6397  toolkit/runtimes/claude/CLAUDE_TEMPLATE.md
 4154c15c71f44d2f2caf07fb41722fa65d4f9ec7e78f798ee084effd12345c62  toolkit/runtimes/codex/CODEX_TEMPLATE.md
@@ -20,25 +20,29 @@ f29c6774019ef0789dfb88678e1ab31d4d8eb7b3ab69b2115368ef5d879e5276  toolkit/skills
 2c4bc8edda84f20bf05130fdf19b9abd562dd87b03508301dff9ccd877b52a2f  toolkit/skills/sdtk-api-doc/SKILL.md
 9adf1e46833411a861fb7426c37baac69689b9e3120a8ed1e4a3224de44a8dd2  toolkit/skills/sdtk-arch/references/API_DESIGN_CREATION_RULES.md
 13f26a3307894b9bfb570d75f6db4ccb61104064d19661ec2a26a1b9984f4c97  toolkit/skills/sdtk-arch/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
-b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0  toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md
+a9b8a776ec57a29363924f3f1aef324567292ae17b3bb2ba9d43c83760d926bc  toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md
 decffe52425e22b3dd82e9c8f3768aefbb209ec58237107d84f583fee876ea8f  toolkit/skills/sdtk-arch/references/FLOWCHART_CREATION_RULES.md
 f29c6774019ef0789dfb88678e1ab31d4d8eb7b3ab69b2115368ef5d879e5276  toolkit/skills/sdtk-arch/references/YAML_CREATION_RULES.md
-78275557bbea966134422423fb6910cecdc5468e7bf2abb777ff1c4233345639  toolkit/skills/sdtk-arch/SKILL.md
+bd7c67ed7d4caf130939fb2dd373fa7e4823b9d85bd45dffbb90761b0510c33a  toolkit/skills/sdtk-arch/SKILL.md
 0a7c6aa20be2e29aa2124355264ee45847df76f635437c2d05ddd26f7121f12e  toolkit/skills/sdtk-ba/SKILL.md
-8eabb7bdb821a91766ccd5b5fdcc1a4e876b51052cd6c6429b98b4d9946e2b1a  toolkit/skills/sdtk-design-layout/SKILL.md
-7a7f5a799247896a8ddebc5cefec25450bf9284d34044b6b69b13e4535c005a1  toolkit/skills/sdtk-dev/SKILL.md
+ee01a3daeeb4822429f4dcf530c11f15ac65df6700615beefd6c04c3fb41bbbc  toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py
+24f24cc3561342b4e19ca076ad557dd09a5da380ef979dad68664ab671dd8452  toolkit/skills/sdtk-design-layout/SKILL.md
+3d44bc436dab6201beeb4fed52ab3aa94791c51baca7b7b8e2e8a5ecd6c08baf  toolkit/skills/sdtk-dev/prompts/code-quality-reviewer.md
+9bed2859fbeee84257199e63eb471874975d26d57f5a19dcedab0c06980e24ad  toolkit/skills/sdtk-dev/prompts/implementer.md
+1dc33dd59afe48c4c78564bdb32999b9a4f34958361ad8f5580cef0e77c953ef  toolkit/skills/sdtk-dev/prompts/spec-reviewer.md
+785bdb7e35d6b1c58eee35cda1bd9c7f16f543c302c65287a1484b32fc9e8717  toolkit/skills/sdtk-dev/SKILL.md
 4b242b5f86d0074538e14721cc66c0fbaac5757e984796145f5e4477c89c6729  toolkit/skills/sdtk-dev-backend/SKILL.md
 390d895ab5da1fd214efecdbbd13c81e92815d4db157a7e9e8f32c79e09439dd  toolkit/skills/sdtk-dev-frontend/SKILL.md
-e6560b5a0c893d66117eedac3762bb0758553a80bcd1e7c24c84ba91f6ab7f9c  toolkit/skills/sdtk-orchestrator/SKILL.md
+5dbd257f32f0b72ac8968f392bb20789a7e488a612a0f01e8debed80999d0ffa  toolkit/skills/sdtk-orchestrator/SKILL.md
 7dd81943172b1d7a96093424b0ba76519db3d713272374d5c4aedb15f37adbe2  toolkit/skills/sdtk-pm/SKILL.md
-564c536395227511ac9be215e41a3b5604e2f249da28319417ca75a6bfe8ed3b  toolkit/skills/sdtk-qa/SKILL.md
+4330fcec7b9dcb59ff4a10fb9f39a5c056a0e24ae66655a509e7f79fef6936c0  toolkit/skills/sdtk-qa/SKILL.md
 97f65fd84c80e4836c9bbb82d8b7fc81527336c55dbbd82ea5e69672e21b22e4  toolkit/skills/sdtk-screen-design-spec/references/excel-image-export.md
 a9b414a07d76e63331ffc832dea2381357f9a99e2cd82ea74f713b3a9d7acee7  toolkit/skills/sdtk-screen-design-spec/references/figma-mcp.md
-b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0  toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md
+a9b8a776ec57a29363924f3f1aef324567292ae17b3bb2ba9d43c83760d926bc  toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md
 4edd3318634fbc142f1ce3161fc3ac93d901a6bb7f0add1d1bed7fc25293c4d9  toolkit/skills/sdtk-screen-design-spec/references/numbering-rules.md
 b54b14cc75c02c3fe9f89547b3f09baf1d7d036ef5f3d9f40487516e22351c45  toolkit/skills/sdtk-screen-design-spec/scripts/renumber_flow_action_spec_global.py
 ae0bc9b120c19a142f10cc79168a8f7d6bf8a37e48341fc16cbc74bbdc2e692c  toolkit/skills/sdtk-screen-design-spec/scripts/validate_flow_action_spec_numbering.py
-876d546e077ce451082792776360a4a309cc79a34c74234f1b55f80c56b159d1  toolkit/skills/sdtk-screen-design-spec/SKILL.md
+6a7149d761ca3e76353a9b78f7ad8195360e8d43dae6e4fa5d1035ef27f0462e  toolkit/skills/sdtk-screen-design-spec/SKILL.md
 7c21e74f5eee712c6b65665b4f10483ed008113186a92dc0a4673ce1fcd3ef5c  toolkit/skills/sdtk-test-case-spec/references/TEST_CASE_CREATION_RULES.md
 4d1e813908114f2be68007fb7373973e2c6e0aebc5a6305b8b19443d5ae477d0  toolkit/skills/sdtk-test-case-spec/scripts/validate_test_case_spec.py
 727a9870a455e9c455b2c405cb52c6b9867f229fa56d8ce9408e66b6f6cae4a5  toolkit/skills/sdtk-test-case-spec/SKILL.md
@@ -74,8 +78,8 @@ e8d3554fc4893a8a57fbf006e58f37f21347de5f31ce02f0717e97d29b387eea  toolkit/templa
 7c21e74f5eee712c6b65665b4f10483ed008113186a92dc0a4673ce1fcd3ef5c  toolkit/templates/docs/qa/TEST_CASE_CREATION_RULES.md
 4b64a123d6e22edefa17a23a1eff766cf612ec5fa2f78b34bf50eecb39abf06a  toolkit/templates/docs/qa/TEST_CASE_TEMPLATE.md
 3b5f911d5e0eb042efc388ef3a441285a57d2dc02ae032d080934495e2d06f4d  toolkit/templates/docs/specs/BA_SPEC_TEMPLATE.md
-b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0  toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md
-afa6ac33875037495e28238a2c3fae2f4dcbb12f318c3cec0696fe45465cdf2a  toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md
+a9b8a776ec57a29363924f3f1aef324567292ae17b3bb2ba9d43c83760d926bc  toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md
+b045989fb4eb6b4a0f62341019c4388f498d18027ec09a0d8da91f3fe310fd51  toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md
 f9dc0d49ceeeb8814d77670e43f09b5221f46d406fb1e89eb575c1ab39bc022a  toolkit/templates/QUALITY_CHECKLIST.md
 0ccb7a0509cf92aa91ebea95996dfffd5b52edd6ab4bbefbb827e4ed495abc31  toolkit/templates/README.md
 2b5d4d10019e3c9b3219d92b8123acc85872d9c76230107206e7a270a5ece5a2  toolkit/templates/SHARED_PLANNING.md

package/assets/toolkit/toolkit/AGENTS.md

@@ -12,6 +12,7 @@ Goal: use SDTK as a virtual PM/BA/ARCH/DEV/QA operating model to deliver one fea
 - Read stack and command configuration from `sdtk.config.json` in the project root.
 - For VI/JP source requirements, keep original text in an appendix and add literal English translation for traceability.
 - Code review must be complete before QA starts.
+- Verification-before-completion: no phase may declare done, pass, or handoff-ready without fresh command evidence per `governance/ai/core/SDTK_VERIFICATION_BEFORE_COMPLETION_POLICY.md`.
 
 ## 0.1) Clarification Protocol
 Apply for all roles (`/pm`, `/ba`, `/arch`, `/dev`, `/qa`):
@@ -44,6 +45,13 @@ Notes:
 5. DEV Implementation + Code Review -> `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md` + code + tests
 6. QA Testing -> `docs/qa/[FEATURE_KEY]_TEST_CASE.md` + `docs/qa/QA_RELEASE_REPORT_[FEATURE_KEY].md`
 
+## 2.1) DEV Review Gates
+DEV Review Gates (mandatory, in order):
+1. Artifact/spec compliance review -- verify code matches BA spec, API YAML, FLOW_ACTION_SPEC, and DB spec line by line.
+2. Code quality review -- verify structure, naming, test coverage, and maintainability. Runs ONLY after Stage 1 PASS.
+
+QA handoff is blocked until both gates PASS.
+
 ## 3) Shared State And Quality Gates
 - `SHARED_PLANNING.md`: phase status, owners, artifacts, blockers, handoff notes.
 - `QUALITY_CHECKLIST.md`: gate checklist by phase.
@@ -94,16 +102,22 @@ Rule files are installed locally by the runtime. Skills resolve these at:
 - Claude Code: `.claude/skills/references/`
 - Codex: `$CODEX_HOME/skills/<skill>/references/`
 
+Workflow governance docs:
+- `governance/ai/core/SDTK_VERIFICATION_BEFORE_COMPLETION_POLICY.md` -- verification-before-completion gate
+- `governance/ai/core/SDTK_SKILL_AUTHORING_AND_TESTING.md` -- maintainer authoring/test guide
+
 Available rule files:
-- `YAML_CREATION_RULES.md` — API YAML docs
-- `API_DESIGN_FLOWCHART_CREATION_RULES.md` — API design detail + flow docs
-- `FLOWCHART_CREATION_RULES.md` — Flowchart (legacy compat)
-- `API_DESIGN_CREATION_RULES.md` — API design (legacy compat)
-- `FLOW_ACTION_SPEC_CREATION_RULES.md` — Screen flow-action specs
-- `TEST_CASE_CREATION_RULES.md` — QA test-case specs
-- `numbering-rules.md` — Flow-action numbering policy
-- `figma-mcp.md` — Figma MCP integration
-- `excel-image-export.md` — Excel image export
+- `YAML_CREATION_RULES.md` -- API YAML docs
+- `API_DESIGN_FLOWCHART_CREATION_RULES.md` -- API design detail + flow docs
+- `FLOWCHART_CREATION_RULES.md` -- Flowchart (legacy compat)
+- `API_DESIGN_CREATION_RULES.md` -- API design (legacy compat)
+- `FLOW_ACTION_SPEC_CREATION_RULES.md` -- Screen flow-action specs
+- `TEST_CASE_CREATION_RULES.md` -- QA test-case specs
+- `numbering-rules.md` -- Flow-action numbering policy
+- `figma-mcp.md` -- Figma MCP integration
+- `excel-image-export.md` -- Excel image export
 
 Flow-action numbering policy:
 - Use one global numbering mode for the whole document (no per-screen reset).
+
+

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

@@ -16,6 +16,19 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
   - `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md`
   - `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
 
+## Flow Overview
+
+```dot
+digraph sdtk_arch_flow {
+  rankdir=TB;
+  BA_SPEC -> ARCH_DESIGN;
+  ARCH_DESIGN -> DESIGN_LAYOUT;
+  DESIGN_LAYOUT -> FLOW_ACTION_SPEC;
+  ARCH_DESIGN -> API_YAML;
+  API_YAML -> API_DETAIL;
+}
+```
+
 ## Process
 1. Read BA spec and PRD/backlog.
 2. Read `sdtk.config.json` for project stack assumptions (backend/frontend/db/auth).
@@ -25,22 +38,42 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
    - `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:
+6. For UI-scope features, enforce this generation sequence:
+   a. Generate/update `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` first (using `sdtk-design-layout`).
+   b. Attempt to render screen preview images from the layout using `render_design_layout_images.py`. Output: `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`. If rendering fails (no Java/plantuml.jar), fall back to the render-skipped note -- do not silently skip.
+   c. Then generate/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md` (using `sdtk-screen-design-spec`).
+   d. The flow-action spec must reference the design-layout doc as its design source when no Figma/screenshot is available (Design Source Type: `generated-draft`). Use rendered `.svg` files as the screen image. If render failed, use the render-skipped note instead of a broken image reference.
+7. For complex UI flow-action specs, use `sdtk-screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
+8. Define:
    - System components + data model
    - API endpoints and flows
    - Screen layouts
    - Security/authz decisions
-8. Create/update:
+9. 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` for a decision.
-12. Update shared state + Phase 3 checklist.
-13. Handoff: `@dev please implement ...`.
+   - Design layout (if UI impact exists) - must be created before flow-action spec
+   - Flow-action spec (if UI impact exists) - must reference design layout as fallback source
+10. 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
+11. 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.
+12. If anything is unclear, record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to `@pm` for a decision.
+13. Update shared state + Phase 3 checklist.
+14. Handoff: `@dev please implement ...`.
+
+## Order-Critical Hard Gate
+For UI-scope features, do not generate or update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md` until `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` already exists and is current enough to serve as the design source for the same scope.
+
+If the layout is missing, stale, or cannot support the flow-action spec, stop and fix the layout first. Do not reverse the order and repair it later.
+
+
+## Common Mistakes
+
+| Mistake | Why it is wrong | Do instead |
+|---|---|---|
+| Generate `FLOW_ACTION_SPEC` before `DESIGN_LAYOUT` for UI scope | Forces the spec to invent screen behavior without a design source | Create or refresh the layout first, then derive the flow-action spec |
+| Treat API YAML, API detail, and flow-action outputs as independent documents | Causes naming and traceability drift across artifacts | Keep ARCH outputs linked through shared requirements and path policy |
+| Close open questions silently during ARCH | Hides unresolved design decisions from downstream roles | Record `OQ-xx` explicitly and escalate through `@pm` |

package/assets/toolkit/toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md

@@ -32,9 +32,9 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 
 - Every table must include a `No` column (sequential numbering).
 - Use stable headers for action tables:
-  - `No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
+  - `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
 - Use stable headers for API mapping tables:
-  - `No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes`
+  - `No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes`
 - Use stable headers for screen mapping:
   - `No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs`
 - Table rows must keep column count consistent with the header (no broken or merged rows).
@@ -43,7 +43,7 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 ### 3.1 Language and Encoding Standards (EN Artifacts)
 
 - For EN artifacts (`docs/en/**` or explicitly requested EN version), narrative text must be English.
-- JP labels can remain only in JP-specific fields/columns (`JP Item Name`, `項目名`, source captions).
+- JP labels, if provided by the input, should be kept in a clearly marked appendix or note column, not in the default item table columns.
 - Do not leave mixed-language fragments in one sentence/cell (for example VI+EN mixed text).
 - If original VI/JP text is required for traceability, keep it in a clearly marked appendix block (`Original Text`), then provide EN translation.
 - Save files as UTF-8 and avoid mojibake/broken glyphs (`�`, `ↁE`, garbled sequences).
@@ -69,12 +69,29 @@ For each screen section:
 - Provide metadata:
   - official screen name
   - Screen ID
-  - design source URL (for example Figma)
-- Embed one representative image per screen.
+  - Design Source Type
+  - Design Source Reference
+- Embed one representative image per screen (from Figma, screenshot, or generated layout).
 - Provide one action table.
 - Provide one API mapping table.
 - If a screen has dialogs, create explicit dialog sub-sections with their own tables and API mapping.
 
+## 5.1 Design Source Modes
+
+Each screen section must declare a design source using one of these modes:
+
+| Mode | When | Design Source Reference |
+|------|------|----------------------|
+| `source-backed` | Figma URL or screenshot is available | Figma URL or screenshot path |
+| `generated-draft` | No Figma/screenshot, but feature has UI scope | Section reference in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` |
+| `none` | Feature has no UI scope for this screen | State `N/A - no UI scope` |
+
+Rules:
+- For UI-scope features, `none` is only valid when the specific screen truly has no visual layout.
+- When using `generated-draft`, the `DESIGN_LAYOUT_[FEATURE_KEY].md` must exist before the flow-action spec is finalized.
+- The flow-action spec and the design-layout doc must remain separate documents.
+- When Figma becomes available later, update the source mode from `generated-draft` to `source-backed`.
+
 ## 6. API Traceability Rules
 
 - Every actionable UI event that changes state must map to a write API.
@@ -98,6 +115,17 @@ For each screen section:
 - Store images in repository-relative paths.
 - Do not keep temporary local absolute paths in markdown.
 
+### 8.1 Rendered Screen Images for Generated-Draft Screens
+
+When `Design Source Type` is `generated-draft`:
+- Screen preview images may be rendered from `DESIGN_LAYOUT_[FEATURE_KEY].md` PlantUML SALT wireframes.
+- Renderer: `toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py`
+- Expected output path: `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
+- If the rendered `.svg` file exists, use it as the `Screen image:` reference.
+- If rendering is unavailable or the `.svg` does not exist, replace the image line with:
+  `> Screen image not rendered in this environment. See Design Source Reference for layout.`
+- Do not leave a broken image reference pointing to a non-existent file.
+
 ## 9. Consistency with Other Specs
 
 - Align terms with:
@@ -128,7 +156,7 @@ For each screen section:
 - All mandatory sections exist.
 - All tables include `No`.
 - Numbering is global across the document (no resets).
-- No broken image links.
+- No broken image links (for `generated-draft` screens: `.svg` exists or render-skipped note is present).
 - Screen/API mappings are consistent with `*_ENDPOINTS.md`.
 - Open questions are explicit and traceable.
 - For EN artifact: no leftover VI text outside allowed `Original Text` appendix blocks.

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

@@ -15,6 +15,22 @@ description: Generate UI screen layout documentation for a feature, including Pl
    - API list table
    - Item table with numbering that matches the wireframe
 3. Keep screen IDs consistent (A-*, B-*, C-*).
+4. After writing `DESIGN_LAYOUT`, attempt to render screen preview images by default:
+   - Run `render_design_layout_images.py` to extract `@startsalt` blocks and render `.svg` files.
+   - Output path: `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
+   - If PlantUML is unavailable, rendering is skipped with a warning and the render-skipped note is used in `FLOW_ACTION_SPEC`. The layout doc remains valid.
+
+## Screen Image Renderer
+- Script: `toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py`
+- Usage:
+  ```
+  python "toolkit/skills/sdtk-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` (auto-detected from VSCode PlantUML extension, or pass `--plantuml-jar`)
+- Output: `.svg` files under `docs/specs/assets/<feature_snake>/screens/`
+- Failure policy: non-blocking. Warns and continues if rendering is unavailable.
 
 ## Template
 - Use `toolkit/templates/docs/design/DESIGN_LAYOUT_TEMPLATE.md` as starting structure.

package/assets/toolkit/toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py

@@ -0,0 +1,213 @@
+#!/usr/bin/env python3
+"""
+Render screen preview SVGs from DESIGN_LAYOUT PlantUML SALT wireframes.
+
+Extracts @startsalt blocks from a DESIGN_LAYOUT_[FEATURE_KEY].md file,
+renders each to .svg using a local plantuml.jar, and writes the images
+to docs/specs/assets/<feature_snake>/screens/.
+
+Graceful failure: if PlantUML is unavailable or a block fails to render,
+the script warns but does not exit with an error code.
+"""
+
+from __future__ import annotations
+
+import argparse
+import re
+import shutil
+import subprocess
+import sys
+from pathlib import Path
+from typing import List, Optional, Tuple
+
+
+def parse_args() -> argparse.Namespace:
+    parser = argparse.ArgumentParser(
+        description="Render screen images from DESIGN_LAYOUT PlantUML SALT blocks."
+    )
+    parser.add_argument(
+        "--design-layout",
+        required=True,
+        help="Path to DESIGN_LAYOUT_[FEATURE_KEY].md",
+    )
+    parser.add_argument(
+        "--feature-key",
+        required=True,
+        help="Feature key, e.g. CRM_LITE",
+    )
+    parser.add_argument(
+        "--output-dir",
+        default="",
+        help="Output directory for SVGs. Default: docs/specs/assets/<feature_snake>/screens/",
+    )
+    parser.add_argument(
+        "--plantuml-jar",
+        default="",
+        help="Explicit path to plantuml.jar. Auto-detected if omitted.",
+    )
+    parser.add_argument(
+        "--skip-render",
+        action="store_true",
+        help="Extract .puml files only, skip SVG rendering.",
+    )
+    return parser.parse_args()
+
+
+def normalize_feature_snake(feature_key: str) -> str:
+    return re.sub(r"[^a-z0-9]+", "_", feature_key.lower()).strip("_")
+
+
+def find_plantuml_jar(explicit: str) -> Optional[Path]:
+    if explicit:
+        p = Path(explicit).expanduser().resolve()
+        return p if p.exists() else None
+    user_home = Path.home()
+    candidates = sorted(
+        (user_home / ".vscode" / "extensions").glob("jebbs.plantuml-*/plantuml.jar")
+    )
+    if candidates:
+        return candidates[-1]
+    return None
+
+
+def extract_screens(text: str) -> List[Tuple[str, str]]:
+    """Extract (screen_id, plantuml_block) pairs from DESIGN_LAYOUT markdown.
+
+    Looks for heading patterns like '## A-1. Screen Name' or '## SCR-01 Screen Name'
+    followed by a fenced plantuml block containing @startsalt.
+    """
+    screens: List[Tuple[str, str]] = []
+    heading_pattern = re.compile(
+        r"^##\s+([A-Z]+-?\d+|SCR-?\d+)[.\s]",
+        re.MULTILINE,
+    )
+    salt_pattern = re.compile(
+        r"```plantuml\s*\n(@startsalt[\s\S]*?@endsalt)\s*\n```",
+        re.MULTILINE,
+    )
+
+    headings = list(heading_pattern.finditer(text))
+    for i, match in enumerate(headings):
+        screen_id = match.group(1).strip().lower().replace("-", "_")
+        start = match.start()
+        end = headings[i + 1].start() if i + 1 < len(headings) else len(text)
+        section = text[start:end]
+
+        salt_match = salt_pattern.search(section)
+        if salt_match:
+            screens.append((screen_id, salt_match.group(1)))
+
+    return screens
+
+
+def render_svg(
+    plantuml_jar: Path, puml_path: Path, output_dir: Path
+) -> Optional[str]:
+    """Render a single .puml to .svg. Returns error string or None on success."""
+    proc = subprocess.run(
+        ["java", "-jar", str(plantuml_jar), "-tsvg", str(puml_path)],
+        stdout=subprocess.PIPE,
+        stderr=subprocess.STDOUT,
+        text=True,
+        check=False,
+    )
+    # PlantUML writes .svg next to the .puml file.
+    svg_path = puml_path.with_suffix(".svg")
+    if not svg_path.exists():
+        return f"Render failed (no svg produced): {puml_path.name}"
+
+    # If .puml is already in the output dir, no copy needed.
+    # Otherwise move the svg to the output dir.
+    svg_dst = output_dir / svg_path.name
+    if svg_path.resolve() != svg_dst.resolve():
+        shutil.copy2(svg_path, svg_dst)
+        svg_path.unlink(missing_ok=True)
+        svg_path = svg_dst
+
+    svg_text = svg_path.read_text(encoding="utf-8", errors="ignore")
+    if any(
+        x in svg_text
+        for x in ("Cannot find group", "Syntax Error", "contains errors")
+    ):
+        return f"Rendered with error content: {svg_path.name}"
+    if proc.returncode != 0:
+        return f"PlantUML exit={proc.returncode} for {puml_path.name}"
+    return None
+
+
+def main() -> int:
+    args = parse_args()
+
+    feature_key = args.feature_key.strip()
+    if not feature_key:
+        print("[ERROR] --feature-key is empty", file=sys.stderr)
+        return 1
+
+    feature_snake = normalize_feature_snake(feature_key)
+    layout_path = Path(args.design_layout)
+    if not layout_path.exists():
+        print(f"[ERROR] Design layout not found: {layout_path}", file=sys.stderr)
+        return 1
+
+    if args.output_dir:
+        output_dir = Path(args.output_dir)
+    else:
+        output_dir = Path(f"docs/specs/assets/{feature_snake}/screens")
+
+    output_dir.mkdir(parents=True, exist_ok=True)
+
+    text = layout_path.read_text(encoding="utf-8")
+    screens = extract_screens(text)
+
+    if not screens:
+        print("[WARN] No screen sections with @startsalt blocks found.")
+        print("[OK] Nothing to render.")
+        return 0
+
+    print(f"[OK] Found {len(screens)} screen(s) with SALT wireframes.")
+
+    # Write .puml files
+    puml_files: List[Path] = []
+    for screen_id, salt_block in screens:
+        puml_name = f"{screen_id}.puml"
+        puml_path = output_dir / puml_name
+        puml_path.write_text(salt_block + "\n", encoding="utf-8")
+        puml_files.append(puml_path)
+
+    if args.skip_render:
+        print(f"[OK] Wrote {len(puml_files)} .puml file(s). Render skipped (--skip-render).")
+        return 0
+
+    # Find PlantUML
+    jar = find_plantuml_jar(args.plantuml_jar)
+    if not jar:
+        print("[WARN] PlantUML jar not found. SVG rendering skipped.")
+        print("       Use --plantuml-jar or install VSCode PlantUML extension.")
+        print(f"[OK] Wrote {len(puml_files)} .puml file(s) without SVG rendering.")
+        return 0
+
+    # Render SVGs
+    errors: List[str] = []
+    rendered = 0
+    for puml_path in puml_files:
+        err = render_svg(jar, puml_path, output_dir)
+        if err:
+            errors.append(err)
+        else:
+            rendered += 1
+
+    print(f"[OK] Rendered {rendered}/{len(puml_files)} screen image(s) to: {output_dir}")
+    if errors:
+        print("[WARN] Render issues:")
+        for item in errors:
+            print(f"  - {item}")
+
+    return 0
+
+
+if __name__ == "__main__":
+    try:
+        raise SystemExit(main())
+    except Exception as exc:
+        print(f"[ERROR] {exc}", file=sys.stderr)
+        raise

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

@@ -9,12 +9,78 @@ description: Developer workflow for SDTK. Use when you need to implement a featu
 - `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md`
 - Code + tests (follow repo conventions)
 
+## Prompt Templates
+- `./prompts/implementer.md`
+- `./prompts/spec-reviewer.md`
+- `./prompts/code-quality-reviewer.md`
+
+Use these templates when you need a controller -> subagent execution loop for implementation and review. The controller owns context selection and pastes the task text into the template placeholders.
+
 ## 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` for a decision (PM asks the user 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: `@qa please test …` (only after code review PASS).
+4. If anything is unclear: record OQ-xx in FEATURE_IMPL_PLAN "Open Questions" and escalate to `@pm` for a decision (PM asks the user if still missing info).
+5. Dispatch implementation work with `./prompts/implementer.md` when task slicing or delegated execution is needed. The controller must paste the full task text and relevant constraints into the template; do not make the implementer subagent discover missing context on its own.
+6. Implement incrementally with tests.
+7. Run the verification commands that prove the current claim (unit tests, lint, typecheck, build, or targeted smoke checks as applicable) and read the full output before saying the work is done.
+8. If delegated review is needed, run the review loop in this order:
+   - `./prompts/spec-reviewer.md` first for artifact/spec compliance
+   - `./prompts/code-quality-reviewer.md` only after spec reviewer PASS is documented
+9. Complete mandatory code review gate (self + peer checklist; AI peer review allowed).
+10. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 4.
+11. Handoff: `@qa please test ...` (only after code review PASS and fresh verification evidence is recorded).
+
+## Delegated Execution Contract
+- The implementer subagent receives the full task text directly in the prompt.
+- Required implementer status values:
+  - `DONE`
+  - `DONE_WITH_CONCERNS`
+  - `NEEDS_CONTEXT`
+  - `BLOCKED`
+- `DONE_WITH_CONCERNS` means the task is complete but the controller must read the concerns before review.
+- `NEEDS_CONTEXT` means the controller must supply missing information and re-dispatch.
+- `BLOCKED` means do not retry the same task unchanged; resolve the blocker first.
+- The spec reviewer must verify real artifacts, not trust implementer claims.
+- The code-quality reviewer is a second-stage review and must not run before spec compliance passes.
+
+## Model Selection Guidance
+Choose the cheapest model that can safely complete the task without creating avoidable rework.
+
+| Task type | Recommended model tier | Why |
+|---|---|---|
+| Single-file mechanical change with a clear spec | Fast model | Speed matters more than deep judgment |
+| Multi-file integration that follows an approved plan | Standard model | Needs pattern matching across several files |
+| Architecture or design tradeoff for the current implementation slice | Most capable model | Requires judgment and ambiguity handling |
+| Stage 1 artifact/spec review | Standard model | Needs careful comparison against requirements |
+| Stage 2 code-quality review | Standard or most capable model | Choose most capable when boundaries or refactors are non-trivial |
+| Cross-artifact consistency investigation | Most capable model | Requires broader synthesis across docs and code |
+
+Blocked-task rule:
+- If an implementer returns `BLOCKED`, do not force the same model to retry the same task unchanged.
+- First resolve missing context or reduce task scope.
+- Escalate to a stronger model only when the blocker is judgment or synthesis bound, not because the prompt was incomplete.
+
+## Verification Before Completion
+Apply `governance/ai/core/SDTK_VERIFICATION_BEFORE_COMPLETION_POLICY.md`.
+
+Do not:
+- say implementation is done, passing, or QA-ready without fresh verification evidence
+- use `should`, `probably`, or `seems` in place of executed checks
+- rely on partial output, stale command runs, or unchecked agent reports
+
+If verification fails or cannot be run, report the status as not verified and explain the blocker.
+
+## Order-Critical Hard Gate
+Do not start implementation work until `docs/dev/FEATURE_IMPL_PLAN_[FEATURE_KEY].md` exists and the current execution scope is explicitly approved in that plan for implementation.
+
+If the plan is missing, incomplete, or still awaiting approval for the current task slice, stop and update the plan first. Do not implement first and backfill the plan later.
+
+
+## Common Mistakes
+
+| Mistake | Why it is wrong | Do instead |
+|---|---|---|
+| Start coding before the implementation plan is approved | Causes scope drift and invalidates review order | Finish and approve `FEATURE_IMPL_PLAN` first |
+| Run Stage 2 code-quality review before Stage 1 spec review passes | Hides requirement mismatches behind style feedback | Keep the review order strict: spec first, quality second |
+| Retry a `BLOCKED` implementer with the same prompt and same model | Repeats the same failure mode | Add missing context, split the task, or change model tier intentionally |

package/assets/toolkit/toolkit/skills/sdtk-dev/prompts/code-quality-reviewer.md

@@ -0,0 +1,35 @@
+# SDTK DEV Code Quality Reviewer Prompt Template
+
+You are the Stage 2 code-quality reviewer for a completed SDTK development task.
+
+## Gate Position
+Run this prompt only after the spec reviewer has passed Stage 1 artifact/spec compliance.
+
+## Inputs From Controller
+- Task ID: `{{TASK_ID}}`
+- Feature key: `{{FEATURE_KEY}}`
+- Stage 1 PASS evidence: `{{SPEC_REVIEW_PASS_EVIDENCE}}`
+- Files to review:
+
+```text
+{{FILES_TO_REVIEW}}
+```
+
+- Relevant coding standards or repo conventions:
+
+```text
+{{CODE_QUALITY_RULES}}
+```
+
+## Review Rules
+- Confirm Stage 1 PASS before reviewing code quality.
+- Review structure, naming, maintainability, boundary clarity, and test quality.
+- Flag issues that make the implementation fragile even if it is spec-compliant.
+- Do not reopen Stage 1 scope unless you find a direct contradiction in the shipped code.
+
+## Response Format
+- Gate result: `{{GATE_RESULT}}`
+- Code quality findings: `{{QUALITY_FINDINGS}}`
+- Test quality findings: `{{TEST_FINDINGS}}`
+- Required improvements: `{{REQUIRED_IMPROVEMENTS}}`
+- Final recommendation: `{{FINAL_RECOMMENDATION}}`

package/assets/toolkit/toolkit/skills/sdtk-dev/prompts/implementer.md

@@ -0,0 +1,61 @@
+# SDTK DEV Implementer Prompt Template
+
+You are the implementation subagent for a single SDTK development task.
+
+## Mission
+Implement exactly the task provided by the controller, then report one of the required status values.
+
+## Inputs From Controller
+- Task ID: `{{TASK_ID}}`
+- Feature key: `{{FEATURE_KEY}}`
+- Scene-setting context: `{{SCENE_CONTEXT}}`
+- Full task text:
+
+```text
+{{FULL_TASK_TEXT}}
+```
+
+- Relevant requirements or constraints:
+
+```text
+{{RELEVANT_CONSTRAINTS}}
+```
+
+- Files already identified by the controller:
+
+```text
+{{KNOWN_FILE_PATHS}}
+```
+
+- Verification commands to run before claiming completion:
+
+```text
+{{VERIFICATION_COMMANDS}}
+```
+
+## Before You Begin
+1. Read the full task text carefully.
+2. If required information is missing, ask focused questions immediately instead of guessing.
+3. Do not ask the controller to make you read unrelated planning files. The controller is responsible for pasting the task context you need.
+
+## Working Rules
+- Stay within the provided task scope.
+- Follow repo conventions and existing patterns in the touched files.
+- Update or add tests when the task requires it.
+- Run the provided verification commands before reporting `DONE` or `DONE_WITH_CONCERNS`.
+- Perform a short self-review against the task requirements and obvious code quality issues before you report back.
+
+## Required Status Taxonomy
+Return exactly one of these statuses:
+- `DONE`
+- `DONE_WITH_CONCERNS`
+- `NEEDS_CONTEXT`
+- `BLOCKED`
+
+## Response Format
+- Status: `{{STATUS}}`
+- Files changed: `{{FILES_CHANGED}}`
+- What was implemented: `{{IMPLEMENTATION_SUMMARY}}`
+- Verification evidence: `{{VERIFICATION_RESULTS}}`
+- Open concerns or blocker details: `{{CONCERNS_OR_BLOCKERS}}`
+- Questions for the controller (if any): `{{FOLLOW_UP_QUESTIONS}}`

package/assets/toolkit/toolkit/skills/sdtk-dev/prompts/spec-reviewer.md

@@ -0,0 +1,42 @@
+# SDTK DEV Spec Reviewer Prompt Template
+
+You are the artifact/spec compliance reviewer for a completed SDTK development task.
+
+## Gate Position
+This is Stage 1 review. It runs before the code-quality reviewer.
+
+## Inputs From Controller
+- Task ID: `{{TASK_ID}}`
+- Feature key: `{{FEATURE_KEY}}`
+- Scope summary: `{{SCOPE_SUMMARY}}`
+- Implementer report:
+
+```text
+{{IMPLEMENTER_REPORT}}
+```
+
+- Requirements to validate against:
+
+```text
+{{SPEC_REQUIREMENTS}}
+```
+
+- Files to review:
+
+```text
+{{FILES_TO_REVIEW}}
+```
+
+## Review Rules
+- Do NOT trust implementer report, verify code.
+- Read the actual files listed by the controller.
+- Compare the changed artifacts against the provided BA/API/FLOW_ACTION/DB/plan requirements line by line.
+- Identify missing behavior, incorrect mappings, requirement drift, and unverified assumptions.
+- If artifact compliance fails, do not allow the code-quality review to proceed.
+
+## Response Format
+- Gate result: `{{GATE_RESULT}}`
+- Requirement-by-requirement findings: `{{SPEC_FINDINGS}}`
+- Missing or incorrect artifacts: `{{ARTIFACT_GAPS}}`
+- Required fixes before Stage 2: `{{REQUIRED_FIXES}}`
+- Verification notes: `{{VERIFICATION_NOTES}}`

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

@@ -21,7 +21,7 @@ description: Orchestrate a full 6-phase SDLC multi-agent workflow (PM/BA/ARCH/DE
   - If phase is QA and test-case specification is in scope, invoke `sdtk-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.
+  - Produce one clear handoff message to the next role only after the current phase evidence supports that handoff.
 
 ## API design detail mode (Hybrid)
 - Read `sdtk.config.json` key: `orchestration.apiDesignDetailMode`.
@@ -37,8 +37,40 @@ description: Orchestrate a full 6-phase SDLC multi-agent workflow (PM/BA/ARCH/DE
   - `on`: always run `sdtk-test-case-spec` for QA phase (fail fast if required inputs are missing).
   - `off`: skip test-case spec generation unless user explicitly requests it.
 
+## Flow Overview
+
+```dot
+digraph sdtk_orchestrator_flow {
+  rankdir=LR;
+  PM -> BA;
+  BA -> ARCH;
+  ARCH -> DEV;
+  DEV -> QA;
+  QA -> PM;
+}
+```
+
+## Verification Before Completion
+Apply `governance/ai/core/SDTK_VERIFICATION_BEFORE_COMPLETION_POLICY.md` whenever you mark a phase complete, mark a gate PASS, or hand off to the next role. Require fresh verification evidence before you state that the phase is done.
+
+Do not:
+- say a phase is done or PASS without citing the evidence that proves it
+- treat a planned command as equivalent to an executed command
+- hand off DEV or QA work with overstated verification status
+
+If the evidence is incomplete, keep the phase open or mark it blocked instead of overstating completion.
+
 ## 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).
+- If input requirements are VI/JP: preserve original text + add EN translation in appendix for traceability (at least in Project Initiation and BA spec).
+
+
+## Common Mistakes
+
+| Mistake | Why it is wrong | Do instead |
+|---|---|---|
+| Skip directly from PM to DEV because the request seems small | Breaks traceability and removes BA and ARCH controls | Keep phase order unless the user explicitly narrows scope with acceptable evidence |
+| Hand off a phase based on planned checks instead of executed evidence | Creates false PASS status and weakens downstream gates | Require fresh evidence before marking the phase complete |
+| Mix generation, review, and release decisions in one uncontrolled turn | Makes status tracking ambiguous | Complete one phase handoff at a time and update shared state before moving on |

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

@@ -11,13 +11,30 @@ description: QA workflow for SDTK. Use when you need to validate an implemented
   - `docs/qa/[FEATURE_KEY]_TEST_CASE.md` via `sdtk-test-case-spec`
 
 ## Process
-1. Validate prerequisites: DEV phase completed + code review PASS.
+1. Validate prerequisites: DEV phase completed + Stage 1 artifact/spec review PASS + Stage 2 code-quality 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. 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).
+6. Execute the required checks, record the commands used, and capture the actual results (unit/integration/e2e or document review evidence as applicable).
 7. Record defects with severity and status.
-8. Decide: APPROVED vs REJECTED (with reasons).
+8. Decide: APPROVED vs REJECTED only after fresh verification evidence supports the verdict.
 9. Update shared state + Phase 5 checklist.
 10. Handoff: `@pm please finalize release status ...` if approved.
+
+## Verification Before Completion
+Apply `governance/ai/core/SDTK_VERIFICATION_BEFORE_COMPLETION_POLICY.md` and require fresh verification evidence before any QA verdict or handoff.
+
+Do not:
+- issue an APPROVED verdict without fresh verification evidence
+- infer PASS from expected behavior, partial logs, or missing runtime access
+- overstate benchmark-mode results as if they were live execution results
+
+If the environment cannot run the proving checks, follow the benchmark QA mode policy explicitly and state that the result is not fully verified at runtime.
+
+## Order-Critical Hard Gate
+Do not start QA handoff, release testing, or release decision work until both DEV review gates are documented as PASS:
+- Stage 1 artifact/spec compliance review
+- Stage 2 code-quality review
+
+If either review gate is missing or not PASS, keep the work in DEV and block QA handoff until both gates are complete.

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

@@ -15,29 +15,39 @@ description: Create/update screen flow-action specifications from requirement so
 ## Required Inputs
 - Feature key/name
 - Primary requirement sources (BA spec, architecture, customer design docs)
-- Screen source references (Figma URLs and/or requirement screenshots)
+- 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` (used when no Figma/screenshot is available for a UI-scope feature)
 - 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 `./references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
-3. Build/update section `Feature overview` and `Screen flow action` (PlantUML).
-4. For each screen/dialog:
-   - Add metadata (screen ID, source link)
-   - Add screen image reference
+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`. That file must exist before finalizing the flow-action spec.
+   - 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)
    - Add UI item/action table with `No` column
    - Add API mapping table (trigger -> API -> data usage)
-5. Build/update `System processing flow` from use-case and process sources.
-6. Build/update `Open questions` for unresolved behavior/API/data points.
-7. Build/update `Screen - API Mapping` summary section.
-8. Validate:
+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
+   - no broken image paths (for `generated-draft` screens, verify `.svg` exists or use render-skipped note)
    - PlantUML renderability
    - consistency with API endpoints spec
    - EN artifact hygiene (no VI leftovers, no mojibake, no merged heading lines)
    - for legacy specs with per-screen reset numbering: run renumber migration first
-9. Update document history and handoff to ARCH/DEV.
+   - every UI-scope screen declares a Design Source Type (`source-backed` or `generated-draft`)
+10. For `generated-draft` screens, set `Screen image:` to the rendered `.svg` path if the file exists:
+    - Expected path: `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
+    - If the `.svg` does not exist (render unavailable), replace the image reference with: `> Screen image not rendered in this environment. See Design Source Reference for layout.`
+11. Update document history and handoff to ARCH/DEV.
 
 ## Rule References
 - Core rules: `./references/FLOW_ACTION_SPEC_CREATION_RULES.md`

package/assets/toolkit/toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md

@@ -32,9 +32,9 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 
 - Every table must include a `No` column (sequential numbering).
 - Use stable headers for action tables:
-  - `No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
+  - `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
 - Use stable headers for API mapping tables:
-  - `No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes`
+  - `No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes`
 - Use stable headers for screen mapping:
   - `No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs`
 - Table rows must keep column count consistent with the header (no broken or merged rows).
@@ -43,7 +43,7 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 ### 3.1 Language and Encoding Standards (EN Artifacts)
 
 - For EN artifacts (`docs/en/**` or explicitly requested EN version), narrative text must be English.
-- JP labels can remain only in JP-specific fields/columns (`JP Item Name`, `項目名`, source captions).
+- JP labels, if provided by the input, should be kept in a clearly marked appendix or note column, not in the default item table columns.
 - Do not leave mixed-language fragments in one sentence/cell (for example VI+EN mixed text).
 - If original VI/JP text is required for traceability, keep it in a clearly marked appendix block (`Original Text`), then provide EN translation.
 - Save files as UTF-8 and avoid mojibake/broken glyphs (`�`, `ↁE`, garbled sequences).
@@ -69,12 +69,29 @@ For each screen section:
 - Provide metadata:
   - official screen name
   - Screen ID
-  - design source URL (for example Figma)
-- Embed one representative image per screen.
+  - Design Source Type
+  - Design Source Reference
+- Embed one representative image per screen (from Figma, screenshot, or generated layout).
 - Provide one action table.
 - Provide one API mapping table.
 - If a screen has dialogs, create explicit dialog sub-sections with their own tables and API mapping.
 
+## 5.1 Design Source Modes
+
+Each screen section must declare a design source using one of these modes:
+
+| Mode | When | Design Source Reference |
+|------|------|----------------------|
+| `source-backed` | Figma URL or screenshot is available | Figma URL or screenshot path |
+| `generated-draft` | No Figma/screenshot, but feature has UI scope | Section reference in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` |
+| `none` | Feature has no UI scope for this screen | State `N/A - no UI scope` |
+
+Rules:
+- For UI-scope features, `none` is only valid when the specific screen truly has no visual layout.
+- When using `generated-draft`, the `DESIGN_LAYOUT_[FEATURE_KEY].md` must exist before the flow-action spec is finalized.
+- The flow-action spec and the design-layout doc must remain separate documents.
+- When Figma becomes available later, update the source mode from `generated-draft` to `source-backed`.
+
 ## 6. API Traceability Rules
 
 - Every actionable UI event that changes state must map to a write API.
@@ -98,6 +115,17 @@ For each screen section:
 - Store images in repository-relative paths.
 - Do not keep temporary local absolute paths in markdown.
 
+### 8.1 Rendered Screen Images for Generated-Draft Screens
+
+When `Design Source Type` is `generated-draft`:
+- Screen preview images may be rendered from `DESIGN_LAYOUT_[FEATURE_KEY].md` PlantUML SALT wireframes.
+- Renderer: `toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py`
+- Expected output path: `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
+- If the rendered `.svg` file exists, use it as the `Screen image:` reference.
+- If rendering is unavailable or the `.svg` does not exist, replace the image line with:
+  `> Screen image not rendered in this environment. See Design Source Reference for layout.`
+- Do not leave a broken image reference pointing to a non-existent file.
+
 ## 9. Consistency with Other Specs
 
 - Align terms with:
@@ -128,7 +156,7 @@ For each screen section:
 - All mandatory sections exist.
 - All tables include `No`.
 - Numbering is global across the document (no resets).
-- No broken image links.
+- No broken image links (for `generated-draft` screens: `.svg` exists or render-skipped note is present).
 - Screen/API mappings are consistent with `*_ENDPOINTS.md`.
 - Open questions are explicit and traceable.
 - For EN artifact: no leftover VI text outside allowed `Original Text` appendix blocks.

package/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md

@@ -32,9 +32,9 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 
 - Every table must include a `No` column (sequential numbering).
 - Use stable headers for action tables:
-  - `No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
+  - `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
 - Use stable headers for API mapping tables:
-  - `No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes`
+  - `No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes`
 - Use stable headers for screen mapping:
   - `No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs`
 - Table rows must keep column count consistent with the header (no broken or merged rows).
@@ -43,7 +43,7 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
 ### 3.1 Language and Encoding Standards (EN Artifacts)
 
 - For EN artifacts (`docs/en/**` or explicitly requested EN version), narrative text must be English.
-- JP labels can remain only in JP-specific fields/columns (`JP Item Name`, `項目名`, source captions).
+- JP labels, if provided by the input, should be kept in a clearly marked appendix or note column, not in the default item table columns.
 - Do not leave mixed-language fragments in one sentence/cell (for example VI+EN mixed text).
 - If original VI/JP text is required for traceability, keep it in a clearly marked appendix block (`Original Text`), then provide EN translation.
 - Save files as UTF-8 and avoid mojibake/broken glyphs (`�`, `ↁE`, garbled sequences).
@@ -69,12 +69,29 @@ For each screen section:
 - Provide metadata:
   - official screen name
   - Screen ID
-  - design source URL (for example Figma)
-- Embed one representative image per screen.
+  - Design Source Type
+  - Design Source Reference
+- Embed one representative image per screen (from Figma, screenshot, or generated layout).
 - Provide one action table.
 - Provide one API mapping table.
 - If a screen has dialogs, create explicit dialog sub-sections with their own tables and API mapping.
 
+## 5.1 Design Source Modes
+
+Each screen section must declare a design source using one of these modes:
+
+| Mode | When | Design Source Reference |
+|------|------|----------------------|
+| `source-backed` | Figma URL or screenshot is available | Figma URL or screenshot path |
+| `generated-draft` | No Figma/screenshot, but feature has UI scope | Section reference in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` |
+| `none` | Feature has no UI scope for this screen | State `N/A - no UI scope` |
+
+Rules:
+- For UI-scope features, `none` is only valid when the specific screen truly has no visual layout.
+- When using `generated-draft`, the `DESIGN_LAYOUT_[FEATURE_KEY].md` must exist before the flow-action spec is finalized.
+- The flow-action spec and the design-layout doc must remain separate documents.
+- When Figma becomes available later, update the source mode from `generated-draft` to `source-backed`.
+
 ## 6. API Traceability Rules
 
 - Every actionable UI event that changes state must map to a write API.
@@ -98,6 +115,17 @@ For each screen section:
 - Store images in repository-relative paths.
 - Do not keep temporary local absolute paths in markdown.
 
+### 8.1 Rendered Screen Images for Generated-Draft Screens
+
+When `Design Source Type` is `generated-draft`:
+- Screen preview images may be rendered from `DESIGN_LAYOUT_[FEATURE_KEY].md` PlantUML SALT wireframes.
+- Renderer: `toolkit/skills/sdtk-design-layout/scripts/render_design_layout_images.py`
+- Expected output path: `docs/specs/assets/<feature_snake>/screens/<screen_id>.svg`
+- If the rendered `.svg` file exists, use it as the `Screen image:` reference.
+- If rendering is unavailable or the `.svg` does not exist, replace the image line with:
+  `> Screen image not rendered in this environment. See Design Source Reference for layout.`
+- Do not leave a broken image reference pointing to a non-existent file.
+
 ## 9. Consistency with Other Specs
 
 - Align terms with:
@@ -128,7 +156,7 @@ For each screen section:
 - All mandatory sections exist.
 - All tables include `No`.
 - Numbering is global across the document (no resets).
-- No broken image links.
+- No broken image links (for `generated-draft` screens: `.svg` exists or render-skipped note is present).
 - Screen/API mappings are consistent with `*_ENDPOINTS.md`.
 - Open questions are explicit and traceable.
 - For EN artifact: no leftover VI text outside allowed `Original Text` appendix blocks.

package/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md

@@ -66,26 +66,29 @@ B --> C : open dialog
 ## 3) Screen layout spec by flow action
 
 > Standard item table format:
-> `No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
+> `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
 
 ### 3.1 Screen A
 
 Information:
-- JP: TBD
 - Screen ID: SCR-01
-- Figma URL: TBD
+- Design Source Type: source-backed | generated-draft | none
+- Design Source Reference: Figma URL | screenshot path | `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md` section reference | `N/A - no UI scope`
 
 Screen image:
-![3.1 Screen A](assets/{{FEATURE_SNAKE}}/screens/screen_3_1_screen_a.png)
+![3.1 Screen A](assets/{{FEATURE_SNAKE}}/screens/scr_01.svg)
 
-| No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
-| ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| 1 | Item A (JP) | Item A | Button | - | - | - | - | Click | TBD | TBD |
-| 2 | Item B (JP) | Item B | Input | string | column_a | 100 | empty | Input | TBD | TBD |
+<!-- If the .svg file does not exist (render unavailable), replace the image line above with: -->
+<!-- > Screen image not rendered in this environment. See Design Source Reference for layout. -->
+
+| No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
+| ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| 1 | Item A | Button | - | - | - | - | Click | TBD | TBD |
+| 2 | Item B | Input | string | column_a | 100 | empty | Input | TBD | TBD |
 
 #### API Mapping (Draft)
 
-| No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes |
+| No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes |
 | ---: | --- | --- | --- | --- |
 | 1 | Initial load | Main area | `GET /api/...` | Load initial dataset |
 | 2 | Click search | No 1 | `POST /api/.../search` | Refresh grid |
@@ -95,20 +98,23 @@ Screen image:
 ### 3.2 Screen B
 
 Information:
-- JP: TBD
 - Screen ID: SCR-02
-- Figma URL: TBD
+- Design Source Type: source-backed | generated-draft | none
+- Design Source Reference: Figma URL | screenshot path | `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md` section reference | `N/A - no UI scope`
 
 Screen image:
-![3.2 Screen B](assets/{{FEATURE_SNAKE}}/screens/screen_3_2_screen_b.png)
+![3.2 Screen B](assets/{{FEATURE_SNAKE}}/screens/scr_02.svg)
+
+<!-- If the .svg file does not exist (render unavailable), replace the image line above with: -->
+<!-- > Screen image not rendered in this environment. See Design Source Reference for layout. -->
 
-| No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
-| ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| 3 | Item C (JP) | Item C | Toggle | boolean | flag_a | - | false | Toggle | TBD | TBD |
+| No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
+| ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- |
+| 3 | Item C | Toggle | boolean | flag_a | - | false | Toggle | TBD | TBD |
 
 #### API Mapping (Draft)
 
-| No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes |
+| No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes |
 | ---: | --- | --- | --- | --- |
 | 1 | Change mode | No 3 | `POST /api/.../edit/{uuid}` | Persist mode |
 

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "sdtk-kit",
-    "version": "0.3.5",
+    "version": "0.3.7",
     "description": "SDTK CLI toolkit for deterministic software documentation workflows",
     "bin": {
         "sdtk": "./bin/sdtk.js"