sdtk-kit 0.3.4 → 0.3.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,5 +1,8 @@
1
1
  {
2
- "buildTimestamp": "2026-03-07T02:40:24Z",
2
+ "version": "0.3.5",
3
+ "sourceCommit": "537f76cfcb2d42882cc5fb19946f0389279e1583",
4
+ "buildTimestamp": "2026-03-11T08:51:43Z",
5
+ "fileCount": 81,
3
6
  "files": [
4
7
  {
5
8
  "path": "toolkit/AGENTS.md",
@@ -98,8 +101,8 @@
98
101
  },
99
102
  {
100
103
  "path": "toolkit/skills/sdtk-api-doc/SKILL.md",
101
- "sha256": "d93980bc0332f25852a5e4b0e5187bde7185a5ede70c59c8ebaf542afdb42188",
102
- "size": 1966
104
+ "sha256": "2c4bc8edda84f20bf05130fdf19b9abd562dd87b03508301dff9ccd877b52a2f",
105
+ "size": 2248
103
106
  },
104
107
  {
105
108
  "path": "toolkit/skills/sdtk-arch/references/API_DESIGN_CREATION_RULES.md",
@@ -128,13 +131,13 @@
128
131
  },
129
132
  {
130
133
  "path": "toolkit/skills/sdtk-arch/SKILL.md",
131
- "sha256": "ddf57e65096fc6f1bdd0f2c829f2580d2d7edb99f79d3cba7a3f68e69d373f46",
132
- "size": 2489
134
+ "sha256": "78275557bbea966134422423fb6910cecdc5468e7bf2abb777ff1c4233345639",
135
+ "size": 2597
133
136
  },
134
137
  {
135
138
  "path": "toolkit/skills/sdtk-ba/SKILL.md",
136
- "sha256": "7bc02ad898b5e7dc36282026dcc718818600a507d18046a9e80d8e6eba588131",
137
- "size": 1041
139
+ "sha256": "0a7c6aa20be2e29aa2124355264ee45847df76f635437c2d05ddd26f7121f12e",
140
+ "size": 1177
138
141
  },
139
142
  {
140
143
  "path": "toolkit/skills/sdtk-design-layout/SKILL.md",
@@ -168,8 +171,8 @@
168
171
  },
169
172
  {
170
173
  "path": "toolkit/skills/sdtk-qa/SKILL.md",
171
- "sha256": "c221eb80c68ba8672fb8a3c13fd6b36d5b65ccdd9988a32be88c6589c4594498",
172
- "size": 1142
174
+ "sha256": "564c536395227511ac9be215e41a3b5604e2f249da28319417ca75a6bfe8ed3b",
175
+ "size": 1459
173
176
  },
174
177
  {
175
178
  "path": "toolkit/skills/sdtk-screen-design-spec/references/excel-image-export.md",
@@ -218,8 +221,8 @@
218
221
  },
219
222
  {
220
223
  "path": "toolkit/skills/sdtk-test-case-spec/SKILL.md",
221
- "sha256": "72ca16e07c286910333243954610e116217ca2abb3a5e276cbe91e92eb826ad5",
222
- "size": 2652
224
+ "sha256": "727a9870a455e9c455b2c405cb52c6b9867f229fa56d8ce9408e66b6f6cae4a5",
225
+ "size": 2842
223
226
  },
224
227
  {
225
228
  "path": "toolkit/skills-claude/api-design-spec/SKILL.md",
@@ -228,18 +231,18 @@
228
231
  },
229
232
  {
230
233
  "path": "toolkit/skills-claude/api-doc/SKILL.md",
231
- "sha256": "57176bb3d74e19ef5feb1a8d59d8c7c1714634f67e1d51bf4667d3f189093319",
232
- "size": 2240
234
+ "sha256": "6f6ddb470bc61d286b84418e299b360d5f148e6bed75fa50b6c8f2929e6fe49c",
235
+ "size": 2518
233
236
  },
234
237
  {
235
238
  "path": "toolkit/skills-claude/arch/SKILL.md",
236
- "sha256": "5ab03dc8a928c6528d1ccaad427a15c686427e8fd9114421da495d9223652337",
237
- "size": 4108
239
+ "sha256": "e293fd71f9fc71ac63e5e53bf55fbfe9c71e186e298b2fd3429c71a4e972a8b1",
240
+ "size": 4175
238
241
  },
239
242
  {
240
243
  "path": "toolkit/skills-claude/ba/SKILL.md",
241
- "sha256": "1956fd69ff1a0adb54c8abbf06b37bd5c21b7f0ca597b6d8b94dfed0606cd2e4",
242
- "size": 2551
244
+ "sha256": "4dd1db27839c73a8ec0bba2b465b7cacffd55393a325a822ced8f2f209f6b51b",
245
+ "size": 2648
243
246
  },
244
247
  {
245
248
  "path": "toolkit/skills-claude/design-layout/SKILL.md",
@@ -273,8 +276,8 @@
273
276
  },
274
277
  {
275
278
  "path": "toolkit/skills-claude/qa/SKILL.md",
276
- "sha256": "eb0a540d28144855b5026e7b40ce965c4049a9b56f6e7ffd9732964006f63d1a",
277
- "size": 2687
279
+ "sha256": "3ab5af1b27aa0947052ef7b76abca132d89b78b74516b8668474c08c344289aa",
280
+ "size": 2956
278
281
  },
279
282
  {
280
283
  "path": "toolkit/skills-claude/screen-design-spec/SKILL.md",
@@ -283,8 +286,8 @@
283
286
  },
284
287
  {
285
288
  "path": "toolkit/skills-claude/test-case-spec/SKILL.md",
286
- "sha256": "efd43e2087961f4e30177144c42e06b6c9b3d73f9533dad34f9ce1284fcdf126",
287
- "size": 2625
289
+ "sha256": "c397431a7752fcdee1dbb7720472703d262bfcc8fb543c4562fbc24a79064769",
290
+ "size": 2806
288
291
  },
289
292
  {
290
293
  "path": "toolkit/templates/docs/api/API_DESIGN_CREATION_RULES.md",
@@ -406,8 +409,5 @@
406
409
  "sha256": "2b5d4d10019e3c9b3219d92b8123acc85872d9c76230107206e7a270a5ece5a2",
407
410
  "size": 3255
408
411
  }
409
- ],
410
- "sourceCommit": "965d6ad1f80a42b8b49c4296ec7a96ffef2655e3",
411
- "version": "0.3.4",
412
- "fileCount": 81
412
+ ]
413
413
  }
