sdtk-kit 0.3.4 → 0.3.6

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.
Files changed (18) hide show
  1. package/assets/manifest/toolkit-bundle.manifest.json +35 -35
  2. package/assets/manifest/toolkit-bundle.sha256.txt +15 -15
  3. package/assets/toolkit/toolkit/skills/sdtk-api-doc/SKILL.md +5 -4
  4. package/assets/toolkit/toolkit/skills/sdtk-arch/SKILL.md +23 -16
  5. package/assets/toolkit/toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md +22 -5
  6. package/assets/toolkit/toolkit/skills/sdtk-ba/SKILL.md +7 -6
  7. package/assets/toolkit/toolkit/skills/sdtk-qa/SKILL.md +8 -7
  8. package/assets/toolkit/toolkit/skills/sdtk-screen-design-spec/SKILL.md +17 -10
  9. package/assets/toolkit/toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md +22 -5
  10. package/assets/toolkit/toolkit/skills/sdtk-test-case-spec/SKILL.md +4 -6
  11. package/assets/toolkit/toolkit/skills-claude/api-doc/SKILL.md +7 -6
  12. package/assets/toolkit/toolkit/skills-claude/arch/SKILL.md +20 -18
  13. package/assets/toolkit/toolkit/skills-claude/ba/SKILL.md +13 -12
  14. package/assets/toolkit/toolkit/skills-claude/qa/SKILL.md +14 -13
  15. package/assets/toolkit/toolkit/skills-claude/test-case-spec/SKILL.md +9 -11
  16. package/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md +22 -5
  17. package/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md +14 -14
  18. package/package.json +44 -44
package/assets/manifest/toolkit-bundle.manifest.json CHANGED
@@ -1,5 +1,8 @@
1
1
  {
2
- "buildTimestamp": "2026-03-07T02:40:24Z",
2
+ "version": "0.3.6",
3
+ "sourceCommit": "f15ad683ea08ad6974f2f6c6572a95411be3eac0",
4
+ "buildTimestamp": "2026-03-12T06:10:16Z",
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",
@@ -113,8 +116,8 @@
113
116
  },
114
117
  {
115
118
  "path": "toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md",
116
- "sha256": "b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0",
117
- "size": 5741
119
+ "sha256": "096c720bfb51cd44d2cf4241313f25874f9b6a1baa6874523a6ea8dcdb7a21b8",
120
+ "size": 6736
118
121
  },
119
122
  {
120
123
  "path": "toolkit/skills/sdtk-arch/references/FLOWCHART_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": "87ac00226478a8198ea9f218e221de8f49f34ccdae3fde2f26a5a1b6b7216feb",
135
+ "size": 3156
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",
@@ -183,8 +186,8 @@
183
186
  },
184
187
  {
185
188
  "path": "toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md",
186
- "sha256": "b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0",
187
- "size": 5741
189
+ "sha256": "096c720bfb51cd44d2cf4241313f25874f9b6a1baa6874523a6ea8dcdb7a21b8",
190
+ "size": 6736
188
191
  },
189
192
  {
190
193
  "path": "toolkit/skills/sdtk-screen-design-spec/references/numbering-rules.md",
@@ -203,8 +206,8 @@
203
206
  },
204
207
  {
205
208
  "path": "toolkit/skills/sdtk-screen-design-spec/SKILL.md",
206
- "sha256": "876d546e077ce451082792776360a4a309cc79a34c74234f1b55f80c56b159d1",
207
- "size": 2996
209
+ "sha256": "6e66a8c258a94be377d756cf80835968aa30a66ba200a8ac151558ab5bb675d3",
210
+ "size": 3771
208
211
  },
209
212
  {
210
213
  "path": "toolkit/skills/sdtk-test-case-spec/references/TEST_CASE_CREATION_RULES.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",
@@ -383,13 +386,13 @@
383
386
  },
384
387
  {
385
388
  "path": "toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md",
386
- "sha256": "b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0",
387
- "size": 5741
389
+ "sha256": "096c720bfb51cd44d2cf4241313f25874f9b6a1baa6874523a6ea8dcdb7a21b8",
390
+ "size": 6736
388
391
  },
389
392
  {
390
393
  "path": "toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md",
391
- "sha256": "afa6ac33875037495e28238a2c3fae2f4dcbb12f318c3cec0696fe45465cdf2a",
392
- "size": 4135
394
+ "sha256": "df87638e4e997beeee22f1e6a5cbbab83b6ed5fe2bf0ac5f3b816a1e852bba5d",
395
+ "size": 4386
393
396
  },
