@anhth2/spec-driven-dev-plugin 0.7.0 → 0.9.0

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 (96) hide show
  1. package/ARCHITECTURE.md +6 -2
  2. package/bin/index.js +105 -0
  3. package/commands/debug.md +189 -1
  4. package/commands/debug.tmpl +16 -0
  5. package/commands/define-product.md +94 -1
  6. package/commands/fix-bug.md +190 -1
  7. package/commands/fix-bug.tmpl +17 -0
  8. package/commands/generate-bdd.md +314 -14
  9. package/commands/generate-bdd.tmpl +220 -13
  10. package/commands/generate-code.md +191 -3
  11. package/commands/generate-code.tmpl +97 -2
  12. package/commands/generate-design-spec.md +811 -0
  13. package/commands/generate-design-spec.tmpl +399 -0
  14. package/commands/generate-prd.md +133 -1
  15. package/commands/generate-prd.tmpl +39 -0
  16. package/commands/generate-spec-manifest.md +576 -0
  17. package/commands/generate-spec-manifest.tmpl +164 -0
  18. package/commands/generate-tech-docs.md +116 -2
  19. package/commands/generate-tech-docs.tmpl +22 -1
  20. package/commands/generate-tests.md +94 -1
  21. package/commands/learn.md +554 -0
  22. package/commands/learn.tmpl +63 -0
  23. package/commands/propose-scenario.md +521 -0
  24. package/commands/propose-scenario.tmpl +109 -0
  25. package/commands/refine-prd.md +94 -1
  26. package/commands/report-bug.md +543 -0
  27. package/commands/report-bug.tmpl +131 -0
  28. package/commands/review-code.md +190 -1
  29. package/commands/review-code.tmpl +17 -0
  30. package/commands/review-context.md +134 -1
  31. package/commands/review-context.tmpl +40 -0
  32. package/commands/review-tech-docs.md +176 -5
  33. package/commands/review-tech-docs.tmpl +82 -4
  34. package/commands/run-tests.md +119 -1
  35. package/commands/run-tests.tmpl +25 -0
  36. package/commands/setup-ai-first.md +142 -4
  37. package/commands/setup-ai-first.tmpl +135 -3
  38. package/commands/smoke-test.md +94 -1
  39. package/commands/sync.md +405 -0
  40. package/commands/sync.tmpl +345 -0
  41. package/commands/update-framework.md +211 -0
  42. package/commands/update-framework.tmpl +151 -0
  43. package/commands/validate-traces.md +152 -3
  44. package/commands/validate-traces.tmpl +58 -2
  45. package/core/FRAMEWORK_VERSION +1 -1
  46. package/core/commands/debug.md +189 -1
  47. package/core/commands/define-product.md +94 -1
  48. package/core/commands/fix-bug.md +190 -1
  49. package/core/commands/generate-bdd.md +314 -14
  50. package/core/commands/generate-code.md +191 -3
  51. package/core/commands/generate-design-spec.md +811 -0
  52. package/core/commands/generate-prd.md +133 -1
  53. package/core/commands/generate-spec-manifest.md +576 -0
  54. package/core/commands/generate-tech-docs.md +116 -2
  55. package/core/commands/generate-tests.md +94 -1
  56. package/core/commands/learn.md +554 -0
  57. package/core/commands/propose-scenario.md +521 -0
  58. package/core/commands/refine-prd.md +94 -1
  59. package/core/commands/report-bug.md +543 -0
  60. package/core/commands/review-code.md +190 -1
  61. package/core/commands/review-context.md +134 -1
  62. package/core/commands/review-tech-docs.md +176 -5
  63. package/core/commands/run-tests.md +119 -1
  64. package/core/commands/setup-ai-first.md +142 -4
  65. package/core/commands/smoke-test.md +94 -1
  66. package/core/commands/sync.md +405 -0
  67. package/core/commands/update-framework.md +211 -0
  68. package/core/commands/validate-traces.md +152 -3
  69. package/core/skills/code/SKILL.md +101 -2
  70. package/core/skills/debug/SKILL.md +108 -3
  71. package/core/skills/design-spec/SKILL.md +507 -0
  72. package/core/skills/discovery/SKILL.md +94 -1
  73. package/core/skills/prd/SKILL.md +14 -2
  74. package/core/skills/setup-ai-first/SKILL.md +7 -1
  75. package/core/skills/spec/SKILL.md +14 -2
  76. package/core/skills/test/SKILL.md +195 -3
  77. package/core/steps/capture-lesson.md +79 -0
  78. package/core/steps/context-loader.md +87 -0
  79. package/core/steps/report-footer.md +7 -1
  80. package/core/templates/design-spec.template.md +209 -0
  81. package/core/templates/project-context.yaml +40 -0
  82. package/package.json +1 -1
  83. package/skills/code/SKILL.md +101 -2
  84. package/skills/debug/SKILL.md +108 -3
  85. package/skills/design-spec/SKILL.md +507 -0
  86. package/skills/design-spec/SKILL.tmpl +95 -0
  87. package/skills/discovery/SKILL.md +94 -1
  88. package/skills/prd/SKILL.md +14 -2
  89. package/skills/setup-ai-first/SKILL.md +7 -1
  90. package/skills/spec/SKILL.md +14 -2
  91. package/skills/test/SKILL.md +195 -3
  92. package/steps/capture-lesson.md +79 -0
  93. package/steps/context-loader.md +87 -0
  94. package/steps/report-footer.md +7 -1
  95. package/templates/design-spec.template.md +209 -0
  96. package/templates/project-context.yaml +40 -0