@@ -17,21 +17,21 @@ c6147e7b01632cb6ffa017af43e4e5c9e1f98d160ed812ade1d087b1f3ca5490 toolkit/skills
17
17
  13f26a3307894b9bfb570d75f6db4ccb61104064d19661ec2a26a1b9984f4c97 toolkit/skills/sdtk-api-doc/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
18
18
  decffe52425e22b3dd82e9c8f3768aefbb209ec58237107d84f583fee876ea8f toolkit/skills/sdtk-api-doc/references/FLOWCHART_CREATION_RULES.md
19
19
  f29c6774019ef0789dfb88678e1ab31d4d8eb7b3ab69b2115368ef5d879e5276 toolkit/skills/sdtk-api-doc/references/YAML_CREATION_RULES.md
20
- d93980bc0332f25852a5e4b0e5187bde7185a5ede70c59c8ebaf542afdb42188 toolkit/skills/sdtk-api-doc/SKILL.md
20
+ 2c4bc8edda84f20bf05130fdf19b9abd562dd87b03508301dff9ccd877b52a2f toolkit/skills/sdtk-api-doc/SKILL.md
21
21
  9adf1e46833411a861fb7426c37baac69689b9e3120a8ed1e4a3224de44a8dd2 toolkit/skills/sdtk-arch/references/API_DESIGN_CREATION_RULES.md
22
22
  13f26a3307894b9bfb570d75f6db4ccb61104064d19661ec2a26a1b9984f4c97 toolkit/skills/sdtk-arch/references/API_DESIGN_FLOWCHART_CREATION_RULES.md
23
23
  b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0 toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md
24
24
  decffe52425e22b3dd82e9c8f3768aefbb209ec58237107d84f583fee876ea8f toolkit/skills/sdtk-arch/references/FLOWCHART_CREATION_RULES.md
25
25
  f29c6774019ef0789dfb88678e1ab31d4d8eb7b3ab69b2115368ef5d879e5276 toolkit/skills/sdtk-arch/references/YAML_CREATION_RULES.md
26
- ddf57e65096fc6f1bdd0f2c829f2580d2d7edb99f79d3cba7a3f68e69d373f46 toolkit/skills/sdtk-arch/SKILL.md
27
- 7bc02ad898b5e7dc36282026dcc718818600a507d18046a9e80d8e6eba588131 toolkit/skills/sdtk-ba/SKILL.md
26
+ 78275557bbea966134422423fb6910cecdc5468e7bf2abb777ff1c4233345639 toolkit/skills/sdtk-arch/SKILL.md
27
+ 0a7c6aa20be2e29aa2124355264ee45847df76f635437c2d05ddd26f7121f12e toolkit/skills/sdtk-ba/SKILL.md
28
28
  8eabb7bdb821a91766ccd5b5fdcc1a4e876b51052cd6c6429b98b4d9946e2b1a toolkit/skills/sdtk-design-layout/SKILL.md
29
29
  7a7f5a799247896a8ddebc5cefec25450bf9284d34044b6b69b13e4535c005a1 toolkit/skills/sdtk-dev/SKILL.md
30
30
  4b242b5f86d0074538e14721cc66c0fbaac5757e984796145f5e4477c89c6729 toolkit/skills/sdtk-dev-backend/SKILL.md
31
31
  390d895ab5da1fd214efecdbbd13c81e92815d4db157a7e9e8f32c79e09439dd toolkit/skills/sdtk-dev-frontend/SKILL.md
32
32
  e6560b5a0c893d66117eedac3762bb0758553a80bcd1e7c24c84ba91f6ab7f9c toolkit/skills/sdtk-orchestrator/SKILL.md
33
33
  7dd81943172b1d7a96093424b0ba76519db3d713272374d5c4aedb15f37adbe2 toolkit/skills/sdtk-pm/SKILL.md
34
- c221eb80c68ba8672fb8a3c13fd6b36d5b65ccdd9988a32be88c6589c4594498 toolkit/skills/sdtk-qa/SKILL.md
34
+ 564c536395227511ac9be215e41a3b5604e2f249da28319417ca75a6bfe8ed3b toolkit/skills/sdtk-qa/SKILL.md
35
35
  97f65fd84c80e4836c9bbb82d8b7fc81527336c55dbbd82ea5e69672e21b22e4 toolkit/skills/sdtk-screen-design-spec/references/excel-image-export.md
36
36
  a9b414a07d76e63331ffc832dea2381357f9a99e2cd82ea74f713b3a9d7acee7 toolkit/skills/sdtk-screen-design-spec/references/figma-mcp.md
37
37
  b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0 toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md
@@ -41,20 +41,20 @@ ae0bc9b120c19a142f10cc79168a8f7d6bf8a37e48341fc16cbc74bbdc2e692c toolkit/skills
41
41
  876d546e077ce451082792776360a4a309cc79a34c74234f1b55f80c56b159d1 toolkit/skills/sdtk-screen-design-spec/SKILL.md