394
397
  {
395
398
  "path": "toolkit/templates/QUALITY_CHECKLIST.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
  }
package/assets/manifest/toolkit-bundle.sha256.txt CHANGED
@@ -17,44 +17,44 @@ 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
- b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0 toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md
23
+ 096c720bfb51cd44d2cf4241313f25874f9b6a1baa6874523a6ea8dcdb7a21b8 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
+ 87ac00226478a8198ea9f218e221de8f49f34ccdae3fde2f26a5a1b6b7216feb 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
- b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0 toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md
37
+ 096c720bfb51cd44d2cf4241313f25874f9b6a1baa6874523a6ea8dcdb7a21b8 toolkit/skills/sdtk-screen-design-spec/references/FLOW_ACTION_SPEC_CREATION_RULES.md
38
38
  4edd3318634fbc142f1ce3161fc3ac93d901a6bb7f0add1d1bed7fc25293c4d9 toolkit/skills/sdtk-screen-design-spec/references/numbering-rules.md
39
39
  b54b14cc75c02c3fe9f89547b3f09baf1d7d036ef5f3d9f40487516e22351c45 toolkit/skills/sdtk-screen-design-spec/scripts/renumber_flow_action_spec_global.py
40
40
  ae0bc9b120c19a142f10cc79168a8f7d6bf8a37e48341fc16cbc74bbdc2e692c toolkit/skills/sdtk-screen-design-spec/scripts/validate_flow_action_spec_numbering.py
41
- 876d546e077ce451082792776360a4a309cc79a34c74234f1b55f80c56b159d1 toolkit/skills/sdtk-screen-design-spec/SKILL.md
41
+ 6e66a8c258a94be377d756cf80835968aa30a66ba200a8ac151558ab5bb675d3 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
@@ -74,8 +74,8 @@ e8d3554fc4893a8a57fbf006e58f37f21347de5f31ce02f0717e97d29b387eea toolkit/templa
74
74
  7c21e74f5eee712c6b65665b4f10483ed008113186a92dc0a4673ce1fcd3ef5c toolkit/templates/docs/qa/TEST_CASE_CREATION_RULES.md
75
75
  4b64a123d6e22edefa17a23a1eff766cf612ec5fa2f78b34bf50eecb39abf06a toolkit/templates/docs/qa/TEST_CASE_TEMPLATE.md
76
76
  3b5f911d5e0eb042efc388ef3a441285a57d2dc02ae032d080934495e2d06f4d toolkit/templates/docs/specs/BA_SPEC_TEMPLATE.md
77
- b1ed7f7cad8f4098bd305fa9aaea6cdf1c78cf909284547baa50235fa677d8c0 toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md
78
- afa6ac33875037495e28238a2c3fae2f4dcbb12f318c3cec0696fe45465cdf2a toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md
77
+ 096c720bfb51cd44d2cf4241313f25874f9b6a1baa6874523a6ea8dcdb7a21b8 toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md
78
+ df87638e4e997beeee22f1e6a5cbbab83b6ed5fe2bf0ac5f3b816a1e852bba5d toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md
79
79
  f9dc0d49ceeeb8814d77670e43f09b5221f46d406fb1e89eb575c1ab39bc022a toolkit/templates/QUALITY_CHECKLIST.md
80
80
  0ccb7a0509cf92aa91ebea95996dfffd5b52edd6ab4bbefbb827e4ed495abc31 toolkit/templates/README.md
81
81
  2b5d4d10019e3c9b3219d92b8123acc85872d9c76230107206e7a270a5ece5a2 toolkit/templates/SHARED_PLANNING.md