@@ -0,0 +1,507 @@
1
+ ---
2
+ description: Generates a Design Specification document for FE or App platforms from a Business PRD. Trigger when: "/generate-design-spec", "tạo design spec", "generate design spec", "viết design spec", "tạo tài liệu thiết kế UI", "generate UI spec", "cần design spec cho", "tôi muốn spec UI", "tài liệu cho FE", "tài liệu cho app".
3
+ ---
4
+
5
+ # /generate-design-spec — Generate Design Specification (FE / App)
6
+
7
+ This skill generates a platform-specific Design Spec from a Business PRD.
8
+ Design Spec captures screen-level UI requirements, component inventory, platform interactions,
9
+ and design-level AC-UI for PO + Designer sign-off — separate from the business-level PRD.
10
+
11
+ **Supported platforms:** web (react / nextjs / vue / angular), app (flutter / react-native / ios-swiftui / android-compose)
12
+ **Not supported:** backend services — API contracts belong in the Business PRD.
13
+
14
+ ---
15
+
16
+ ## Gate
17
+
18
+ <!-- Directory: specs/prd/**/*.md -->
19
+ # Gate — Universal Entry Procedure
20
+
21
+ Every command must execute this gate before proceeding with its specific logic.
22
+
23
+ ## Step 0 — Sub-Agent Mode Check
24
+
25
+ Before anything else, check if `$ARGUMENTS` is a JSON payload from an orchestrator:
26
+
27
+ 1. Attempt to parse `$ARGUMENTS` as JSON.
28
+ 2. If it parses successfully **and** contains `"_agent_mode": true`:
29
+ - **Skip Steps 1, 2, and 3 of this Gate entirely.**
30
+ - Set target file = `payload.target_file`
31
+ - Set loaded context = `payload.context` (do NOT run context-loader.md)
32
+ - Set UC scope = `payload.uc_id` (process only this UC)
33
+ - Set line range = `payload.uc_section` (read only that PRD section)
34
+ - Proceed directly to the command-specific logic.
35
+ 3. If `$ARGUMENTS` is not JSON or `_agent_mode` is absent → continue to Step 1 (normal mode).
36
+
37
+ ## Step 0-B — Model Check
38
+
39
+ *Skip this step if `_agent_mode: true` (sub-agent — orchestrator already validated).*
40
+
41
+ Complex generation and review commands require strong reasoning.
42
+ Using a smaller model risks missed edge cases, incomplete spec analysis, and architecture violations.
43
+
44
+ Display and wait for response:
45
+
46
+ ```
47
+ ⚙️ MODEL CHECK
48
+ ──────────────────────────────────────────────────────────────────
49
+ Recommended : claude-opus-4 (or latest Opus model)
50
+ Why needed : Spec analysis, architecture review, code generation
51
+ require deep reasoning. Smaller models miss edge cases.
52
+
53
+ To switch in Claude Code:
54
+ • Settings → Model → select "claude-opus"
55
+ • or: /model → choose claude-opus
56
+
57
+ Running on claude-opus?
58
+ Y — yes, on claude-opus → proceed
59
+ S — skip check (I accept lower quality risk with current model)
60
+ ──────────────────────────────────────────────────────────────────
61
+ ```
62
+
63
+ - "Y" → proceed to Step 1.
64
+ - "S" → proceed to Step 1 (user accepts risk, add ⚠️ to final report).
65
+ - "N" or anything else → **STOP.** Output: "Please switch to claude-opus, then re-run this command."
66
+
67
+ ## Step 1 — Resolve Target File
68
+
69
+ 1. If `$ARGUMENTS` is provided and points to an existing file → use it directly as the target.
70
+ 2. If `$ARGUMENTS` is a UC-ID, ticket ID, or partial name → search for matching files in the relevant directory.
71
+ 3. If `$ARGUMENTS` is empty or no match found:
72
+ - List files in the relevant directory for this command (e.g., `specs/prd/**/*.md` for PRD commands, `specs/bdd/**/*.feature` for BDD commands).
73
+ - Present the list to the user and ask: "Which file do you want to work with? (Enter number or filename)"
74
+ - Wait for user selection before continuing.
75
+
76
+ ## Step 2 — Execute Context Loader
77
+
78
+ Load all project context by following the procedure in `steps/context-loader.md`.
79
+ Store all loaded context in memory for use throughout this command session.
80
+
81
+ ## Step 3 — CHECKPOINT
82
+
83
+ After completing Steps 1 and 2, display a summary and wait for confirmation:
84
+
85
+ ```
86
+ CHECKPOINT
87
+ -----------
88
+ Target : {resolved file path}
89
+ Project : {project.name from project-context.yaml}
90
+ Tech stack : {language} / {framework}
91
+ Module : {module if set, else "not configured"}
92
+ Domains : {comma-separated domain list}
93
+
94
+ Proceed? (Y/N)
95
+ ```
96
+
97
+ Wait for explicit "Y" or "N" from the user before continuing.
98
+ - "Y" → proceed to the command-specific steps below.
99
+ - "N" → stop and ask what the user wants to change.
100
+
101
+
102
+ ---
103
+
104
+ ## Context
105
+
106
+ # Context Loader — Load All Project Context
107
+
108
+ Execute these steps in order. Store everything in memory for the duration of the command session.
109
+
110
+ **Priority guide (anti-lost-in-middle):**
111
+ - Steps 1–2 are PROJECT-CONFIG — loaded first, resolve all paths and metadata.
112
+ - Step 3 is CRITICAL — architecture + coding standards, the highest-priority facts for generation.
113
+ - Step 4 is SAFETY — data protection rules, enforced silently for the entire session.
114
+ - Steps 5–6 are DOMAIN KNOWLEDGE — terminology and entity definitions.
115
+ - Step 7 is the WORKING MEMORY RECAP — locks critical facts into the top of working memory.
116
+
117
+ ---
118
+
119
+ ## Step 1 — [PROJECT-CONFIG] Load project-context.yaml
120
+
121
+ Read `.agent/project-context.yaml`. Extract and store:
122
+
123
+ **Tech Stack:**
124
+ - `tech_stack.language` → active language (e.g., Java 17, TypeScript, C#, Go)
125
+ - `tech_stack.framework` → active framework (e.g., Spring Boot 3.2, Angular 17, .NET 8)
126
+ - `tech_stack.build_tool` → build tool (e.g., Maven, npm, dotnet, go)
127
+ - `tech_stack.test_framework` → test framework (e.g., JUnit 5 + Mockito, Jest, xUnit)
128
+ - `tech_stack.database` → database (e.g., PostgreSQL, MySQL, MongoDB)
129
+ - `tech_stack.module` → active module profile (e.g., java-spring, angular, dotnet, golang, context-engineering)
130
+
131
+ **Conventions:**
132
+ - `conventions.build_command` → how to compile/build
133
+ - `conventions.test_command` → how to run tests
134
+ - `conventions.service_run` → how to start the service
135
+ - `conventions.ticket_prefix` → ticket ID prefix (e.g., PROJ, FEAT, UC)
136
+
137
+ **Domains:**
138
+ - `domains` → list of active business domains
139
+
140
+ **Paths (if present):**
141
+ - `paths.specs_dir` → BDD specs root
142
+ - `paths.prd_dir` → PRD documents root
143
+ - `paths.refinement_dir` → findings/review output dir
144
+ - `paths.product_definitions_dir` → product definitions root
145
+ - `paths.domain_knowledge_dir` → domain knowledge root
146
+ - `paths.business_dictionary` → path to business-dictionary.md
147
+ - `paths.core_entities` → path to core-entities.md
148
+ - `paths.tech_docs_dir` → technical documentation root
149
+ - `paths.trace_dir` → trace state directory
150
+ - `paths.design_spec_dir` → Design Spec documents root (FE/App only)
151
+
152
+ If `paths` section is absent, use these defaults:
153
+ - `specs_dir` = `specs/bdd`
154
+ - `prd_dir` = `specs/prd`
155
+ - `refinement_dir` = `.agent/review`
156
+ - `product_definitions_dir` = `specs/product-definition`
157
+ - `domain_knowledge_dir` = `specs/domain-knowledge`
158
+ - `business_dictionary` = `specs/domain-knowledge/business-dictionary.md`
159
+ - `core_entities` = `specs/domain-knowledge/core-entities.md`
160
+ - `tech_docs_dir` = `specs/tech-docs`
161
+ - `trace_dir` = `.trace`
162
+ - `design_spec_dir` = `specs/design-spec`
163
+
164
+ If `tech_stack.module` is set, also load `.agent/modules/{module}/stack-profile.yaml` if it exists.
165
+
166
+ ---
167
+
168
+ ## Step 1.5 — [SERVICE ROUTING] Resolve service paths (umbrella mode)
169
+
170
+ *Skip this step entirely if `setup.mode` is not `"umbrella"` and `services` section is absent from project-context.yaml.*
171
+
172
+ If `services` section is present:
173
+
174
+ **1. Detect active domain** (in priority order):
175
+ - Read `@trace.domain` from target file frontmatter (if Gate loaded a target file)
176
+ - Extract from target file path: segment immediately after `prd_dir` base path
177
+ *(e.g., `specs/prd/user/FEAT-01.md` → domain = `user`)*
178
+ - If `$ARGUMENTS` contains a path, extract the segment after `prd_dir`
179
+
180
+ **2. Route to service** — if active domain matches a key in `services`:
181
+ - Override `paths.specs_dir` → `services.{domain}.specs_dir`
182
+ - Override `paths.tech_docs_dir` → `services.{domain}.tech_docs_dir`
183
+ - Store `active_service` = `services.{domain}.path`
184
+ - Store `active_service_module` = `services.{domain}.module`
185
+ - If service has its own `module` → use it as `active_module` (overrides `tech_stack.module`)
186
+
187
+ **3. Fallback** — if domain not detected or no matching service key:
188
+ - Keep default paths from Step 1
189
+ - Set `active_service = unresolved`
190
+
191
+ **4. Spec source auto-override** — if `setup.spec_source` is set AND the corresponding path was not already explicitly set in `paths:`:
192
+ - Override `paths.prd_dir` → `{spec_source}/specs/prd`
193
+ - Override `paths.design_spec_dir` → `{spec_source}/specs/design-spec`
194
+ - Override `paths.domain_knowledge_dir` → `{spec_source}/specs/domain-knowledge`
195
+ - Override `paths.business_dictionary` → `{spec_source}/specs/domain-knowledge/business-dictionary.md`
196
+ - Override `paths.core_entities` → `{spec_source}/specs/domain-knowledge/core-entities.md`
197
+ - Override `paths.bug_reports_dir` → `{spec_source}/feedback/bug-reports`
198
+ - Override `paths.bdd_proposals_dir` → `{spec_source}/feedback/bdd-proposals`
199
+
200
+ > **Why under `spec_source`:** tester feedback (`/report-bug`, `/propose-scenario`) must land in the **shared spec repo** so PO/Dev see it when they `/sync`. In single-service mode (no `spec_source`), these default to `feedback/bug-reports` and `feedback/bdd-proposals` at repo root — still shared, same repo.
201
+
202
+ ---
203
+
204
+ ## Step 1.6 — [SERVICE CONVENTIONS] Load service-specific conventions (umbrella mode)
205
+
206
+ *Skip this step entirely if `active_service` is `"unresolved"` or context is single-service mode.*
207
+
208
+ When `active_service` has been resolved to a real path in Step 1.5 (e.g., `user-service/`):
209
+
210
+ **1. Locate service config** — try in priority order:
211
+ - `{active_service}/.agent/project-context.yaml`
212
+ - `{active_service}/project-context.yaml`
213
+
214
+ **2. If found, override with service-specific values:**
215
+
216
+ | Variable | Source |
217
+ |----------|--------|
218
+ | `conventions.test_command` | service's `conventions.test_command` |
219
+ | `conventions.build_command` | service's `conventions.build_command` |
220
+ | `paths.trace_dir` | `{active_service}/{service paths.trace_dir}` — default: `{active_service}/.trace` |
221
+ | `paths.specs_dir` | `{active_service}/{service paths.specs_dir}` (if set in service config, else keep Step 1.5 override) |
222
+
223
+ **3. Store** `service_root = {active_service}` as the working directory anchor for all downstream commands:
224
+ - Shell commands (`/run-tests`, `/generate-tests`) run **from within** `service_root`
225
+ - File write operations (test files, trace TSVs) use paths **relative to** `service_root`
226
+
227
+ **4. If service config not found** — keep umbrella defaults, still set `service_root = {active_service}` (path anchor is always needed even without a config override).
228
+
229
+ ---
230
+
231
+ ## Step 2 — [PROJECT-CONFIG] Load module stack profile (conditional)
232
+
233
+ If `tech_stack.module` is set, read `.agent/modules/{module}/stack-profile.yaml`.
234
+ Merge framework-specific conventions (layer patterns, test patterns, naming rules) into the loaded context.
235
+ If the file does not exist → skip silently.
236
+
237
+ ---
238
+
239
+ ## Step 3 — [CRITICAL] Load CLAUDE.md
240
+
241
+ *This is the highest-priority context — it defines HOW to write code and documents for this project.*
242
+
243
+ Read `CLAUDE.md`. Extract and store:
244
+
245
+ - **§1 Project Overview** → project name, language, framework, build/test commands, domains
246
+ - **§2 Architecture** → layer order (e.g., Controller → Facade → Service → Repository), architectural rules
247
+ - **§3 Coding Standards** → naming conventions (classes, methods), response wrapper type, forbidden patterns
248
+ - **§5 Error Handling** → exception types, HTTP status code mapping, not-found exception class name
249
+ - **§7 Git Conventions** → branch naming pattern, commit message format
250
+
251
+ If `CLAUDE.md` does not exist → note it as missing and continue with project-context.yaml data only.
252
+
253
+ ---
254
+
255
+ ## Step 4 — [SAFETY] Load Data Protection Rules
256
+
257
+ Read `.agent/rules/data-protection.md` (or `rules/data-protection.md` from the framework installation).
258
+
259
+ Store the sensitive file patterns — you must **never** read, write, display, or reference content from files matching those patterns for the entire session.
260
+
261
+ If neither file exists → apply built-in defaults: never access `.env*`, `*.key`, `*.pem`, `*secret*`, `*password*`, `*credential*`.
262
+
263
+ ---
264
+
265
+ ## Step 5 — [DOMAIN] Load Business Dictionary (conditional)
266
+
267
+ Check if the business dictionary file exists (use `paths.business_dictionary` resolved in Step 1).
268
+
269
+ If it exists, read it and extract:
270
+ - **Canonical Terms** → complete list of approved terms and their definitions
271
+ - **Banned Terms** → complete list of banned terms and their canonical replacements
272
+ - **Status / Enum Registry** → allowed enum values per entity
273
+
274
+ Store the banned terms list for **active enforcement** throughout the command session:
275
+ - When generating any text (PRD, BDD, code comments, tech docs), verify no banned terms appear
276
+ - Replace banned terms with their canonical equivalents automatically
277
+
278
+ If the file does not exist → skip silently. Do not warn or block.
279
+
280
+ ---
281
+
282
+ ## Step 6 — [DOMAIN] Load Core Entities (conditional)
283
+
284
+ Check if the core entities file exists at `paths.core_entities` (resolved in Step 1).
285
+ Default path: `specs/domain-knowledge/core-entities.md`.
286
+
287
+ If it exists, read it and store:
288
+ - **Entity catalog** → for each entity: its name, purpose, owner service, key fields (name + type), business invariants, and relationships
289
+ - **Field name registry** → canonical field names to use in generated code and documents
290
+ - **Relationship map** → how entities relate to each other (1:N, N:N, embedded, etc.)
291
+
292
+ **How to use this catalog:**
293
+ - When generating code: use the field names, types, and relationships defined here — do NOT infer from existing code
294
+ - When generating PRD/BDD: reference entity names from this catalog for consistency
295
+ - When generating tech-docs: use this catalog as the source-of-truth for entity definitions
296
+
297
+ If the file does not exist → skip silently.
298
+
299
+ ---
300
+
301
+ ## Step 6.5 — [PLATFORM] Derive active_module and platform_type
302
+
303
+ Using `tech_stack.module` loaded in Step 1, derive and store two variables for use by all downstream commands:
304
+
305
+ ```
306
+ active_module = tech_stack.module (e.g. "java-spring", "react", "flutter")
307
+ ```
308
+
309
+ | `platform_type` | Modules |
310
+ |---|---|
311
+ | `backend` | `java-spring`, `golang`, `dotnet`, `php-laravel`, `context-engineering` |
312
+ | `web-frontend` | `react`, `nextjs`, `vue`, `nuxt`, `angular` |
313
+ | `mobile` | `flutter`, `react-native`, `ios-swiftui`, `android-compose` |
314
+
315
+ If `tech_stack.module` is blank or not recognized → set `platform_type = "unknown"` and flag as ⚠️ in the Step 7 recap.
316
+
317
+ These two variables (`active_module`, `platform_type`) are the canonical source for all branching logic in commands that need platform-specific behavior (generate-tests, debug, fix-bug, smoke-test).
318
+
319
+ ---
320
+
321
+ ## Step 6.7 — [GUARDRAILS] Load Project Lessons (conditional)
322
+
323
+ *Accumulated mistakes the AI must not repeat in this project. These are added over time via `/learn`
324
+ or accepted during `/review-code`, `/fix-bug`, `/debug`.*
325
+
326
+ Resolve the lessons file path:
327
+ - Use `paths.lessons_file` if set (may be service-overridden in umbrella mode, Step 1.6)
328
+ - Else default `specs/domain-knowledge/lessons-learned.md`
329
+ - In umbrella/service mode (when `service_root` is set), if `paths.lessons_file` is unset, default to `{service_root}/.agent/project-lessons.md`
330
+
331
+ If the file exists, read it and store ALL lessons as **ACTIVE GUARDRAILS** for the session:
332
+ - Treat each lesson's **Rule** as a hard constraint — same priority as CLAUDE.md coding standards (Step 3).
333
+ - Before generating or modifying any artifact (PRD, BDD, tech-doc, code, test), check the output against every lesson whose `category` matches the current command AND whose `scope` matches the target (domain / file).
334
+ - If a generated output would violate a lesson → correct it **before** presenting, and note which lesson (`L-NNN`) was applied.
335
+
336
+ If the file does not exist → skip silently (no lessons captured yet).
337
+
338
+ ---
339
+
340
+ ## Step 7 — [RECAP] Working Memory Recap (anti-lost-in-middle)
341
+
342
+ After loading all context, synthesize and output a compact summary block.
343
+ This recap ensures the most critical facts are stated at the END of context loading
344
+ (recency effect — freshest in working memory when the task begins).
345
+
346
+ Output exactly this block:
347
+ ```
348
+ [CTX LOADED]
349
+ Stack : {language} / {framework} / {database}
350
+ Platform : {active_module} ({platform_type})
351
+ Layers : {layer order from CLAUDE.md §2, e.g., Controller → Facade → Service → Repository}
352
+ Ticket : {ticket_prefix}-
353
+ Dict : {loaded — N canonical terms, M banned terms | missing}
354
+ Entities : {loaded — EntityA, EntityB, EntityC | missing}
355
+ Lessons : {loaded — N guardrails | none yet}
356
+ Service : {active_service} ({active_service_module}) | single-service
357
+ Svc Root : {service_root} — conventions + trace_dir loaded from service config | —
358
+ Status : {FULL | PARTIAL — missing: CLAUDE.md / business-dict / core-entities | MINIMAL}
359
+ ```
360
+
361
+ If any CRITICAL file is missing (CLAUDE.md), flag it clearly so the user can decide whether to proceed.
362
+
363
+ ---
364
+
365
+ ## Context Load Complete
366
+
367
+ After completing all steps, you have loaded:
368
+ - Project identity, tech stack, module conventions
369
+ - Architecture rules and layer order ← **[CRITICAL — hold in working memory]**
370
+ - Coding standards and naming conventions ← **[CRITICAL — hold in working memory]**
371
+ - Data protection rules (sensitive file patterns to never access)
372
+ - Terminology rules with banned-term list ← **[DOMAIN — apply to every generated word]**
373
+ - Entity catalog (field names, types, invariants) ← **[DOMAIN — use for code generation]**
374
+ - All configured paths
375
+
376
+ Proceed to the next step of the calling command.
377
+
378
+
379
+ *Read the target PRD. Extract: TICKET-ID, domain, feature name, Service, Module from metadata, User Flow (Section 4a), Wireframe screen names (Section 4b).*
380
+
381
+ ---
382
+
383
+ ## Platform Check
384
+
385
+ - `platform_type = "backend"` → **STOP**: "Design Spec is only for FE/App. BE API contracts go in the Business PRD."
386
+ - `platform_type = "web-frontend"` → `active_platform = "web"`
387
+ - `platform_type = "mobile"` → `active_platform = "app"` (or `"app-ios"` / `"app-android"` for native)
388
+ - `platform_type = "unknown"` → ask user to select platform
389
+
390
+ ---
391
+
392
+ ## Figma Check
393
+
394
+ Ask: "Do you have a Figma link? (paste URL or Enter to skip)"
395
+
396
+ Store as `figma_url` or set to `"TBD"` with AI Assumption noted.
397
+
398
+ ---
399
+
400
+ ## Screen Discovery
401
+
402
+ Extract screen names from PRD Section 4. Present list for PO to confirm/add before generating.
403
+
404
+ ---
405
+
406
+ ## Generate
407
+
408
+ Write `{paths.design_spec_dir}/{domain}/{TICKET-ID}-design-spec-{active_platform}-{slug}.md`.
409
+
410
+ Structure:
411
+ 1. **Metadata** — Spec ID, platform, module, service, Business PRD link, Figma link
412
+ 2. **Screen Inventory** — table of all screens with entry points and Figma frame links
413
+ 3. **Screen Specs** (per screen):
414
+ - Layout (grid, spacing, design tokens)
415
+ - Component Inventory (Figma → code component, import path, states)
416
+ - Screen States (default / loading / error / empty / success)
417
+ - Actions & Navigation (triggers → results)
418
+ 4. **Interaction Patterns** (platform-adaptive):
419
+ - Web: responsive breakpoints table, hover/focus/keyboard table
420
+ - App: gesture table, navigation stack diagram, iOS vs Android conventions table
421
+ 5. **Platform Considerations** (platform-adaptive):
422
+ - Web: accessibility checklist (WCAG, keyboard, ARIA)
423
+ - App: safe area, touch targets, deep links, permissions, offline, dark mode
424
+ 6. **AC-UI** — design acceptance criteria table (Verified by: Designer / PO / QA)
425
+ 7. **Appendix** — Figma summary, design tokens, references, AI assumptions, changelog
426
+
427
+ Component mapping rules:
428
+ - Check `figma-components/{active_module}.md` (loaded in context) for every component
429
+ - ✅ Found → use exact Code Component + Import Path
430
+ - ⚠️ TODO → mark `[TODO — implementation pending]`
431
+ - ❌ Not found → mark `[NEW — confirm with designer]`
432
+
433
+ ---
434
+
435
+ ## Output
436
+
437
+ # Report Footer — Standard Command Output Format
438
+
439
+ Every command report must end with this standard footer section.
440
+
441
+ ## Status Badge
442
+
443
+ Choose one based on outcome:
444
+ - `✅ Complete` — all steps succeeded, no issues found
445
+ - `❌ Failed` — command could not complete due to a blocking error
446
+ - `⚠️ Warnings` — completed with non-blocking issues that should be reviewed
447
+
448
+ ## Output Artifacts
449
+
450
+ List every file created or modified by this command:
451
+ ```
452
+ Output Artifacts:
453
+ {created|updated} {file-path} ({brief description})
454
+ {created|updated} {file-path} ({brief description})
455
+ ```
456
+
457
+ If no files were written (e.g., review or analysis commands) → write `Output Artifacts: none (read-only)`.
458
+
459
+ ## Next Command Suggestion
460
+
461
+ Suggest the logical next command based on workflow phase:
462
+
463
+ | Current command | Suggest next |
464
+ |-------------------------|-----------------------------------------------|
465
+ | /setup-ai-first | `/define-product` to start your first feature |
466
+ | /define-product | `/generate-prd {product-definition-file}` |
467
+ | /generate-prd | `/refine-prd {prd-file}` then `/review-context {prd-file}` |
468
+ | /refine-prd | Open Review Board → update PRD → `/review-context {prd-file}` |
469
+ | /review-context (PRD) | FE/App: `/generate-design-spec {prd-file}` (then BDD after sign-off); BE: `/generate-bdd {prd-file}` directly; fix PRD if NEEDS_FIX |
470
+ | /generate-design-spec | Designer review → Figma links confirmed → PO + Designer sign-off → `/generate-bdd {prd-file}` |
471
+ | /generate-bdd | `/review-context {feature-file}` to verify coverage |
472
+ | /review-context (BDD) | `/generate-tech-docs {UC-ID}` if APPROVED; regenerate if NEEDS_FIX |
473
+ | /generate-tech-docs | `/review-tech-docs {tech-design-file}` |
474
+ | /review-tech-docs | `/generate-code {feature-file}` if APPROVED; fix doc if NEEDS_FIX |
475
+ | /generate-code | First gen → `/review-code {UC-ID}`; re-gen → `/generate-tests {UC-ID}` |
476
+ | /generate-tests | `/run-tests {UC-ID}` |
477
+ | /run-tests (passing) | `/review-code {UC-ID}` |
478
+ | /run-tests (failing) | `/fix-bug {ticket-id}` or `/debug {error}` |
479
+ | /review-code | `/smoke-test {UC-ID}` or create PR |
480
+ | /smoke-test | Create PR and link to ticket |
481
+ | /validate-traces | DRIFT/UNTRACKED → `/generate-code {UC-ID}`; GAP → `/generate-tests {UC-ID}`; all OK → create PR |
482
+ | /fix-bug | Create PR and link to ticket |
483
+ | /debug | `/fix-bug {ticket-id}` if fix needed |
484
+ | /report-bug | Send to dev (`/fix-bug {BUG-ID}`); if coverage gap → `/propose-scenario {UC-ID}` |
485
+ | /propose-scenario | Notify PO/Dev to review the proposal in `feedback/bdd-proposals/` |
486
+ | /learn | Continue working — lesson applies on next command |
487
+ | /sync | `/validate-traces` for full coverage; act on any `📥 tester feedback` surfaced |
488
+ | /update-framework | Review `git diff .agent/`, commit; `/sync` for project content |
489
+
490
+ Format the footer as:
491
+ ```
492
+ ---
493
+ Status : {badge}
494
+ {Output Artifacts block}
495
+ Next : {suggested command with example arguments}
496
+ ```
497
+
498
+
499
+ ```
500
+ /generate-design-spec Complete — {TICKET-ID} [{active_platform}]
501
+ ---
502
+ Status : ✅ Complete
503
+ Output Artifacts:
504
+ created specs/design-spec/{domain}/{TICKET-ID}-design-spec-{active_platform}-{slug}.md (v1.0)
505
+ Next : Share with Designer → add Figma links → PO + Designer sign-off
506
+ → /generate-bdd {prd-file}
507
+ ```
@@ -0,0 +1,95 @@
1
+ ---
2
+ description: Generates a Design Specification document for FE or App platforms from a Business PRD. Trigger when: "/generate-design-spec", "tạo design spec", "generate design spec", "viết design spec", "tạo tài liệu thiết kế UI", "generate UI spec", "cần design spec cho", "tôi muốn spec UI", "tài liệu cho FE", "tài liệu cho app".
3
+ ---
4
+
5
+ # /generate-design-spec — Generate Design Specification (FE / App)
6
+
7
+ This skill generates a platform-specific Design Spec from a Business PRD.
8
+ Design Spec captures screen-level UI requirements, component inventory, platform interactions,
9
+ and design-level AC-UI for PO + Designer sign-off — separate from the business-level PRD.
10
+
11
+ **Supported platforms:** web (react / nextjs / vue / angular), app (flutter / react-native / ios-swiftui / android-compose)
12
+ **Not supported:** backend services — API contracts belong in the Business PRD.
13
+
14
+ ---
15
+
16
+ ## Gate
17
+
18
+ <!-- Directory: specs/prd/**/*.md -->
19
+ {{include:steps/gate.md}}
20
+
21
+ ---
22
+
23
+ ## Context
24
+
25
+ {{include:steps/context-loader.md}}
26
+
27
+ *Read the target PRD. Extract: TICKET-ID, domain, feature name, Service, Module from metadata, User Flow (Section 4a), Wireframe screen names (Section 4b).*
28
+
29
+ ---
30
+
31
+ ## Platform Check
32
+
33
+ - `platform_type = "backend"` → **STOP**: "Design Spec is only for FE/App. BE API contracts go in the Business PRD."
34
+ - `platform_type = "web-frontend"` → `active_platform = "web"`
35
+ - `platform_type = "mobile"` → `active_platform = "app"` (or `"app-ios"` / `"app-android"` for native)
36
+ - `platform_type = "unknown"` → ask user to select platform
37
+
38
+ ---
39
+
40
+ ## Figma Check
41
+
42
+ Ask: "Do you have a Figma link? (paste URL or Enter to skip)"
43
+
44
+ Store as `figma_url` or set to `"TBD"` with AI Assumption noted.
45
+
46
+ ---
47
+
48
+ ## Screen Discovery
49
+
50
+ Extract screen names from PRD Section 4. Present list for PO to confirm/add before generating.
51
+
52
+ ---
53
+
54
+ ## Generate
55
+
56
+ Write `{paths.design_spec_dir}/{domain}/{TICKET-ID}-design-spec-{active_platform}-{slug}.md`.
57
+
58
+ Structure:
59
+ 1. **Metadata** — Spec ID, platform, module, service, Business PRD link, Figma link
60
+ 2. **Screen Inventory** — table of all screens with entry points and Figma frame links
61
+ 3. **Screen Specs** (per screen):
62
+ - Layout (grid, spacing, design tokens)
63
+ - Component Inventory (Figma → code component, import path, states)
64
+ - Screen States (default / loading / error / empty / success)
65
+ - Actions & Navigation (triggers → results)
66
+ 4. **Interaction Patterns** (platform-adaptive):
67
+ - Web: responsive breakpoints table, hover/focus/keyboard table
68
+ - App: gesture table, navigation stack diagram, iOS vs Android conventions table
69
+ 5. **Platform Considerations** (platform-adaptive):
70
+ - Web: accessibility checklist (WCAG, keyboard, ARIA)
71
+ - App: safe area, touch targets, deep links, permissions, offline, dark mode
72
+ 6. **AC-UI** — design acceptance criteria table (Verified by: Designer / PO / QA)
73
+ 7. **Appendix** — Figma summary, design tokens, references, AI assumptions, changelog
74
+
75
+ Component mapping rules:
76
+ - Check `figma-components/{active_module}.md` (loaded in context) for every component
77
+ - ✅ Found → use exact Code Component + Import Path
78
+ - ⚠️ TODO → mark `[TODO — implementation pending]`
79
+ - ❌ Not found → mark `[NEW — confirm with designer]`
80
+
81
+ ---
82
+
83
+ ## Output
84
+
85
+ {{include:steps/report-footer.md}}
86
+
87
+ ```
88
+ /generate-design-spec Complete — {TICKET-ID} [{active_platform}]
89
+ ---
90
+ Status : ✅ Complete
91
+ Output Artifacts:
92
+ created specs/design-spec/{domain}/{TICKET-ID}-design-spec-{active_platform}-{slug}.md (v1.0)
93
+ Next : Share with Designer → add Figma links → PO + Designer sign-off
94
+ → /generate-bdd {prd-file}
95
+ ```