42
42
  7c21e74f5eee712c6b65665b4f10483ed008113186a92dc0a4673ce1fcd3ef5c toolkit/skills/sdtk-test-case-spec/references/TEST_CASE_CREATION_RULES.md
43
43
  4d1e813908114f2be68007fb7373973e2c6e0aebc5a6305b8b19443d5ae477d0 toolkit/skills/sdtk-test-case-spec/scripts/validate_test_case_spec.py
44
- 72ca16e07c286910333243954610e116217ca2abb3a5e276cbe91e92eb826ad5 toolkit/skills/sdtk-test-case-spec/SKILL.md
44
+ 727a9870a455e9c455b2c405cb52c6b9867f229fa56d8ce9408e66b6f6cae4a5 toolkit/skills/sdtk-test-case-spec/SKILL.md
45
45
  123873681ff65792a9a269b264155c65a5feb68b23e4eeb1e68cb7da1a137d54 toolkit/skills-claude/api-design-spec/SKILL.md
46
- 57176bb3d74e19ef5feb1a8d59d8c7c1714634f67e1d51bf4667d3f189093319 toolkit/skills-claude/api-doc/SKILL.md
47
- 5ab03dc8a928c6528d1ccaad427a15c686427e8fd9114421da495d9223652337 toolkit/skills-claude/arch/SKILL.md
48
- 1956fd69ff1a0adb54c8abbf06b37bd5c21b7f0ca597b6d8b94dfed0606cd2e4 toolkit/skills-claude/ba/SKILL.md
46
+ 6f6ddb470bc61d286b84418e299b360d5f148e6bed75fa50b6c8f2929e6fe49c toolkit/skills-claude/api-doc/SKILL.md
47
+ e293fd71f9fc71ac63e5e53bf55fbfe9c71e186e298b2fd3429c71a4e972a8b1 toolkit/skills-claude/arch/SKILL.md
48
+ 4dd1db27839c73a8ec0bba2b465b7cacffd55393a325a822ced8f2f209f6b51b toolkit/skills-claude/ba/SKILL.md
49
49
  9765f229108c5aff27457489707218570ad83dc362353a79c2f5a78607adf4de toolkit/skills-claude/design-layout/SKILL.md
50
50
  cea9f6512bc805d5b22a84a4ef8dbd229b4f7a3f073f9e125e933e6e79a206d5 toolkit/skills-claude/dev/SKILL.md
51
51
  142a8fe088a4b0326ca79e00200cb5f562c53728b7adc83e6b749db6e29f1d0d toolkit/skills-claude/dev-backend/SKILL.md
52
52
  1631bd51bc3d0106c18f4c00412f6279626bdce9f0e310822d5dcdff08063a88 toolkit/skills-claude/dev-frontend/SKILL.md
53
53
  c8e8303f1833e71cacdf20b1f398e476b44b3de14fbffad9a404c2a68fa713a3 toolkit/skills-claude/orchestrator/SKILL.md
54
54
  b34621fe61957e573c616ad816d591a60a6c8d1333d0bfb71f39f45b93331cb0 toolkit/skills-claude/pm/SKILL.md
55
- eb0a540d28144855b5026e7b40ce965c4049a9b56f6e7ffd9732964006f63d1a toolkit/skills-claude/qa/SKILL.md
55
+ 3ab5af1b27aa0947052ef7b76abca132d89b78b74516b8668474c08c344289aa toolkit/skills-claude/qa/SKILL.md
56
56
  5686da60872f1a3c6791e9a740897d4a564f40d53d54902a47fbc3165e68a1ec toolkit/skills-claude/screen-design-spec/SKILL.md
57
- efd43e2087961f4e30177144c42e06b6c9b3d73f9533dad34f9ce1284fcdf126 toolkit/skills-claude/test-case-spec/SKILL.md
57
+ c397431a7752fcdee1dbb7720472703d262bfcc8fb543c4562fbc24a79064769 toolkit/skills-claude/test-case-spec/SKILL.md
58
58
  9adf1e46833411a861fb7426c37baac69689b9e3120a8ed1e4a3224de44a8dd2 toolkit/templates/docs/api/API_DESIGN_CREATION_RULES.md
59
59
  d2aa0ee3a7c5351700b3bffb4ba66e8056ed955f55903c744c694624730038cb toolkit/templates/docs/api/API_DESIGN_DETAIL_TEMPLATE.md
60
60
  13f26a3307894b9bfb570d75f6db4ccb61104064d19661ec2a26a1b9984f4c97 toolkit/templates/docs/api/API_DESIGN_FLOWCHART_CREATION_RULES.md
@@ -23,16 +23,17 @@ description: Generate OpenAPI 3.x YAML and PlantUML flow diagrams for a feature
23
23
  2. Read and apply split API rule sources:
24
24
  - `./references/YAML_CREATION_RULES.md` for YAML contract rules
25
25
  - `./references/API_DESIGN_FLOWCHART_CREATION_RULES.md` for flow list / flowchart rules
26
- 3. Define endpoints mapped to UC-xx; keep path naming consistent across CRUD/search/list/mst patterns.
26
+ 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.
27
27
  4. For each endpoint, document request/response schema and error cases.
28
28
  5. Generate/update endpoint markdown (`[FEATURE_KEY]_ENDPOINTS.md`) with summary tables, API type grouping, and screen-logic mapping.
29
- 6. Generate PlantUML flows including: auth, permission check, validation, main logic, error exits.
29
+ 6. Generate PlantUML flows including auth, permission check, validation, main logic, and error exits.
30
30
  7. Ensure traceability notes reference UC/BR where relevant.
31
- 8. Validate English output hygiene when generating English artifacts:
31
+ 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.
32
+ 9. Validate English output hygiene when generating English artifacts:
32
33
  - no mixed-language leftovers in narrative text