package/assets/toolkit/toolkit/skills/sdtk-api-doc/SKILL.md CHANGED
@@ -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).
package/assets/toolkit/toolkit/skills/sdtk-arch/SKILL.md CHANGED
@@ -17,28 +17,35 @@ 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`.
28
- 7. Define:
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 UI-scope features, enforce this generation sequence:
29
+ a. Generate/update `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` first (using `sdtk-design-layout`).
30
+ b. Then generate/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md` (using `sdtk-screen-design-spec`).
31
+ c. 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`).
32
+ 7. For complex UI flow-action specs, use `sdtk-screen-design-spec` to build/update `docs/specs/[FEATURE_KEY]_FLOW_ACTION_SPEC.md`.
33
+ 8. Define:
29
34
  - System components + data model
30
- - API endpoints and flows (if backend changes)
31
- - Screen layouts (if UI changes)
35
+ - API endpoints and flows
36
+ - Screen layouts
32
37
  - Security/authz decisions
33
- 8. Create/update:
38
+ 9. Create/update:
34
39
  - OpenAPI YAML + API endpoint markdown
35
40
  - API flow list
36
41
  - API design detail spec (when `orchestration.apiDesignDetailMode` is `auto/on`)
37
42
  - Database spec (if DB impact exists)
38
- - Flow-action spec and design layout (if UI impact exists)
39
- 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 ...`.
43
+ - Design layout (if UI impact exists) - must be created before flow-action spec
44
+ - Flow-action spec (if UI impact exists) - must reference design layout as fallback source
45
+ 10. Ensure mapping UC/BR -> DB/API/screens and run output hygiene checks:
46
+ - EN artifacts use English narrative text (except clearly marked original-language appendix blocks)
47
+ - No mojibake/encoding corruption in markdown/yaml/txt outputs
48
+ 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.
49
+ 12. If anything is unclear, record OQ-xx in ARCH_DESIGN "Open Questions" and escalate to `@pm` for a decision.
50
+ 13. Update shared state + Phase 3 checklist.
51
+ 14. Handoff: `@dev please implement ...`.
package/assets/toolkit/toolkit/skills/sdtk-arch/references/FLOW_ACTION_SPEC_CREATION_RULES.md CHANGED
@@ -32,9 +32,9 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
32
32
 
33
33
  - Every table must include a `No` column (sequential numbering).
34
34
  - Use stable headers for action tables:
35
- - `No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
35
+ - `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
36
36
  - Use stable headers for API mapping tables:
37
- - `No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes`
37
+ - `No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes`
38
38
  - Use stable headers for screen mapping:
39
39
  - `No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs`
40
40
  - 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
43
43
  ### 3.1 Language and Encoding Standards (EN Artifacts)
44
44
 
45
45
  - For EN artifacts (`docs/en/**` or explicitly requested EN version), narrative text must be English.
46
- - JP labels can remain only in JP-specific fields/columns (`JP Item Name`, `項目名`, source captions).
46
+ - 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.
47
47
  - Do not leave mixed-language fragments in one sentence/cell (for example VI+EN mixed text).
48
48
  - If original VI/JP text is required for traceability, keep it in a clearly marked appendix block (`Original Text`), then provide EN translation.
49
49
  - Save files as UTF-8 and avoid mojibake/broken glyphs (`�`, `ↁE`, garbled sequences).
@@ -69,12 +69,29 @@ For each screen section:
69
69
  - Provide metadata:
70
70
  - official screen name
71
71
  - Screen ID
72
- - design source URL (for example Figma)
73
- - Embed one representative image per screen.
72
+ - Design Source Type
73
+ - Design Source Reference
74
+ - Embed one representative image per screen (from Figma, screenshot, or generated layout).
74
75
  - Provide one action table.
75
76
  - Provide one API mapping table.
76
77
  - If a screen has dialogs, create explicit dialog sub-sections with their own tables and API mapping.
77
78
 
79
+ ## 5.1 Design Source Modes
80
+
81
+ Each screen section must declare a design source using one of these modes:
82
+
83
+ | Mode | When | Design Source Reference |
84
+ |------|------|----------------------|
85
+ | `source-backed` | Figma URL or screenshot is available | Figma URL or screenshot path |
86
+ | `generated-draft` | No Figma/screenshot, but feature has UI scope | Section reference in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` |
87
+ | `none` | Feature has no UI scope for this screen | State `N/A - no UI scope` |
88
+
89
+ Rules:
90
+ - For UI-scope features, `none` is only valid when the specific screen truly has no visual layout.
91
+ - When using `generated-draft`, the `DESIGN_LAYOUT_[FEATURE_KEY].md` must exist before the flow-action spec is finalized.
92
+ - The flow-action spec and the design-layout doc must remain separate documents.
93
+ - When Figma becomes available later, update the source mode from `generated-draft` to `source-backed`.
94
+
78
95
  ## 6. API Traceability Rules
79
96
 
80
97
  - Every actionable UI event that changes state must map to a write API.
package/assets/toolkit/toolkit/skills/sdtk-ba/SKILL.md CHANGED
@@ -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`.
package/assets/toolkit/toolkit/skills/sdtk-qa/SKILL.md CHANGED
@@ -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.
package/assets/toolkit/toolkit/skills/sdtk-screen-design-spec/SKILL.md CHANGED
@@ -15,29 +15,36 @@ description: Create/update screen flow-action specifications from requirement so
15
15
  ## Required Inputs