33
34
  - no mojibake/encoding corruption markers
34
35
  - terminology consistency across endpoint detail, summary tables, and flow labels
35
- 9. If orchestrator mode requires API design detail generation (`apiDesignDetailMode=auto/on`), handoff to `sdtk-api-design-spec` after YAML + flow list are updated.
36
+ 10. If orchestrator mode requires API design detail generation (`apiDesignDetailMode=auto/on`), handoff to `sdtk-api-design-spec` after YAML + flow list are updated.
36
37
 
37
38
  ## Reference
38
39
  - Deeper analysis: `docs/specs/API_DOC_SKILL_ANALYSIS.md` (if present).
@@ -17,18 +17,19 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
17
17
  - `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
18
18
 
19
19
  ## Process
20
- 1. Read BA spec + PRD/backlog.
20
+ 1. Read BA spec and PRD/backlog.
21
21
  2. Read `sdtk.config.json` for project stack assumptions (backend/frontend/db/auth).
22
- 3. If architecture output includes API contracts/flows, read and apply the split API rule sources before defining endpoints/flows:
22
+ 3. If architecture output includes API contracts/flows, read and apply:
23
23
  - `./references/YAML_CREATION_RULES.md`
24
24
  - `./references/API_DESIGN_FLOWCHART_CREATION_RULES.md`
25
- 4. If architecture output includes screen flow-action specs, read and apply rules from `./references/FLOW_ACTION_SPEC_CREATION_RULES.md` (global numbering policy).
26
- 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.
27
- 6. For complex UI flow-action specs, use skill `sdtk-screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
25
+ - `governance/ai/core/SDTK_API_PATH_STYLE_POLICY.md` for canonical resource naming and multi-word path style
26
+ 4. If architecture output includes screen flow-action specs, read and apply `./references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
27
+ 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.
28
+ 6. For complex UI flow-action specs, use `sdtk-screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
28
29
  7. Define:
29
30
  - System components + data model
30
- - API endpoints and flows (if backend changes)
31
- - Screen layouts (if UI changes)
31
+ - API endpoints and flows
32
+ - Screen layouts
32
33
  - Security/authz decisions
33
34
  8. Create/update:
34
35
  - OpenAPI YAML + API endpoint markdown
@@ -37,8 +38,9 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
37
38
  - Database spec (if DB impact exists)
38
39
  - Flow-action spec and design layout (if UI impact exists)
39
40
  9. Ensure mapping UC/BR -> DB/API/screens and run output hygiene checks:
40
- - EN artifacts use English narrative text (except clearly marked original-language appendix blocks).
41
- - No mojibake/encoding corruption in markdown/yaml/txt outputs.
42
- 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).
43
- 11. Update shared state + Phase 3 checklist.
44
- 12. Handoff: `@dev please implement ...`.
41
+ - EN artifacts use English narrative text (except clearly marked original-language appendix blocks)
42
+ - No mojibake/encoding corruption in markdown/yaml/txt outputs
43
+ 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.
44
+ 11. If anything is unclear, record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to `@pm` for a decision.
45
+ 12. Update shared state + Phase 3 checklist.
46
+ 13. Handoff: `@dev please implement ...`.
@@ -9,7 +9,7 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
9
9
  - `docs/specs/BA_SPEC_[FEATURE_KEY].md`
10
10
 
11
11
  ## Process
12
- 1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` (and any source requirements).
12
+ 1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` and any source requirements.
13
13
  2. Produce:
14
14
  - Glossary
15
15
  - BR-xx (numbered)
@@ -17,8 +17,9 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
17
17
  - AC-xx (mapped to UC/BR)
18
18
  - NFR-xx
19
19
  - Risks + Open Questions
20
- - Traceability summary table (REQ UC/BR/AC)
21
- 3. If source requirements are VI/JP: preserve the original text and add a literal EN translation in appendices.
22
- 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).
23
- 5. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 2.
24
- 6. Handoff: `@pm specs ready for PRD`.
20
+ - Traceability summary table (REQ -> UC/BR/AC)
21
+ 3. If source requirements are VI/JP, preserve the original text and add a literal EN translation in appendices.
22
+ 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.
23
+ 5. If anything is unclear, record OQ-xx in BA_SPEC "Open Questions" and escalate to `@pm` for a decision.
24
+ 6. Update `SHARED_PLANNING.md` and `QUALITY_CHECKLIST.md` Phase 2.
25
+ 7. Handoff: `@pm specs ready for PRD`.
@@ -13,10 +13,11 @@ description: QA workflow for SDTK. Use when you need to validate an implemented
13
13
  ## Process
14
14
  1. Validate prerequisites: DEV phase completed + code review PASS.
15
15
  2. Create test strategy mapped to UC/AC.
16
- 3. If test-case specification artifact is required, invoke `sdtk-test-case-spec` and align counts/coverage with release testing scope.
17
- 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).
18
- 5. Execute/record results (unit/integration/e2e as applicable).
19
- 6. Record defects with severity and status.
20
- 7. Decide: APPROVED vs REJECTED (with reasons).
21
- 8. Update shared state + Phase 5 checklist.
22
- 9. Handoff: `@pm please finalize release status ...` if approved.
16
+ 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.
17
+ 4. Apply `governance/ai/core/SDTK_BENCHMARK_QA_MODE_POLICY.md` for benchmark-mode verdict rules when no executable build exists.
18
+ 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.
19
+ 6. Execute/record results (unit/integration/e2e as applicable).
20
+ 7. Record defects with severity and status.
21
+ 8. Decide: APPROVED vs REJECTED (with reasons).
22
+ 9. Update shared state + Phase 5 checklist.
23
+ 10. Handoff: `@pm please finalize release status ...` if approved.
@@ -24,24 +24,23 @@ description: Generate screen-based QA test-case markdown (`[FEATURE_KEY]_TEST_CA
24
24
  ## Core Rules
25
25
  1. Apply `./references/TEST_CASE_CREATION_RULES.md` first.
26
26
  2. Keep section order fixed (Statistic -> Abbreviations -> Scope -> References -> Environment -> Coverage -> Screen-based UTC/ITC -> OQ -> STC/UAT note).
27
- 3. Use screen-first layout to mirror worksheet structure:
28
- - each screen can have `[SCREEN_KEY]_UTC` and `[SCREEN_KEY]_ITC`.
27
+ 3. Use screen-first layout to mirror worksheet structure.
29
28
  4. Keep one unified 18-column schema for UTC/ITC rows.
30
29
  5. Keep stable case IDs; do not renumber only because of regrouping.
31
- 6. Track unresolved decisions via `OQ-xx`.
30
+ 6. Track unresolved decisions via `OQ-xx` and keep benchmark-expected OQs explicitly OPEN per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`.
32
31
 
33
32
  ## Procedure
34
33
  1. Resolve output path:
35
34
  - default `docs/qa/[FEATURE_KEY]_TEST_CASE.md`
36
35
  - use `docs/en/qa/...` only if the repo already follows `docs/en/**`.
37
- 2. Build/refresh `Statistic Summary (Excel-aligned)`:
38
- - include UT total, IT total, grand total.
36
+ 2. Build/refresh `Statistic Summary (Excel-aligned)` with UT total, IT total, and grand total.
39
37
  3. Build `Feature Coverage Matrix` from flow/action and API docs.
40
38
  4. Split UTC/ITC by screen sections (`screen-first`), not by test type only.
41
39
  5. Fill conflict/permission/error-path cases from Q&A decisions and API contracts.
42
40
  6. Record unresolved items in section `Open Questions`.
43
41
  7. Validate:
44
42
  - counts in summary match table rows
43
+ - 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
45
44
  - no placeholder tokens like `??`
46
45
  - out-of-scope boundaries are explicit
47
46
 
@@ -62,4 +61,3 @@ description: Generate screen-based QA test-case markdown (`[FEATURE_KEY]_TEST_CA
62
61
  python "toolkit/skills/sdtk-test-case-spec/scripts/validate_test_case_spec.py" `
63
62
  --file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
64
63
  ```
65
-
@@ -5,8 +5,8 @@ description: Generate OpenAPI 3.x YAML and PlantUML flow diagrams for a feature
5
5
 
6
6
  ## Required Inputs (read before proceeding)
7
7
  Read the following artifacts for the current feature:
8
- 1. `docs/specs/BA_SPEC_*.md` business rules, use cases
9
- 2. `docs/architecture/ARCH_DESIGN_*.md` system components, data model
8
+ 1. `docs/specs/BA_SPEC_*.md` - business rules, use cases
9
+ 2. `docs/architecture/ARCH_DESIGN_*.md` - system components, data model
10
10
 
11
11
  ## Input
12
12
  $ARGUMENTS
@@ -31,16 +31,17 @@ $ARGUMENTS
31
31
  2. Read and apply split API rule sources:
32
32
  - `.claude/skills/references/YAML_CREATION_RULES.md` for YAML contract rules
33
33
  - `.claude/skills/references/API_DESIGN_FLOWCHART_CREATION_RULES.md` for flow list / flowchart rules
34
- 3. Define endpoints mapped to UC-xx; keep path naming consistent across CRUD/search/list/mst patterns.
34
+ 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.
35
35
  4. For each endpoint, document request/response schema and error cases.
36
36
  5. Generate/update endpoint markdown (`[FEATURE_KEY]_ENDPOINTS.md`) with summary tables, API type grouping, and screen-logic mapping.
37
- 6. Generate PlantUML flows including: auth, permission check, validation, main logic, error exits.
37
+ 6. Generate PlantUML flows including auth, permission check, validation, main logic, and error exits.
38
38
  7. Ensure traceability notes reference UC/BR where relevant.
39
- 8. Validate English output hygiene when generating English artifacts:
39
+ 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.
40
+ 9. Validate English output hygiene when generating English artifacts:
40
41
  - no mixed-language leftovers in narrative text
41
42
  - no mojibake/encoding corruption markers
42
43
  - terminology consistency across endpoint detail, summary tables, and flow labels
43
- 9. If orchestrator mode requires API design detail generation (`apiDesignDetailMode=auto/on`), handoff to `/api-design-spec` after YAML + flow list are updated.
44
+ 10. If orchestrator mode requires API design detail generation (`apiDesignDetailMode=auto/on`), handoff to `/api-design-spec` after YAML + flow list are updated.
44
45
 
45
46
  ## Reference
46
47
  - Deeper analysis: `docs/specs/API_DOC_SKILL_ANALYSIS.md` (if present).
@@ -4,19 +4,19 @@ description: Solution Architect workflow for SDTK. Use when you need to convert
4
4
  ---
5
5
 
6
6
  ## SDTK Pipeline Rules (always apply)
7
- 1. Pipeline: PM Initiation BA Analysis PM Planning Architecture Design Development + Review QA Validation
7
+ 1. Pipeline: PM Initiation -> BA Analysis -> PM Planning -> Architecture Design -> Development + Review -> QA Validation
8
8
  2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
9
- 3. If unclear: log OQ-xx in artifact, escalate to PM (PM asks user if needed)
10
- 4. Traceability: REQ BR/UC/AC design backlog code/tests QA
9
+ 3. If unclear: log OQ-xx in artifact, escalate to PM
10
+ 4. Traceability: REQ -> BR/UC/AC -> design -> backlog -> code/tests -> QA
11
11
  5. Code review must be COMPLETE before QA phase can start
12
- 6. Do not skip phases. If inputs missing, ask focused questions.
12
+ 6. Do not skip phases. If inputs are missing, ask focused questions.
13
13
 
14
14
  ## Prerequisites (verify before proceeding)
15
15
  Read QUALITY_CHECKLIST.md and verify:
16
16
  - Phase 2 BA Analysis gate must show all items [x] Done.
17
17
  - Phase 2+ PM Planning gate must show all items [x] Done.
18
18
 
19
- If prerequisites NOT met: report which gate is missing, suggest user run the prerequisite phase first.
19
+ If prerequisites are not met, report which gate is missing and suggest user run the prerequisite phase first.
20
20
 
21
21
  ## Current Context
22
22
  - 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
27
27
  ## Input
28
28
  $ARGUMENTS
29
29
 
30
- If no arguments provided, read current feature context from SHARED_PLANNING.md.
30
+ If no arguments are provided, read current feature context from SHARED_PLANNING.md.
31
31
 
32
32
  # SDTK ARCH (Solution Architecture)
33
33
 
@@ -43,18 +43,19 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
43
43
  - `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`
44
44
 
45
45
  ## Process
46
- 1. Read BA spec + PRD/backlog.
46
+ 1. Read BA spec and PRD/backlog.
47
47
  2. Read `sdtk.config.json` for project stack assumptions (backend/frontend/db/auth).
48
- 3. If architecture output includes API contracts/flows, read and apply the split API rule sources before defining endpoints/flows:
48
+ 3. If architecture output includes API contracts/flows, read and apply:
49
49
  - `.claude/skills/references/YAML_CREATION_RULES.md`
50
50
  - `.claude/skills/references/API_DESIGN_FLOWCHART_CREATION_RULES.md`
51
- 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).
52
- 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.
53
- 6. For complex UI flow-action specs, use skill `/screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
51
+ - `governance/ai/core/SDTK_API_PATH_STYLE_POLICY.md` for canonical resource naming and multi-word path style
52
+ 4. If architecture output includes screen flow-action specs, read and apply `.claude/skills/references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
53
+ 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.
54
+ 6. For complex UI flow-action specs, use `/screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
54
55
  7. Define:
55
56
  - System components + data model
56
- - API endpoints and flows (if backend changes)
57
- - Screen layouts (if UI changes)
57
+ - API endpoints and flows
58
+ - Screen layouts
58
59
  - Security/authz decisions
59
60
  8. Create/update:
60
61
  - OpenAPI YAML + API endpoint markdown
@@ -63,8 +64,9 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
63
64
  - Database spec (if DB impact exists)
64
65
  - Flow-action spec and design layout (if UI impact exists)
65
66
  9. Ensure mapping UC/BR -> DB/API/screens and run output hygiene checks:
66
- - EN artifacts use English narrative text (except clearly marked original-language appendix blocks).
67
- - No mojibake/encoding corruption in markdown/yaml/txt outputs.
68
- 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).
69
- 11. Update shared state + Phase 3 checklist.
70
- 12. Handoff: suggest user run `/dev` to implement the design.
67
+ - EN artifacts use English narrative text (except clearly marked original-language appendix blocks)
68
+ - No mojibake/encoding corruption in markdown/yaml/txt outputs
69
+ 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.
70
+ 11. If anything is unclear, record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to PM.
71
+ 12. Update shared state + Phase 3 checklist.
72
+ 13. Handoff: suggest user run `/dev` to implement the design.
@@ -4,18 +4,18 @@ description: Business Analyst workflow for SDTK. Use when you need to turn PM in
4
4
  ---
5
5
 
6
6
  ## SDTK Pipeline Rules (always apply)
7
- 1. Pipeline: PM Initiation BA Analysis PM Planning Architecture Design Development + Review QA Validation
7
+ 1. Pipeline: PM Initiation -> BA Analysis -> PM Planning -> Architecture Design -> Development + Review -> QA Validation
8
8
  2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
9
- 3. If unclear: log OQ-xx in artifact, escalate to PM (PM asks user if needed)
10
- 4. Traceability: REQ BR/UC/AC design backlog code/tests QA
9
+ 3. If unclear: log OQ-xx in artifact, escalate to PM
10
+ 4. Traceability: REQ -> BR/UC/AC -> design -> backlog -> code/tests -> QA
11
11
  5. Code review must be COMPLETE before QA phase can start
12
- 6. Do not skip phases. If inputs missing, ask focused questions.
12
+ 6. Do not skip phases. If inputs are missing, ask focused questions.
13
13
 
14
14
  ## Prerequisites (verify before proceeding)
15
15
  Read QUALITY_CHECKLIST.md and verify:
16
16
  - Phase 1 PM Init gate must show all items [x] Done.
17
17
 
18
- If prerequisites NOT met: report which gate is missing, suggest user run `/pm` first.
18
+ If prerequisites are not met, report which gate is missing and suggest user run `/pm` first.
19
19
 
20
20
  ## Current Context
21
21
  - 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
26
26
  ## Input
27
27
  $ARGUMENTS
28
28
 
29
- If no arguments provided, read current feature context from SHARED_PLANNING.md.
29
+ If no arguments are provided, read current feature context from SHARED_PLANNING.md.
30
30
 
31
31
  # SDTK BA (Business Analysis)
32
32
 
@@ -34,7 +34,7 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
34
34
  - `docs/specs/BA_SPEC_[FEATURE_KEY].md`
35
35
 
36
36
  ## Process
37
- 1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` (and any source requirements).
37
+ 1. Read `docs/product/PROJECT_INITIATION_[FEATURE_KEY].md` and any source requirements.
38
38
  2. Produce:
39
39
  - Glossary
40
40
  - BR-xx (numbered)
@@ -42,8 +42,9 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
42
42
  - AC-xx (mapped to UC/BR)
43
43
  - NFR-xx
44
44
  - Risks + Open Questions
45
- - Traceability summary table (REQ UC/BR/AC)
46
- 3. If source requirements are VI/JP: preserve the original text and add a literal EN translation in appendices.
47
- 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).
48
- 5. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 2.
49
- 6. Handoff: suggest user run `/pm` to proceed with PRD planning.
45
+ - Traceability summary table (REQ -> UC/BR/AC)
46
+ 3. If source requirements are VI/JP, preserve the original text and add a literal EN translation in appendices.
47
+ 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.
48
+ 5. If anything is unclear, record OQ-xx in BA_SPEC "Open Questions" and escalate to PM.
49
+ 6. Update `SHARED_PLANNING.md` + `QUALITY_CHECKLIST.md` Phase 2.
50
+ 7. Handoff: suggest user run `/pm` to proceed with PRD planning.
@@ -4,18 +4,18 @@ description: QA workflow for SDTK. Use when you need to validate an implemented
4
4
  ---
5
5
 
6
6
  ## SDTK Pipeline Rules (always apply)
7
- 1. Pipeline: PM Initiation BA Analysis PM Planning Architecture Design Development + Review QA Validation
7
+ 1. Pipeline: PM Initiation -> BA Analysis -> PM Planning -> Architecture Design -> Development + Review -> QA Validation
8
8
  2. After completing phase work: update SHARED_PLANNING.md + QUALITY_CHECKLIST.md
9
- 3. If unclear: log OQ-xx in artifact, escalate to PM (PM asks user if needed)
10
- 4. Traceability: REQ BR/UC/AC design backlog code/tests QA
9
+ 3. If unclear: log OQ-xx in artifact, escalate to PM
10
+ 4. Traceability: REQ -> BR/UC/AC -> design -> backlog -> code/tests -> QA
11
11
  5. Code review must be COMPLETE before QA phase can start
12
- 6. Do not skip phases. If inputs missing, ask focused questions.
12
+ 6. Do not skip phases. If inputs are missing, ask focused questions.
13
13
 
14
14
  ## Prerequisites (verify before proceeding)
15
15
  Read QUALITY_CHECKLIST.md and verify:
16
16
  - Phase 4 DEV gate must show all items [x] Done (including code review completion).
17
17
 
18
- If prerequisites NOT met: report which gate is missing, suggest user run `/dev` first to complete code review.
18
+ If prerequisites are not met, report which gate is missing and suggest user run `/dev` first to complete code review.
19
19
 
20
20
  ## Current Context
21
21
  - 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`
26
26
  ## Input
27
27
  $ARGUMENTS
28
28
 
29
- If no arguments provided, read current feature context from SHARED_PLANNING.md.
29
+ If no arguments are provided, read current feature context from SHARED_PLANNING.md.
30
30
 
31
31
  # SDTK QA (Testing + Release Decision)
32
32
 
@@ -38,10 +38,11 @@ If no arguments provided, read current feature context from SHARED_PLANNING.md.
38
38
  ## Process
39
39
  1. Validate prerequisites: DEV phase completed + code review PASS.
40
40
  2. Create test strategy mapped to UC/AC.
41
- 3. If test-case specification artifact is required, invoke `/test-case-spec` and align counts/coverage with release testing scope.
42
- 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).
43
- 5. Execute/record results (unit/integration/e2e as applicable).
44
- 6. Record defects with severity and status.
45
- 7. Decide: APPROVED vs REJECTED (with reasons).
46
- 8. Update shared state + Phase 5 checklist.
47
- 9. Handoff: suggest user run `/pm` to finalize release status if approved.
41
+ 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.
42
+ 4. Apply `governance/ai/core/SDTK_BENCHMARK_QA_MODE_POLICY.md` for benchmark-mode verdict rules when no executable build exists.
43
+ 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.
44
+ 6. Execute/record results (unit/integration/e2e as applicable).
45
+ 7. Record defects with severity and status.
46
+ 8. Decide: APPROVED vs REJECTED (with reasons).
47
+ 9. Update shared state + Phase 5 checklist.
48
+ 10. Handoff: suggest user run `/pm` to finalize release status if approved.
@@ -5,10 +5,10 @@ description: Generate screen-based QA test-case markdown in Excel-aligned layout
5
5
 