16
16
  - Feature key/name
17
17
  - Primary requirement sources (BA spec, architecture, customer design docs)
18
- - Screen source references (Figma URLs and/or requirement screenshots)
18
+ - Screen source references, using one of these design source modes:
19
+ - `source-backed`: Figma URLs and/or requirement screenshots
20
+ - `generated-draft`: generated layout from `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` (used when no Figma/screenshot is available for a UI-scope feature)
19
21
  - API endpoint source (`docs/api/[FEATURE_KEY]_ENDPOINTS.md`) when available
20
22
 
21
23
  ## Process
22
24
  1. Read requirement sources and identify in-scope screens, dialogs, and transitions.
23
25
  2. Read and apply rules from `./references/FLOW_ACTION_SPEC_CREATION_RULES.md`.
24
- 3. Build/update section `Feature overview` and `Screen flow action` (PlantUML).
25
- 4. For each screen/dialog:
26
- - Add metadata (screen ID, source link)
27
- - Add screen image reference
26
+ 3. Determine design source mode per screen:
27
+ - If Figma URL or screenshot exists: use `source-backed`.
28
+ - 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.
29
+ - If screen has no UI scope: use `none`.
30
+ 4. Build/update section `Feature overview` and `Screen flow action` (PlantUML).
31
+ 5. For each screen/dialog:
32
+ - Add metadata (screen ID, Design Source Type, Design Source Reference)
33
+ - Add screen image reference (from Figma, screenshot, or generated layout)
28
34
  - Add UI item/action table with `No` column
29
35
  - Add API mapping table (trigger -> API -> data usage)
30
- 5. Build/update `System processing flow` from use-case and process sources.
31
- 6. Build/update `Open questions` for unresolved behavior/API/data points.
32
- 7. Build/update `Screen - API Mapping` summary section.
33
- 8. Validate:
36
+ 6. Build/update `System processing flow` from use-case and process sources.
37
+ 7. Build/update `Open questions` for unresolved behavior/API/data points.
38
+ 8. Build/update `Screen - API Mapping` summary section.
39
+ 9. Validate:
34
40
  - global numbering consistency (no screen-level reset)
35
41
  - no broken image paths
36
42
  - PlantUML renderability
37
43
  - consistency with API endpoints spec
38
44
  - EN artifact hygiene (no VI leftovers, no mojibake, no merged heading lines)
39
45
  - for legacy specs with per-screen reset numbering: run renumber migration first
40
- 9. Update document history and handoff to ARCH/DEV.
46
+ - every UI-scope screen declares a Design Source Type (`source-backed` or `generated-draft`)
47
+ 10. Update document history and handoff to ARCH/DEV.
41
48
 
42
49
  ## Rule References
43
50
  - 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 CHANGED
@@ -32,9 +32,9 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
32
32
 
33
33
  - Every table must include a `No` column (sequential numbering).
34
34
  - Use stable headers for action tables:
35
- - `No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
35
+ - `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
36
36
  - Use stable headers for API mapping tables:
37
- - `No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes`
37
+ - `No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes`
38
38
  - Use stable headers for screen mapping:
39
39
  - `No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs`
40
40
  - 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
43
43
  ### 3.1 Language and Encoding Standards (EN Artifacts)
44
44
 
45
45
  - For EN artifacts (`docs/en/**` or explicitly requested EN version), narrative text must be English.
46
- - JP labels can remain only in JP-specific fields/columns (`JP Item Name`, `項目名`, source captions).
46
+ - 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.
47
47
  - Do not leave mixed-language fragments in one sentence/cell (for example VI+EN mixed text).
48
48
  - If original VI/JP text is required for traceability, keep it in a clearly marked appendix block (`Original Text`), then provide EN translation.
49
49
  - Save files as UTF-8 and avoid mojibake/broken glyphs (`�`, `ↁE`, garbled sequences).
@@ -69,12 +69,29 @@ For each screen section:
69
69
  - Provide metadata:
70
70
  - official screen name
71
71
  - Screen ID
72
- - design source URL (for example Figma)
73
- - Embed one representative image per screen.
72
+ - Design Source Type
73
+ - Design Source Reference
74
+ - Embed one representative image per screen (from Figma, screenshot, or generated layout).
74
75
  - Provide one action table.
75
76
  - Provide one API mapping table.
76
77
  - If a screen has dialogs, create explicit dialog sub-sections with their own tables and API mapping.
77
78
 
79
+ ## 5.1 Design Source Modes
80
+
81
+ Each screen section must declare a design source using one of these modes:
82
+
83
+ | Mode | When | Design Source Reference |
84
+ |------|------|----------------------|
85
+ | `source-backed` | Figma URL or screenshot is available | Figma URL or screenshot path |
86
+ | `generated-draft` | No Figma/screenshot, but feature has UI scope | Section reference in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` |
87
+ | `none` | Feature has no UI scope for this screen | State `N/A - no UI scope` |
88
+
89
+ Rules:
90
+ - For UI-scope features, `none` is only valid when the specific screen truly has no visual layout.
91
+ - When using `generated-draft`, the `DESIGN_LAYOUT_[FEATURE_KEY].md` must exist before the flow-action spec is finalized.
92
+ - The flow-action spec and the design-layout doc must remain separate documents.
93
+ - When Figma becomes available later, update the source mode from `generated-draft` to `source-backed`.
94
+
78
95
  ## 6. API Traceability Rules
79
96
 
80
97
  - Every actionable UI event that changes state must map to a write API.
package/assets/toolkit/toolkit/skills/sdtk-test-case-spec/SKILL.md CHANGED
@@ -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
-
package/assets/toolkit/toolkit/skills-claude/api-doc/SKILL.md CHANGED
@@ -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).
package/assets/toolkit/toolkit/skills-claude/arch/SKILL.md CHANGED
@@ -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.
package/assets/toolkit/toolkit/skills-claude/ba/SKILL.md CHANGED
@@ -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.
package/assets/toolkit/toolkit/skills-claude/qa/SKILL.md CHANGED
@@ -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.
package/assets/toolkit/toolkit/skills-claude/test-case-spec/SKILL.md CHANGED
@@ -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/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_CREATION_RULES.md CHANGED
@@ -32,9 +32,9 @@ If a section is not in scope, keep the section and mark explicitly as `N/A` with
32
32
 
33
33
  - Every table must include a `No` column (sequential numbering).
34
34
  - Use stable headers for action tables:
35
- - `No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
35
+ - `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
36
36
  - Use stable headers for API mapping tables:
37
- - `No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes`
37
+ - `No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes`
38
38
  - Use stable headers for screen mapping:
39
39
  - `No | Screen (section) | Screen ID | Read/Search APIs | Write APIs | Notes / Q&A refs`
40
40
  - 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
43
43
  ### 3.1 Language and Encoding Standards (EN Artifacts)
44
44
 
45
45
  - For EN artifacts (`docs/en/**` or explicitly requested EN version), narrative text must be English.
46
- - JP labels can remain only in JP-specific fields/columns (`JP Item Name`, `項目名`, source captions).
46
+ - 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.
47
47
  - Do not leave mixed-language fragments in one sentence/cell (for example VI+EN mixed text).
48
48
  - If original VI/JP text is required for traceability, keep it in a clearly marked appendix block (`Original Text`), then provide EN translation.
49
49
  - Save files as UTF-8 and avoid mojibake/broken glyphs (`�`, `ↁE`, garbled sequences).
@@ -69,12 +69,29 @@ For each screen section:
69
69
  - Provide metadata:
70
70
  - official screen name
71
71
  - Screen ID
72
- - design source URL (for example Figma)
73
- - Embed one representative image per screen.
72
+ - Design Source Type
73
+ - Design Source Reference
74
+ - Embed one representative image per screen (from Figma, screenshot, or generated layout).
74
75
  - Provide one action table.
75
76
  - Provide one API mapping table.
76
77
  - If a screen has dialogs, create explicit dialog sub-sections with their own tables and API mapping.
77
78
 
79
+ ## 5.1 Design Source Modes
80
+
81
+ Each screen section must declare a design source using one of these modes:
82
+
83
+ | Mode | When | Design Source Reference |
84
+ |------|------|----------------------|
85
+ | `source-backed` | Figma URL or screenshot is available | Figma URL or screenshot path |
86
+ | `generated-draft` | No Figma/screenshot, but feature has UI scope | Section reference in `docs/design/DESIGN_LAYOUT_[FEATURE_KEY].md` |
87
+ | `none` | Feature has no UI scope for this screen | State `N/A - no UI scope` |
88
+
89
+ Rules:
90
+ - For UI-scope features, `none` is only valid when the specific screen truly has no visual layout.
91
+ - When using `generated-draft`, the `DESIGN_LAYOUT_[FEATURE_KEY].md` must exist before the flow-action spec is finalized.
92
+ - The flow-action spec and the design-layout doc must remain separate documents.
93
+ - When Figma becomes available later, update the source mode from `generated-draft` to `source-backed`.
94
+
78
95
  ## 6. API Traceability Rules
79
96
 
80
97
  - Every actionable UI event that changes state must map to a write API.
package/assets/toolkit/toolkit/templates/docs/specs/FLOW_ACTION_SPEC_TEMPLATE.md CHANGED
@@ -66,26 +66,26 @@ B --> C : open dialog
66
66
  ## 3) Screen layout spec by flow action
67
67
 
68
68
  > Standard item table format:
69
- > `No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
69
+ > `No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note`
70
70
 
71
71
  ### 3.1 Screen A
72
72
 
73
73
  Information:
74
- - JP: TBD
75
74
  - Screen ID: SCR-01
76
- - Figma URL: TBD
75
+ - Design Source Type: source-backed | generated-draft | none
76
+ - Design Source Reference: Figma URL | screenshot path | `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md` section reference | `N/A - no UI scope`
77
77
 
78
78
  Screen image:
79
79
  ![3.1 Screen A](assets/{{FEATURE_SNAKE}}/screens/screen_3_1_screen_a.png)
80
80
 
81
- | No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
82
- | ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
83
- | 1 | Item A (JP) | Item A | Button | - | - | - | - | Click | TBD | TBD |
84
- | 2 | Item B (JP) | Item B | Input | string | column_a | 100 | empty | Input | TBD | TBD |
81
+ | No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
82
+ | ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- |
83
+ | 1 | Item A | Button | - | - | - | - | Click | TBD | TBD |
84
+ | 2 | Item B | Input | string | column_a | 100 | empty | Input | TBD | TBD |
85
85
 
86
86
  #### API Mapping (Draft)
87
87
 
88
- | No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes |
88
+ | No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes |
89
89
  | ---: | --- | --- | --- | --- |
90
90
  | 1 | Initial load | Main area | `GET /api/...` | Load initial dataset |
91
91
  | 2 | Click search | No 1 | `POST /api/.../search` | Refresh grid |
@@ -95,20 +95,20 @@ Screen image:
95
95
  ### 3.2 Screen B
96
96
 
97
97
  Information:
98
- - JP: TBD
99
98
  - Screen ID: SCR-02
100
- - Figma URL: TBD
99
+ - Design Source Type: source-backed | generated-draft | none
100
+ - Design Source Reference: Figma URL | screenshot path | `docs/design/DESIGN_LAYOUT_{{FEATURE_KEY}}.md` section reference | `N/A - no UI scope`
101
101
 
102
102
  Screen image:
103
103
  ![3.2 Screen B](assets/{{FEATURE_SNAKE}}/screens/screen_3_2_screen_b.png)
104
104
 
105
- | No | JP Item Name | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
106
- | ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
107
- | 3 | Item C (JP) | Item C | Toggle | boolean | flag_a | - | false | Toggle | TBD | TBD |
105
+ | No | Item Name | Item Type | Attribute | DB Column | Size | Default Value | Action | Description | Note |
106
+ | ---: | --- | --- | --- | --- | --- | --- | --- | --- | --- |
107
+ | 3 | Item C | Toggle | boolean | flag_a | - | false | Toggle | TBD | TBD |
108
108
 
109
109
  #### API Mapping (Draft)
110
110
 
111
- | No | Trigger/When | UI item (No / JP Item Name) | API to call | Data usage / Notes |
111
+ | No | Trigger/When | UI item (No / Item Name) | API to call | Data usage / Notes |
112
112
  | ---: | --- | --- | --- | --- |
113
113
  | 1 | Change mode | No 3 | `POST /api/.../edit/{uuid}` | Persist mode |
114
114
 
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.6",
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
  }