6
6
  ## Required Inputs (read before proceeding)
7
7
  Read the following artifacts for the current feature:
8
- 1. `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md` screen/flow references
9
- 2. `docs/specs/BA_SPEC_[FEATURE_KEY].md` business rules, use cases
10
- 3. `docs/api/[FEATURE_KEY]_ENDPOINTS.md` API reference
11
- 4. `docs/specs/Q&A.md` or `docs/en/specs/Q&A.md` clarification source (when available)
8
+ 1. `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md` - screen/flow references
9
+ 2. `docs/specs/BA_SPEC_[FEATURE_KEY].md` - business rules, use cases
10
+ 3. `docs/api/[FEATURE_KEY]_ENDPOINTS.md` - API reference
11
+ 4. `docs/specs/Q&A.md` or `docs/en/specs/Q&A.md` - clarification source (when available)
12
12
 
13
13
  ## Input
14
14
  $ARGUMENTS
@@ -23,24 +23,23 @@ $ARGUMENTS
23
23
  ## Core Rules
24
24
  1. Apply `.claude/skills/references/TEST_CASE_CREATION_RULES.md` first.
25
25
  2. Keep section order fixed (Statistic -> Abbreviations -> Scope -> References -> Environment -> Coverage -> Screen-based UTC/ITC -> OQ -> STC/UAT note).
26
- 3. Use screen-first layout to mirror worksheet structure:
27
- - each screen can have `[SCREEN_KEY]_UTC` and `[SCREEN_KEY]_ITC`.
26
+ 3. Use screen-first layout to mirror worksheet structure.
28
27
  4. Keep one unified 18-column schema for UTC/ITC rows.
29
28
  5. Keep stable case IDs; do not renumber only because of regrouping.
30
- 6. Track unresolved decisions via `OQ-xx`.
29
+ 6. Track unresolved decisions via `OQ-xx` and keep benchmark-expected OQs explicitly OPEN per `governance/ai/core/SDTK_BENCHMARK_OQ_POLICY.md`.
31
30
 
32
31
  ## Procedure
33
32
  1. Resolve output path:
34
33
  - default `docs/qa/[FEATURE_KEY]_TEST_CASE.md`
35
34
  - use `docs/en/qa/...` only if the repo already follows `docs/en/**`.
36
- 2. Build/refresh `Statistic Summary (Excel-aligned)`:
37
- - include UT total, IT total, grand total.
35
+ 2. Build/refresh `Statistic Summary (Excel-aligned)` with UT total, IT total, and grand total.
38
36
  3. Build `Feature Coverage Matrix` from flow/action and API docs.
39
37
  4. Split UTC/ITC by screen sections (`screen-first`), not by test type only.
40
38
  5. Fill conflict/permission/error-path cases from Q&A decisions and API contracts.
41
39
  6. Record unresolved items in section `Open Questions`.
42
40
  7. Validate:
43
41
  - counts in summary match table rows
42
+ - 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
44
43
  - no placeholder tokens like `??`
45
44
  - out-of-scope boundaries are explicit
46
45
 
@@ -58,6 +57,5 @@ $ARGUMENTS
58
57
 
59
58
  ### Typical command
60
59
  ```bash
61
- python scripts/validate_test_case_spec.py \
62
- --file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
60
+ python scripts/validate_test_case_spec.py --file "docs/qa/[FEATURE_KEY]_TEST_CASE.md"
63
61
  ```
package/package.json CHANGED
@@ -1,46 +1,46 @@
1
1
  {
2
- "name": "sdtk-kit",
3
- "version": "0.3.4",
4
- "description": "SDTK CLI toolkit for deterministic software documentation workflows",
5
- "bin": {
6
- "sdtk": "./bin/sdtk.js"
7
- },
8
- "main": "src/index.js",
9
- "type": "commonjs",
10
- "files": [
11
- "bin/",
12
- "src/",
13
- "assets/"
14
- ],
15
- "scripts": {
16
- "test": "node -e \"console.log(\u0027No tests configured yet\u0027)\"",
17
- "build:payload": "powershell -ExecutionPolicy Bypass -File scripts/sync-toolkit-assets.ps1 \u0026\u0026 powershell -ExecutionPolicy Bypass -File scripts/build-toolkit-manifest.ps1",
18
- "verify:payload": "node -e \"require(\u0027./src/lib/toolkit-payload\u0027).verify()\"",
19
- "pack:smoke": "npm pack --dry-run",
20
- "pack:release": "npm pack",
21
- "prepublishOnly": "node -e \"require(\u0027./src/lib/toolkit-payload\u0027).verify()\""
22
- },
23
- "engines": {
24
- "node": "\u003e=18.13.0"
25
- },
26
- "keywords": [
27
- "sdtk",
28
- "cli",
29
- "documentation",
30
- "toolkit",
31
- "dockkit"
32
- ],
33
- "license": "MIT",
34
- "repository": {
35
- "type": "git",
36
- "url": "https://github.com/codexsdtk/sdtk-toolkit.git",
37
- "directory": "distribution/sdtk-cli"
38
- },
39
- "homepage": "https://agenttoolkits.dev",
40
- "bugs": {
41
- "url": "https://github.com/codexsdtk/sdtk-toolkit/issues"
42
- },
43
- "publishConfig": {
44
- "access": "public"
45
- }
2
+ "name": "sdtk-kit",
3
+ "version": "0.3.5",
4
+ "description": "SDTK CLI toolkit for deterministic software documentation workflows",
5
+ "bin": {
6
+ "sdtk": "./bin/sdtk.js"
7
+ },
8
+ "main": "src/index.js",
9
+ "type": "commonjs",
10
+ "files": [
11
+ "bin/",
12
+ "src/",
13
+ "assets/"
14
+ ],
15
+ "scripts": {
16
+ "test": "node -e \"console.log('No tests configured yet')\"",
17
+ "build:payload": "powershell -ExecutionPolicy Bypass -File scripts/sync-toolkit-assets.ps1 && powershell -ExecutionPolicy Bypass -File scripts/build-toolkit-manifest.ps1",
18
+ "verify:payload": "node -e \"require('./src/lib/toolkit-payload').verify()\"",
19
+ "pack:smoke": "npm pack --dry-run",
20
+ "pack:release": "npm pack",
21
+ "prepublishOnly": "node -e \"require('./src/lib/toolkit-payload').verify()\""
22
+ },
23
+ "engines": {
24
+ "node": ">=18.13.0"
25
+ },
26
+ "keywords": [
27
+ "sdtk",
28
+ "cli",
29
+ "documentation",
30
+ "toolkit",
31
+ "dockkit"
32
+ ],
33
+ "license": "MIT",
34
+ "repository": {
35
+ "type": "git",
36
+ "url": "https://github.com/codexsdtk/sdtk-toolkit.git",
37
+ "directory": "distribution/sdtk-cli"
38
+ },
39
+ "homepage": "https://agenttoolkits.dev",
40
+ "bugs": {
41
+ "url": "https://github.com/codexsdtk/sdtk-toolkit/issues"
42
+ },
43
+ "publishConfig": {
44
+ "access": "public"
45
+ }
46
46
  }