create-sdd-project 0.3.3 → 0.4.1
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.
- package/lib/adapt-agents.js +116 -0
- package/lib/generator.js +2 -85
- package/lib/init-generator.js +71 -119
- package/package.json +1 -1
- package/template/.claude/agents/backend-developer.md +3 -0
- package/template/.claude/agents/backend-planner.md +10 -9
- package/template/.claude/agents/code-review-specialist.md +12 -2
- package/template/.claude/agents/frontend-developer.md +3 -0
- package/template/.claude/agents/frontend-planner.md +9 -9
- package/template/.claude/agents/production-code-validator.md +4 -2
- package/template/.claude/agents/qa-engineer.md +3 -0
- package/template/.claude/skills/development-workflow/SKILL.md +13 -7
- package/template/.claude/skills/development-workflow/references/pr-template.md +13 -1
- package/template/.claude/skills/development-workflow/references/ticket-template.md +19 -0
- package/template/.claude/skills/health-check/SKILL.md +105 -0
- package/template/.gemini/agents/backend-developer.md +3 -0
- package/template/.gemini/agents/backend-planner.md +9 -6
- package/template/.gemini/agents/code-review-specialist.md +6 -0
- package/template/.gemini/agents/frontend-developer.md +3 -0
- package/template/.gemini/agents/frontend-planner.md +9 -6
- package/template/.gemini/agents/production-code-validator.md +1 -1
- package/template/.gemini/agents/qa-engineer.md +3 -1
- package/template/.gemini/skills/development-workflow/SKILL.md +13 -7
- package/template/.gemini/skills/development-workflow/references/pr-template.md +13 -1
- package/template/.gemini/skills/development-workflow/references/ticket-template.md +19 -0
- package/template/.gemini/skills/health-check/SKILL.md +100 -0
|
@@ -0,0 +1,116 @@
|
|
|
1
|
+
'use strict';
|
|
2
|
+
|
|
3
|
+
const path = require('path');
|
|
4
|
+
|
|
5
|
+
/**
|
|
6
|
+
* Shared agent/skill content adaptation for single-stack projects.
|
|
7
|
+
* Used by both generator.js (new projects) and init-generator.js (--init).
|
|
8
|
+
*
|
|
9
|
+
* @param {string} dest - Destination directory
|
|
10
|
+
* @param {object} config - Config with projectType and aiTools
|
|
11
|
+
* @param {function} replaceInFileFn - Function(filePath, replacements) to perform replacements
|
|
12
|
+
*/
|
|
13
|
+
function adaptAgentContentForProjectType(dest, config, replaceInFileFn) {
|
|
14
|
+
const toolDirs = [];
|
|
15
|
+
if (config.aiTools !== 'gemini') toolDirs.push('.claude');
|
|
16
|
+
if (config.aiTools !== 'claude') toolDirs.push('.gemini');
|
|
17
|
+
|
|
18
|
+
if (config.projectType === 'backend') {
|
|
19
|
+
for (const dir of toolDirs) {
|
|
20
|
+
// spec-creator: remove Frontend Specifications section and UI output format
|
|
21
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
22
|
+
[/### Frontend Specifications\n(?:- [^\n]*\n)+\n/, ''],
|
|
23
|
+
[/### For UI Changes\n```markdown\n(?:[^\n]*\n)*?```\n\n/, ''],
|
|
24
|
+
['Data Model Changes, UI Changes, Edge Cases', 'Data Model Changes, Edge Cases'],
|
|
25
|
+
]);
|
|
26
|
+
// production-code-validator: remove ui-components line from Spec Drift
|
|
27
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'production-code-validator.md'), [
|
|
28
|
+
[/- Components exported\/used that are NOT listed in `docs\/specs\/ui-components\.md`\n/, ''],
|
|
29
|
+
]);
|
|
30
|
+
// code-review-specialist: backend-only standards ref, remove ui-components
|
|
31
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'code-review-specialist.md'), [
|
|
32
|
+
['(`backend-standards.mdc` / `frontend-standards.mdc`)', '(`backend-standards.mdc`)'],
|
|
33
|
+
['(`api-spec.yaml`, `ui-components.md`)', '(`api-spec.yaml`)'],
|
|
34
|
+
]);
|
|
35
|
+
// qa-engineer: remove frontend refs, adapt standards refs
|
|
36
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'qa-engineer.md'), [
|
|
37
|
+
['(`api-spec.yaml`, `ui-components.md`)', '(`api-spec.yaml`)'],
|
|
38
|
+
[/- Frontend: `cd frontend && npm test`\n/, ''],
|
|
39
|
+
[/- \*\*Frontend\*\*: Write tests for error states[^\n]*\n/, ''],
|
|
40
|
+
['`backend-standards.mdc` / `frontend-standards.mdc`', '`backend-standards.mdc`'],
|
|
41
|
+
['`backend-standards.mdc` and/or `frontend-standards.mdc`', '`backend-standards.mdc`'],
|
|
42
|
+
[/ and\/or `(?:ai-specs\/specs\/)?frontend-standards\.mdc`/, ''],
|
|
43
|
+
]);
|
|
44
|
+
}
|
|
45
|
+
} else if (config.projectType === 'frontend') {
|
|
46
|
+
for (const dir of toolDirs) {
|
|
47
|
+
// spec-creator: remove Backend Specifications section
|
|
48
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
49
|
+
[/### Backend Specifications\n(?:- [^\n]*\n)+\n/, ''],
|
|
50
|
+
[/### For API Changes\n```yaml\n(?:[^\n]*\n)*?```\n\n/, ''],
|
|
51
|
+
]);
|
|
52
|
+
// code-review-specialist: frontend-only standards ref
|
|
53
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'code-review-specialist.md'), [
|
|
54
|
+
['(`backend-standards.mdc` / `frontend-standards.mdc`)', '(`frontend-standards.mdc`)'],
|
|
55
|
+
['(`api-spec.yaml`, `ui-components.md`)', '(`ui-components.md`)'],
|
|
56
|
+
]);
|
|
57
|
+
// qa-engineer: remove backend refs, adapt standards refs
|
|
58
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'qa-engineer.md'), [
|
|
59
|
+
['(`api-spec.yaml`, `ui-components.md`)', '(`ui-components.md`)'],
|
|
60
|
+
[/- Backend: `cd backend && npm test`\n/, ''],
|
|
61
|
+
[/- \*\*Backend\*\*: Write tests for error paths[^\n]*\n/, ''],
|
|
62
|
+
['`backend-standards.mdc` / `frontend-standards.mdc`', '`frontend-standards.mdc`'],
|
|
63
|
+
['`backend-standards.mdc` and/or `frontend-standards.mdc`', '`frontend-standards.mdc`'],
|
|
64
|
+
[/`(?:ai-specs\/specs\/)?backend-standards\.mdc` and\/or /, ''],
|
|
65
|
+
]);
|
|
66
|
+
}
|
|
67
|
+
}
|
|
68
|
+
|
|
69
|
+
// Skills and templates: remove frontend/backend-specific references
|
|
70
|
+
if (config.projectType === 'backend') {
|
|
71
|
+
for (const dir of toolDirs) {
|
|
72
|
+
// Gemini agents have different text patterns for spec-creator
|
|
73
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
74
|
+
[/\(api-spec\.yaml, ui-components\.md\)/, '(api-spec.yaml)'],
|
|
75
|
+
['Data Model Changes, UI Changes, Edge Cases', 'Data Model Changes, Edge Cases'],
|
|
76
|
+
]);
|
|
77
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'production-code-validator.md'), [
|
|
78
|
+
[/,? components not in ui-components\.md/, ''],
|
|
79
|
+
[/\.? ?Check components vs `ui-components\.md`/, ''],
|
|
80
|
+
]);
|
|
81
|
+
// SKILL.md: remove ui-components references
|
|
82
|
+
replaceInFileFn(path.join(dest, dir, 'skills', 'development-workflow', 'SKILL.md'), [
|
|
83
|
+
[/,? `ui-components\.md`\)/, ')'],
|
|
84
|
+
[/- UI components → `docs\/specs\/ui-components\.md` \(MANDATORY\)\n/, ''],
|
|
85
|
+
]);
|
|
86
|
+
// ticket-template: remove UI Changes section, ui-components from checklists
|
|
87
|
+
replaceInFileFn(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'ticket-template.md'), [
|
|
88
|
+
[/### UI Changes \(if applicable\)\n\n\[Components to add\/modify\. Reference `docs\/specs\/ui-components\.md`\.\]\n\n/, ''],
|
|
89
|
+
[' / `ui-components.md`', ''],
|
|
90
|
+
]);
|
|
91
|
+
// pr-template: remove ui-components from checklist
|
|
92
|
+
replaceInFileFn(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'pr-template.md'), [
|
|
93
|
+
[' / ui-components.md', ''],
|
|
94
|
+
]);
|
|
95
|
+
}
|
|
96
|
+
} else if (config.projectType === 'frontend') {
|
|
97
|
+
for (const dir of toolDirs) {
|
|
98
|
+
replaceInFileFn(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
99
|
+
[/\(api-spec\.yaml, ui-components\.md\)/, '(ui-components.md)'],
|
|
100
|
+
]);
|
|
101
|
+
replaceInFileFn(path.join(dest, dir, 'skills', 'development-workflow', 'SKILL.md'), [
|
|
102
|
+
[/`api-spec\.yaml`,? /, ''],
|
|
103
|
+
[/- API endpoints → `docs\/specs\/api-spec\.yaml` \(MANDATORY\)\n/, ''],
|
|
104
|
+
]);
|
|
105
|
+
replaceInFileFn(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'ticket-template.md'), [
|
|
106
|
+
[/### API Changes \(if applicable\)\n\n\[Endpoints to add\/modify\. Reference[^\]]*\]\n\n/, ''],
|
|
107
|
+
['`api-spec.yaml` / ', ''],
|
|
108
|
+
]);
|
|
109
|
+
replaceInFileFn(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'pr-template.md'), [
|
|
110
|
+
['api-spec.yaml / ', ''],
|
|
111
|
+
]);
|
|
112
|
+
}
|
|
113
|
+
}
|
|
114
|
+
}
|
|
115
|
+
|
|
116
|
+
module.exports = { adaptAgentContentForProjectType };
|
package/lib/generator.js
CHANGED
|
@@ -9,6 +9,7 @@ const {
|
|
|
9
9
|
FRONTEND_AGENTS,
|
|
10
10
|
BACKEND_AGENTS,
|
|
11
11
|
} = require('./config');
|
|
12
|
+
const { adaptAgentContentForProjectType } = require('./adapt-agents');
|
|
12
13
|
|
|
13
14
|
function generate(config) {
|
|
14
15
|
const templateDir = path.join(__dirname, '..', 'template');
|
|
@@ -340,91 +341,7 @@ function adaptDocStandards(dest, config) {
|
|
|
340
341
|
}
|
|
341
342
|
|
|
342
343
|
function adaptAgentContent(dest, config) {
|
|
343
|
-
|
|
344
|
-
if (config.aiTools !== 'gemini') toolDirs.push('.claude');
|
|
345
|
-
if (config.aiTools !== 'claude') toolDirs.push('.gemini');
|
|
346
|
-
|
|
347
|
-
if (config.projectType === 'backend') {
|
|
348
|
-
for (const dir of toolDirs) {
|
|
349
|
-
// spec-creator: remove Frontend Specifications section and UI output format
|
|
350
|
-
replaceInFile(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
351
|
-
[/### Frontend Specifications\n(?:- [^\n]*\n)+\n/, ''],
|
|
352
|
-
[/### For UI Changes\n```markdown\n(?:[^\n]*\n)*?```\n\n/, ''],
|
|
353
|
-
['Data Model Changes, UI Changes, Edge Cases', 'Data Model Changes, Edge Cases'],
|
|
354
|
-
]);
|
|
355
|
-
// production-code-validator: remove ui-components line
|
|
356
|
-
replaceInFile(path.join(dest, dir, 'agents', 'production-code-validator.md'), [
|
|
357
|
-
[/- Components exported\/used that are NOT listed in `docs\/specs\/ui-components\.md`\n/, ''],
|
|
358
|
-
]);
|
|
359
|
-
// code-review-specialist: backend-only refs
|
|
360
|
-
replaceInFile(path.join(dest, dir, 'agents', 'code-review-specialist.md'), [
|
|
361
|
-
['(`backend-standards.mdc` / `frontend-standards.mdc`)', '(`backend-standards.mdc`)'],
|
|
362
|
-
['(`api-spec.yaml`, `ui-components.md`)', '(`api-spec.yaml`)'],
|
|
363
|
-
]);
|
|
364
|
-
// qa-engineer: remove frontend refs
|
|
365
|
-
replaceInFile(path.join(dest, dir, 'agents', 'qa-engineer.md'), [
|
|
366
|
-
['(`api-spec.yaml`, `ui-components.md`)', '(`api-spec.yaml`)'],
|
|
367
|
-
[/- Frontend: `cd frontend && npm test`\n/, ''],
|
|
368
|
-
[/- \*\*Frontend\*\*: Write tests for error states[^\n]*\n/, ''],
|
|
369
|
-
]);
|
|
370
|
-
}
|
|
371
|
-
} else if (config.projectType === 'frontend') {
|
|
372
|
-
for (const dir of toolDirs) {
|
|
373
|
-
replaceInFile(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
374
|
-
[/### Backend Specifications\n(?:- [^\n]*\n)+\n/, ''],
|
|
375
|
-
[/### For API Changes\n```yaml\n(?:[^\n]*\n)*?```\n\n/, ''],
|
|
376
|
-
]);
|
|
377
|
-
replaceInFile(path.join(dest, dir, 'agents', 'code-review-specialist.md'), [
|
|
378
|
-
['(`backend-standards.mdc` / `frontend-standards.mdc`)', '(`frontend-standards.mdc`)'],
|
|
379
|
-
['(`api-spec.yaml`, `ui-components.md`)', '(`ui-components.md`)'],
|
|
380
|
-
]);
|
|
381
|
-
replaceInFile(path.join(dest, dir, 'agents', 'qa-engineer.md'), [
|
|
382
|
-
['(`api-spec.yaml`, `ui-components.md`)', '(`ui-components.md`)'],
|
|
383
|
-
[/- Backend: `cd backend && npm test`\n/, ''],
|
|
384
|
-
[/- \*\*Backend\*\*: Write tests for error paths[^\n]*\n/, ''],
|
|
385
|
-
]);
|
|
386
|
-
}
|
|
387
|
-
}
|
|
388
|
-
|
|
389
|
-
// Skills and templates: same cleanup
|
|
390
|
-
if (config.projectType === 'backend') {
|
|
391
|
-
for (const dir of toolDirs) {
|
|
392
|
-
replaceInFile(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
393
|
-
[/\(api-spec\.yaml, ui-components\.md\)/, '(api-spec.yaml)'],
|
|
394
|
-
]);
|
|
395
|
-
replaceInFile(path.join(dest, dir, 'agents', 'production-code-validator.md'), [
|
|
396
|
-
[/,? components not in ui-components\.md/, ''],
|
|
397
|
-
]);
|
|
398
|
-
replaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'SKILL.md'), [
|
|
399
|
-
[/,? `ui-components\.md`\)/, ')'],
|
|
400
|
-
[/- UI components → `docs\/specs\/ui-components\.md` \(MANDATORY\)\n/, ''],
|
|
401
|
-
]);
|
|
402
|
-
replaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'ticket-template.md'), [
|
|
403
|
-
[/### UI Changes \(if applicable\)\n\n\[Components to add\/modify\. Reference `docs\/specs\/ui-components\.md`\.\]\n\n/, ''],
|
|
404
|
-
[' / `ui-components.md`', ''],
|
|
405
|
-
]);
|
|
406
|
-
replaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'pr-template.md'), [
|
|
407
|
-
[' / ui-components.md', ''],
|
|
408
|
-
]);
|
|
409
|
-
}
|
|
410
|
-
} else if (config.projectType === 'frontend') {
|
|
411
|
-
for (const dir of toolDirs) {
|
|
412
|
-
replaceInFile(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
413
|
-
[/\(api-spec\.yaml, ui-components\.md\)/, '(ui-components.md)'],
|
|
414
|
-
]);
|
|
415
|
-
replaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'SKILL.md'), [
|
|
416
|
-
[/`api-spec\.yaml`,? /, ''],
|
|
417
|
-
[/- API endpoints → `docs\/specs\/api-spec\.yaml` \(MANDATORY\)\n/, ''],
|
|
418
|
-
]);
|
|
419
|
-
replaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'ticket-template.md'), [
|
|
420
|
-
[/### API Changes \(if applicable\)\n\n\[Endpoints to add\/modify\. Reference[^\]]*\]\n\n/, ''],
|
|
421
|
-
['`api-spec.yaml` / ', ''],
|
|
422
|
-
]);
|
|
423
|
-
replaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'pr-template.md'), [
|
|
424
|
-
['api-spec.yaml / ', ''],
|
|
425
|
-
]);
|
|
426
|
-
}
|
|
427
|
-
}
|
|
344
|
+
adaptAgentContentForProjectType(dest, config, replaceInFile);
|
|
428
345
|
}
|
|
429
346
|
|
|
430
347
|
module.exports = { generate };
|
package/lib/init-generator.js
CHANGED
|
@@ -7,6 +7,7 @@ const {
|
|
|
7
7
|
FRONTEND_AGENTS,
|
|
8
8
|
BACKEND_AGENTS,
|
|
9
9
|
} = require('./config');
|
|
10
|
+
const { adaptAgentContentForProjectType } = require('./adapt-agents');
|
|
10
11
|
|
|
11
12
|
/**
|
|
12
13
|
* Install SDD DevFlow into an existing project.
|
|
@@ -324,19 +325,39 @@ function adaptCopiedFiles(dest, scan, config) {
|
|
|
324
325
|
const db = scan.backend.db || 'your database';
|
|
325
326
|
|
|
326
327
|
// Common Zod → generic validation replacements (all agents + skills)
|
|
327
|
-
//
|
|
328
|
+
// Phase 1: Replace "Zod" with "validation" (most specific first)
|
|
328
329
|
const zodReplacements = [
|
|
329
330
|
['Zod data schemas', 'validation schemas'],
|
|
330
331
|
['Zod schemas', 'validation schemas'],
|
|
331
332
|
];
|
|
333
|
+
// Phase 2: Clean up shared/src/schemas/ path (Zod-specific convention)
|
|
334
|
+
// Applied AFTER phase 1, so these match the post-replacement text
|
|
335
|
+
const schemaPathReplacements = [
|
|
336
|
+
['validation schemas in `shared/src/schemas/` if applicable', 'validation schemas if applicable'],
|
|
337
|
+
['validation schemas in `shared/src/schemas/` (if shared workspace exists)', 'validation schemas (if shared workspace exists)'],
|
|
338
|
+
['validation schemas in `shared/src/schemas/`', 'validation schemas'],
|
|
339
|
+
['validation schemas (`shared/src/schemas/`)', 'validation schemas'],
|
|
340
|
+
['`shared/src/schemas/` (if exists) for current validation schemas', 'project validation schemas'],
|
|
341
|
+
// Gemini spec-creator: no "Zod" prefix, standalone path reference
|
|
342
|
+
['and `shared/src/schemas/` (if exists)', ''],
|
|
343
|
+
['schemas vs `shared/src/schemas/`', 'validation schemas up to date'],
|
|
344
|
+
];
|
|
332
345
|
|
|
333
346
|
// ORM/DB replacements for backend agents
|
|
334
|
-
|
|
335
|
-
|
|
347
|
+
let ormReplacements = [];
|
|
348
|
+
if (scan.backend.orm && scan.backend.orm !== 'Prisma') {
|
|
349
|
+
ormReplacements = [
|
|
336
350
|
['Prisma ORM, and PostgreSQL', `${orm}${db !== 'your database' ? `, and ${db}` : ''}`],
|
|
337
351
|
['Repository implementations (Prisma)', `Repository implementations (${orm})`],
|
|
338
|
-
]
|
|
339
|
-
|
|
352
|
+
];
|
|
353
|
+
} else if (!scan.backend.orm) {
|
|
354
|
+
// No ORM detected — remove Prisma references with generic text
|
|
355
|
+
const dbLabel = db !== 'your database' ? `, and ${db}` : '';
|
|
356
|
+
ormReplacements = [
|
|
357
|
+
['Prisma ORM, and PostgreSQL', dbLabel ? dbLabel.slice(6) : 'your database'],
|
|
358
|
+
['Repository implementations (Prisma)', 'Repository implementations'],
|
|
359
|
+
];
|
|
360
|
+
}
|
|
340
361
|
|
|
341
362
|
// Apply to all AI tool directories
|
|
342
363
|
const toolDirs = [];
|
|
@@ -349,6 +370,9 @@ function adaptCopiedFiles(dest, scan, config) {
|
|
|
349
370
|
const backendAgentReplacements = [...zodReplacements, ...ormReplacements];
|
|
350
371
|
replaceInCopiedFile(dest, `${dir}/agents/backend-developer.md`, backendAgentReplacements);
|
|
351
372
|
replaceInCopiedFile(dest, `${dir}/agents/backend-planner.md`, backendAgentReplacements);
|
|
373
|
+
// Phase 2: clean up shared/src/schemas/ paths
|
|
374
|
+
replaceInCopiedFile(dest, `${dir}/agents/backend-developer.md`, schemaPathReplacements);
|
|
375
|
+
replaceInCopiedFile(dest, `${dir}/agents/backend-planner.md`, schemaPathReplacements);
|
|
352
376
|
} else if (ormReplacements.length > 0) {
|
|
353
377
|
// Zod detected but different ORM — only ORM replacements
|
|
354
378
|
replaceInCopiedFile(dest, `${dir}/agents/backend-developer.md`, ormReplacements);
|
|
@@ -357,15 +381,17 @@ function adaptCopiedFiles(dest, scan, config) {
|
|
|
357
381
|
|
|
358
382
|
// Multi-purpose agents: Zod replacements only
|
|
359
383
|
if (scan.backend.validation !== 'Zod') {
|
|
360
|
-
|
|
361
|
-
replaceInCopiedFile(dest, `${dir}/agents/
|
|
362
|
-
replaceInCopiedFile(dest, `${dir}/agents/
|
|
384
|
+
const allZodReplacements = [...zodReplacements, ...schemaPathReplacements];
|
|
385
|
+
replaceInCopiedFile(dest, `${dir}/agents/spec-creator.md`, allZodReplacements);
|
|
386
|
+
replaceInCopiedFile(dest, `${dir}/agents/production-code-validator.md`, allZodReplacements);
|
|
387
|
+
replaceInCopiedFile(dest, `${dir}/agents/database-architect.md`, allZodReplacements);
|
|
363
388
|
}
|
|
364
389
|
|
|
365
|
-
// Skills: Zod replacements
|
|
390
|
+
// Skills: Zod + schema path replacements
|
|
366
391
|
if (scan.backend.validation !== 'Zod') {
|
|
367
|
-
|
|
368
|
-
replaceInCopiedFile(dest, `${dir}/skills/development-workflow/
|
|
392
|
+
const allZodReplacements = [...zodReplacements, ...schemaPathReplacements];
|
|
393
|
+
replaceInCopiedFile(dest, `${dir}/skills/development-workflow/SKILL.md`, allZodReplacements);
|
|
394
|
+
replaceInCopiedFile(dest, `${dir}/skills/development-workflow/references/ticket-template.md`, allZodReplacements);
|
|
369
395
|
}
|
|
370
396
|
}
|
|
371
397
|
|
|
@@ -375,142 +401,68 @@ function adaptCopiedFiles(dest, scan, config) {
|
|
|
375
401
|
for (const dir of toolDirs) {
|
|
376
402
|
// backend-planner: adapt header, exploration paths, implementation order, rules
|
|
377
403
|
regexReplaceInFile(path.join(dest, dir, 'agents', 'backend-planner.md'), [
|
|
378
|
-
// Header: remove DDD reference
|
|
404
|
+
// Header: remove DDD reference (Claude verbose format)
|
|
379
405
|
['specializing in Domain-Driven Design (DDD) layered architecture with deep knowledge of',
|
|
380
406
|
'specializing in layered architecture with deep knowledge of'],
|
|
381
|
-
//
|
|
382
|
-
[
|
|
383
|
-
|
|
407
|
+
// Header: remove DDD reference (Gemini condensed format)
|
|
408
|
+
['(DDD architecture)', '(layered architecture)'],
|
|
409
|
+
// Exploration: replace DDD-specific paths with generic (number-agnostic)
|
|
410
|
+
[/\d+\. Read `shared\/src\/schemas\/` \(if exists\) for current .* (?:data )?schemas\n/, ''],
|
|
411
|
+
[/\d+\. Explore existing domain entities, services, validators, repositories\n/,
|
|
384
412
|
'5. Explore the codebase for existing patterns, layer structure, and reusable code\n'],
|
|
385
|
-
[
|
|
386
|
-
|
|
387
|
-
[/8\. Explore `backend\/src\/infrastructure\/` for existing repositories\n/, ''],
|
|
388
|
-
// Implementation Order
|
|
413
|
+
[/\d+\. Explore `backend\/src\/infrastructure\/` for existing repositories\n/, ''],
|
|
414
|
+
// Implementation Order (Claude format)
|
|
389
415
|
['following DDD layer order: Domain > Application > Infrastructure > Presentation > Tests',
|
|
390
416
|
'following the layer order defined in backend-standards.mdc'],
|
|
391
|
-
//
|
|
417
|
+
// Implementation Order (Gemini format)
|
|
418
|
+
['Implementation Order (Domain > Application > Infrastructure > Presentation > Tests)',
|
|
419
|
+
'Implementation Order (see backend-standards.mdc for layer order)'],
|
|
420
|
+
// Rules (Claude format)
|
|
392
421
|
['Follow DDD layer separation: Domain > Application > Infrastructure > Presentation',
|
|
393
422
|
'Follow the layer separation defined in backend-standards.mdc'],
|
|
394
423
|
]);
|
|
395
424
|
// backend-developer: adapt frontmatter, header, exploration, implementation order, rules
|
|
396
425
|
regexReplaceInFile(path.join(dest, dir, 'agents', 'backend-developer.md'), [
|
|
426
|
+
// Frontmatter (Claude format)
|
|
397
427
|
['follows DDD layered architecture',
|
|
398
428
|
'follows layered architecture'],
|
|
429
|
+
// Header (Claude format)
|
|
399
430
|
['specializing in Domain-Driven Design (DDD) with',
|
|
400
431
|
'specializing in layered architecture with'],
|
|
401
|
-
|
|
402
|
-
|
|
432
|
+
// Header (Gemini condensed format)
|
|
433
|
+
['(DDD architecture)', '(layered architecture)'],
|
|
434
|
+
// Exploration: remove shared/src/schemas reference (number-agnostic)
|
|
435
|
+
[/\d+\. Read `shared\/src\/schemas\/` \(if exists\) for current .* (?:data )?schemas\n/, ''],
|
|
436
|
+
// Implementation Order (Claude format): replace DDD layers
|
|
403
437
|
['Follow the DDD layer order from the plan:',
|
|
404
438
|
'Follow the layer order from the plan (see backend-standards.mdc for project layers):'],
|
|
405
|
-
[
|
|
439
|
+
[/\d+\. \*\*Domain Layer\*\*: Entities, value objects, repository interfaces, domain errors\n/,
|
|
406
440
|
'1. **Data Layer**: Models, database operations, data access\n'],
|
|
407
|
-
[
|
|
441
|
+
[/\d+\. \*\*Application Layer\*\*: Services, validators, DTOs\n/,
|
|
408
442
|
'2. **Business Logic Layer**: Controllers, services, external integrations\n'],
|
|
409
|
-
[
|
|
443
|
+
[/\d+\. \*\*Infrastructure Layer\*\*: Repository implementations \([^)]*\), external integrations\n/,
|
|
410
444
|
'3. **Presentation Layer**: Routes, handlers, middleware\n'],
|
|
411
|
-
[
|
|
445
|
+
[/\d+\. \*\*Presentation Layer\*\*: Controllers, routes, middleware\n/,
|
|
412
446
|
'4. **Integration Layer**: Wiring, configuration, server registration\n'],
|
|
413
|
-
//
|
|
447
|
+
// Implementation Order (Gemini format)
|
|
448
|
+
['Follow DDD layer order: Domain > Application > Infrastructure > Presentation.',
|
|
449
|
+
'Follow the layer order defined in backend-standards.mdc.'],
|
|
450
|
+
// Rules (Claude format)
|
|
414
451
|
['**ALWAYS** follow DDD layer separation',
|
|
415
452
|
'**ALWAYS** follow the layer separation defined in backend-standards.mdc'],
|
|
416
453
|
['**ALWAYS** handle errors with custom domain error classes',
|
|
417
454
|
'**ALWAYS** handle errors following the patterns in backend-standards.mdc'],
|
|
418
|
-
//
|
|
419
|
-
[
|
|
420
|
-
|
|
421
|
-
|
|
422
|
-
|
|
423
|
-
|
|
424
|
-
// Agent content: remove frontend/backend-specific references for single-stack projects
|
|
425
|
-
if (config.projectType === 'backend') {
|
|
426
|
-
for (const dir of toolDirs) {
|
|
427
|
-
// spec-creator: remove Frontend Specifications section and UI output format
|
|
428
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
429
|
-
[/### Frontend Specifications\n(?:- [^\n]*\n)+\n/, ''],
|
|
430
|
-
[/### For UI Changes\n```markdown\n(?:[^\n]*\n)*?```\n\n/, ''],
|
|
431
|
-
['Data Model Changes, UI Changes, Edge Cases', 'Data Model Changes, Edge Cases'],
|
|
432
|
-
]);
|
|
433
|
-
// production-code-validator: remove ui-components line from Spec Drift
|
|
434
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'production-code-validator.md'), [
|
|
435
|
-
[/- Components exported\/used that are NOT listed in `docs\/specs\/ui-components\.md`\n/, ''],
|
|
436
|
-
]);
|
|
437
|
-
// code-review-specialist: backend-only standards ref, remove ui-components
|
|
438
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'code-review-specialist.md'), [
|
|
439
|
-
['(`backend-standards.mdc` / `frontend-standards.mdc`)', '(`backend-standards.mdc`)'],
|
|
440
|
-
['(`api-spec.yaml`, `ui-components.md`)', '(`api-spec.yaml`)'],
|
|
441
|
-
]);
|
|
442
|
-
// qa-engineer: remove ui-components from specs, remove frontend test command
|
|
443
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'qa-engineer.md'), [
|
|
444
|
-
['(`api-spec.yaml`, `ui-components.md`)', '(`api-spec.yaml`)'],
|
|
445
|
-
[/- Frontend: `cd frontend && npm test`\n/, ''],
|
|
446
|
-
[/- \*\*Frontend\*\*: Write tests for error states[^\n]*\n/, ''],
|
|
447
|
-
]);
|
|
448
|
-
}
|
|
449
|
-
} else if (config.projectType === 'frontend') {
|
|
450
|
-
for (const dir of toolDirs) {
|
|
451
|
-
// spec-creator: remove Backend Specifications section
|
|
452
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
453
|
-
[/### Backend Specifications\n(?:- [^\n]*\n)+\n/, ''],
|
|
454
|
-
[/### For API Changes\n```yaml\n(?:[^\n]*\n)*?```\n\n/, ''],
|
|
455
|
-
]);
|
|
456
|
-
// code-review-specialist: frontend-only standards ref
|
|
457
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'code-review-specialist.md'), [
|
|
458
|
-
['(`backend-standards.mdc` / `frontend-standards.mdc`)', '(`frontend-standards.mdc`)'],
|
|
459
|
-
['(`api-spec.yaml`, `ui-components.md`)', '(`ui-components.md`)'],
|
|
460
|
-
]);
|
|
461
|
-
// qa-engineer: remove api-spec from specs, remove backend test command
|
|
462
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'qa-engineer.md'), [
|
|
463
|
-
['(`api-spec.yaml`, `ui-components.md`)', '(`ui-components.md`)'],
|
|
464
|
-
[/- Backend: `cd backend && npm test`\n/, ''],
|
|
465
|
-
[/- \*\*Backend\*\*: Write tests for error paths[^\n]*\n/, ''],
|
|
455
|
+
// Rules (Gemini format)
|
|
456
|
+
['ALWAYS handle errors with domain error classes',
|
|
457
|
+
'ALWAYS handle errors following the patterns in backend-standards.mdc'],
|
|
458
|
+
// Documentation: remove shared/src/schemas mandatory update
|
|
459
|
+
[/- (?:\*\*MANDATORY\*\*: )?If modifying a DB schema → update .* schemas in `shared\/src\/schemas\/` BEFORE continuing\n/, ''],
|
|
466
460
|
]);
|
|
467
461
|
}
|
|
468
462
|
}
|
|
469
463
|
|
|
470
|
-
//
|
|
471
|
-
|
|
472
|
-
for (const dir of toolDirs) {
|
|
473
|
-
// Gemini agents have different text patterns
|
|
474
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
475
|
-
[/\(api-spec\.yaml, ui-components\.md\)/, '(api-spec.yaml)'],
|
|
476
|
-
['Data Model Changes, UI Changes, Edge Cases', 'Data Model Changes, Edge Cases'],
|
|
477
|
-
]);
|
|
478
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'production-code-validator.md'), [
|
|
479
|
-
[/,? components not in ui-components\.md/, ''],
|
|
480
|
-
]);
|
|
481
|
-
// SKILL.md: remove ui-components references
|
|
482
|
-
regexReplaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'SKILL.md'), [
|
|
483
|
-
[/,? `ui-components\.md`\)/, ')'],
|
|
484
|
-
[/- UI components → `docs\/specs\/ui-components\.md` \(MANDATORY\)\n/, ''],
|
|
485
|
-
]);
|
|
486
|
-
// ticket-template: remove UI Changes section, ui-components from checklists
|
|
487
|
-
regexReplaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'ticket-template.md'), [
|
|
488
|
-
[/### UI Changes \(if applicable\)\n\n\[Components to add\/modify\. Reference `docs\/specs\/ui-components\.md`\.\]\n\n/, ''],
|
|
489
|
-
[' / `ui-components.md`', ''],
|
|
490
|
-
]);
|
|
491
|
-
// pr-template: remove ui-components from checklist
|
|
492
|
-
regexReplaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'pr-template.md'), [
|
|
493
|
-
[' / ui-components.md', ''],
|
|
494
|
-
]);
|
|
495
|
-
}
|
|
496
|
-
} else if (config.projectType === 'frontend') {
|
|
497
|
-
for (const dir of toolDirs) {
|
|
498
|
-
regexReplaceInFile(path.join(dest, dir, 'agents', 'spec-creator.md'), [
|
|
499
|
-
[/\(api-spec\.yaml, ui-components\.md\)/, '(ui-components.md)'],
|
|
500
|
-
]);
|
|
501
|
-
regexReplaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'SKILL.md'), [
|
|
502
|
-
[/`api-spec\.yaml`,? /, ''],
|
|
503
|
-
[/- API endpoints → `docs\/specs\/api-spec\.yaml` \(MANDATORY\)\n/, ''],
|
|
504
|
-
]);
|
|
505
|
-
regexReplaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'ticket-template.md'), [
|
|
506
|
-
[/### API Changes \(if applicable\)\n\n\[Endpoints to add\/modify\. Reference[^\]]*\]\n\n/, ''],
|
|
507
|
-
['`api-spec.yaml` / ', ''],
|
|
508
|
-
]);
|
|
509
|
-
regexReplaceInFile(path.join(dest, dir, 'skills', 'development-workflow', 'references', 'pr-template.md'), [
|
|
510
|
-
['api-spec.yaml / ', ''],
|
|
511
|
-
]);
|
|
512
|
-
}
|
|
513
|
-
}
|
|
464
|
+
// Agent/skill content: remove frontend/backend-specific references for single-stack projects
|
|
465
|
+
adaptAgentContentForProjectType(dest, config, regexReplaceInFile);
|
|
514
466
|
|
|
515
467
|
// documentation-standards.mdc: remove irrelevant rows based on project type
|
|
516
468
|
const docStdPath = path.join(dest, 'ai-specs', 'specs', 'documentation-standards.mdc');
|
package/package.json
CHANGED
|
@@ -13,6 +13,8 @@ You are an expert TypeScript backend developer specializing in Domain-Driven Des
|
|
|
13
13
|
|
|
14
14
|
Implement the backend task following the **Implementation Plan** in the ticket. Use strict TDD methodology.
|
|
15
15
|
|
|
16
|
+
**Standards take priority over legacy code.** When existing code contradicts `backend-standards.mdc`, follow the standards.
|
|
17
|
+
|
|
16
18
|
## Before Implementing
|
|
17
19
|
|
|
18
20
|
1. Read the ticket file (including the Spec and Implementation Plan)
|
|
@@ -54,6 +56,7 @@ Follow the DDD layer order from the plan:
|
|
|
54
56
|
- **ALWAYS** follow DDD layer separation
|
|
55
57
|
- **ALWAYS** use explicit types (never `any`)
|
|
56
58
|
- **ALWAYS** handle errors with custom domain error classes
|
|
59
|
+
- **ALWAYS** prioritize standards in `backend-standards.mdc` over patterns found in existing code (existing code may use legacy patterns)
|
|
57
60
|
- **ALWAYS** run `npm test` after each TDD cycle to verify
|
|
58
61
|
- **NEVER** skip tests for "simple" code
|
|
59
62
|
- **NEVER** modify code outside the scope of the current ticket
|
|
@@ -16,17 +16,17 @@ Generate a detailed **Implementation Plan** and write it into the ticket's `## I
|
|
|
16
16
|
|
|
17
17
|
**NEVER write implementation code. Only produce the plan.**
|
|
18
18
|
|
|
19
|
+
**Standards take priority over legacy code.** When existing code contradicts `backend-standards.mdc`, follow the standards.
|
|
20
|
+
|
|
19
21
|
## Before Planning
|
|
20
22
|
|
|
21
|
-
1. Read `
|
|
22
|
-
2. Read
|
|
23
|
-
3. Read
|
|
24
|
-
4. Read `
|
|
25
|
-
5.
|
|
26
|
-
6. Explore
|
|
27
|
-
7. Explore `backend/src/
|
|
28
|
-
8. Explore `backend/src/infrastructure/` for existing repositories
|
|
29
|
-
9. Read `ai-specs/specs/backend-standards.mdc` for project standards
|
|
23
|
+
1. Read `ai-specs/specs/backend-standards.mdc` — this is your primary reference for conventions
|
|
24
|
+
2. Read `docs/project_notes/key_facts.md` for existing reusable components
|
|
25
|
+
3. Read the ticket file passed as input (including the `## Spec` section)
|
|
26
|
+
4. Read `docs/specs/api-spec.yaml` for current API endpoints and schemas
|
|
27
|
+
5. Read `shared/src/schemas/` (if exists) for current Zod data schemas
|
|
28
|
+
6. Explore existing domain entities, services, validators, repositories
|
|
29
|
+
7. Explore `backend/src/infrastructure/` for existing repositories
|
|
30
30
|
|
|
31
31
|
**Reuse over recreate.** Only propose new code when existing doesn't fit.
|
|
32
32
|
|
|
@@ -62,4 +62,5 @@ Write the following sections into the ticket's `## Implementation Plan` section:
|
|
|
62
62
|
- **ALWAYS** check existing code before proposing new files
|
|
63
63
|
- **ALWAYS** save the plan into the ticket's `## Implementation Plan` section
|
|
64
64
|
- **ALWAYS** reference `ai-specs/specs/backend-standards.mdc` for project conventions
|
|
65
|
+
- **ALWAYS** prioritize standards in `backend-standards.mdc` over patterns found in existing code (existing code may use legacy patterns)
|
|
65
66
|
- Follow DDD layer separation: Domain > Application > Infrastructure > Presentation
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: code-review-specialist
|
|
3
3
|
description: "Use this agent when you need a thorough code review of recently written or modified code. This includes reviewing pull requests, evaluating code quality before committing, checking for security vulnerabilities, ensuring adherence to best practices, or getting constructive feedback on implementation approaches."
|
|
4
|
-
model:
|
|
4
|
+
model: opus
|
|
5
5
|
---
|
|
6
6
|
|
|
7
7
|
You are a Senior Code Review Specialist. Examine code for correctness, maintainability, security, and performance. Be constructive and specific — reference exact lines, explain WHY something matters, and suggest HOW to fix it.
|
|
@@ -26,7 +26,17 @@ You are a Senior Code Review Specialist. Examine code for correctness, maintaina
|
|
|
26
26
|
|
|
27
27
|
**Maintainability**: Readability, test coverage and quality, consistency with existing codebase.
|
|
28
28
|
|
|
29
|
-
### 3.
|
|
29
|
+
### 3. Adversarial Analysis
|
|
30
|
+
|
|
31
|
+
Go beyond checklist review — actively try to break the implementation:
|
|
32
|
+
|
|
33
|
+
- **External failures**: What if the external API returns garbage, times out, or changes its contract?
|
|
34
|
+
- **Concurrency**: What happens under concurrent requests? Race conditions? Double writes?
|
|
35
|
+
- **Malicious input**: What data could a malicious user inject? Are all inputs validated at system boundaries?
|
|
36
|
+
- **State corruption**: What if the database is slow, a transaction fails midway, or cache is stale?
|
|
37
|
+
- **Missing validation**: Are values range-checked, type-checked, and null-checked before use?
|
|
38
|
+
|
|
39
|
+
### 4. Categorize Findings
|
|
30
40
|
|
|
31
41
|
- **Critical** — Must fix before merging (security, data loss, breaking bugs)
|
|
32
42
|
- **Important** — Should fix (quality/maintainability concerns)
|
|
@@ -13,6 +13,8 @@ You are an expert React frontend developer specializing in Next.js App Router wi
|
|
|
13
13
|
|
|
14
14
|
Implement the frontend task following the **Implementation Plan** in the ticket. Use strict TDD methodology.
|
|
15
15
|
|
|
16
|
+
**Standards take priority over legacy code.** When existing code contradicts `frontend-standards.mdc`, follow the standards.
|
|
17
|
+
|
|
16
18
|
## Before Implementing
|
|
17
19
|
|
|
18
20
|
1. Read the ticket file (including the Spec and Implementation Plan)
|
|
@@ -64,5 +66,6 @@ Follow the logical order from the plan:
|
|
|
64
66
|
- **ALWAYS** handle loading and error states
|
|
65
67
|
- **ALWAYS** run `npm test` after each TDD cycle to verify
|
|
66
68
|
- **NEVER** skip tests for "simple" components
|
|
69
|
+
- **ALWAYS** prioritize standards in `frontend-standards.mdc` over patterns found in existing code (existing code may use legacy patterns)
|
|
67
70
|
- **NEVER** modify code outside the scope of the current ticket
|
|
68
71
|
- **ALWAYS** verify implementation matches the approved spec. If a deviation is needed, document it in the product tracker's Active Session and ask for approval
|
|
@@ -16,17 +16,16 @@ Generate a detailed **Implementation Plan** and write it into the ticket's `## I
|
|
|
16
16
|
|
|
17
17
|
**NEVER write implementation code. Only produce the plan.**
|
|
18
18
|
|
|
19
|
+
**Standards take priority over legacy code.** When existing code contradicts `frontend-standards.mdc`, follow the standards.
|
|
20
|
+
|
|
19
21
|
## Before Planning
|
|
20
22
|
|
|
21
|
-
1. Read `
|
|
22
|
-
2. Read
|
|
23
|
-
3. Read
|
|
24
|
-
4. Read `docs/specs/
|
|
25
|
-
5.
|
|
26
|
-
6. Explore
|
|
27
|
-
7. Explore `frontend/stores/` for existing state stores
|
|
28
|
-
8. Explore `frontend/app/` for existing pages and layouts
|
|
29
|
-
9. Read `ai-specs/specs/frontend-standards.mdc` for project standards
|
|
23
|
+
1. Read `ai-specs/specs/frontend-standards.mdc` — this is your primary reference for conventions
|
|
24
|
+
2. Read `docs/project_notes/key_facts.md` for existing reusable components
|
|
25
|
+
3. Read the ticket file passed as input (including the `## Spec` section)
|
|
26
|
+
4. Read `docs/specs/ui-components.md` for current UI component specs
|
|
27
|
+
5. Read `docs/specs/api-spec.yaml` for API endpoints to consume
|
|
28
|
+
6. Explore existing components, utilities, services, stores, and pages
|
|
30
29
|
|
|
31
30
|
**Reuse over recreate.** Only propose new components when existing ones don't fit.
|
|
32
31
|
|
|
@@ -62,4 +61,5 @@ Write the following sections into the ticket's `## Implementation Plan` section:
|
|
|
62
61
|
- **ALWAYS** check existing code before proposing new files
|
|
63
62
|
- **ALWAYS** save the plan into the ticket's `## Implementation Plan` section
|
|
64
63
|
- **ALWAYS** reference `ai-specs/specs/frontend-standards.mdc` for project conventions
|
|
64
|
+
- **ALWAYS** prioritize standards in `frontend-standards.mdc` over patterns found in existing code (existing code may use legacy patterns)
|
|
65
65
|
- Note which components need `'use client'` directive
|
|
@@ -58,11 +58,13 @@ Scan code systematically to identify and report issues that should never reach p
|
|
|
58
58
|
- Functions longer than 50 lines
|
|
59
59
|
- Missing TypeScript types where expected
|
|
60
60
|
|
|
61
|
-
### 8. Spec Drift
|
|
62
|
-
-
|
|
61
|
+
### 8. Spec Drift (BLOCKING — any mismatch is HIGH severity)
|
|
62
|
+
- **Enumerate every route** registered in the codebase and verify each has a matching entry in `docs/specs/api-spec.yaml`
|
|
63
|
+
- **Enumerate every endpoint** in `api-spec.yaml` and verify each has a matching route in code
|
|
63
64
|
- Components exported/used that are NOT listed in `docs/specs/ui-components.md`
|
|
64
65
|
- Database schema changes not reflected in Zod schemas (`shared/src/schemas/`)
|
|
65
66
|
- Mismatch between spec-defined request/response schemas and actual implementation
|
|
67
|
+
- **Ticket accuracy**: verify acceptance criteria test count matches actual test count
|
|
66
68
|
|
|
67
69
|
## Output Format
|
|
68
70
|
|
|
@@ -10,10 +10,13 @@ You are an expert QA Automation Engineer. Your goal is to break the code. You as
|
|
|
10
10
|
|
|
11
11
|
Verify the implementation's robustness and strict adherence to `docs/specs/`.
|
|
12
12
|
|
|
13
|
+
**Standards take priority over legacy code.** When existing tests contradict `backend-standards.mdc` / `frontend-standards.mdc`, follow the standards.
|
|
14
|
+
|
|
13
15
|
## Workflow
|
|
14
16
|
|
|
15
17
|
### 1. Analyze
|
|
16
18
|
- Read the Ticket and the Specs (`api-spec.yaml`, `ui-components.md`)
|
|
19
|
+
- Read `ai-specs/specs/backend-standards.mdc` and/or `frontend-standards.mdc` for testing patterns
|
|
17
20
|
- Read the implementation code and existing tests
|
|
18
21
|
- Identify what the developer tested vs. what's missing
|
|
19
22
|
|
|
@@ -96,8 +96,9 @@ See `references/branching-strategy.md` for details.
|
|
|
96
96
|
## Step 2: Plan (Standard/Complex only)
|
|
97
97
|
|
|
98
98
|
1. Use Task tool with planner agent (`backend-planner` for backend features, `frontend-planner` for frontend features)
|
|
99
|
-
2.
|
|
100
|
-
3.
|
|
99
|
+
2. **Fullstack features:** Run `backend-planner` first, then `frontend-planner`. Each writes its own section in the Implementation Plan
|
|
100
|
+
3. Agent writes Implementation Plan into ticket's `## Implementation Plan`
|
|
101
|
+
4. Update tracker: step `2/6 (Plan)`
|
|
101
102
|
|
|
102
103
|
**→ CHECKPOINT: Plan Approval**
|
|
103
104
|
|
|
@@ -107,6 +108,8 @@ See `references/branching-strategy.md` for details.
|
|
|
107
108
|
|
|
108
109
|
**Simple:** Implement directly with TDD. **Std/Cplx:** Use developer agent (`backend-developer` / `frontend-developer`).
|
|
109
110
|
|
|
111
|
+
**Fullstack features:** Implement backend first (APIs must exist before the frontend consumes them), then frontend. Use the corresponding developer agent for each.
|
|
112
|
+
|
|
110
113
|
**TDD Cycle:** Failing test → Minimum code to pass → Refactor → Repeat
|
|
111
114
|
|
|
112
115
|
**Update specs IN REAL TIME (do not wait until Finalize):**
|
|
@@ -117,6 +120,8 @@ See `references/branching-strategy.md` for details.
|
|
|
117
120
|
|
|
118
121
|
**Spec deviation** → document in product tracker Active Session and ask for approval.
|
|
119
122
|
|
|
123
|
+
**Commits:** Commit freely during implementation (one per logical unit is fine). Final history cleanup happens via squash merge in Step 5.
|
|
124
|
+
|
|
120
125
|
Update tracker: step `3/6 (Implement)`, context summary.
|
|
121
126
|
|
|
122
127
|
---
|
|
@@ -143,7 +148,7 @@ Update tracker: step `4/6 (Finalize)`
|
|
|
143
148
|
1. Push branch, create PR (use `references/pr-template.md`)
|
|
144
149
|
2. **Std/Cplx:** Run `code-review-specialist` via Task tool — **do NOT skip**
|
|
145
150
|
3. **Std/Cplx:** Also run `qa-engineer` via Task tool
|
|
146
|
-
4. **Merge:** Features/bugfixes → squash; Releases/hotfixes → merge commit
|
|
151
|
+
4. **Merge strategy:** Features/bugfixes → **squash merge** (clean single commit on target branch); Releases/hotfixes → merge commit
|
|
147
152
|
|
|
148
153
|
**→ CHECKPOINT: Merge Approval**
|
|
149
154
|
|
|
@@ -153,10 +158,11 @@ Update tracker: step `5/6 (Review)`
|
|
|
153
158
|
|
|
154
159
|
## Step 6: Complete
|
|
155
160
|
|
|
156
|
-
1.
|
|
157
|
-
2.
|
|
158
|
-
3.
|
|
159
|
-
4.
|
|
161
|
+
1. **Update ticket with final state:** correct test count in acceptance criteria, mark all checkboxes, update Completion Log with all commits and key events
|
|
162
|
+
2. Delete feature branch (local + remote)
|
|
163
|
+
3. Update product tracker: feature → done, add to Completion Log, update progress
|
|
164
|
+
4. Record bugs in `bugs.md`, decisions in `decisions.md`
|
|
165
|
+
5. Clear Active Session → "No active work"
|
|
160
166
|
|
|
161
167
|
---
|
|
162
168
|
|
|
@@ -30,6 +30,18 @@ gh pr create --base main --title "<type>(<scope>): <description>" --body "$(cat
|
|
|
30
30
|
- [x] Integration tests passing (if applicable)
|
|
31
31
|
- [x] Validated with production-code-validator
|
|
32
32
|
|
|
33
|
+
## Risk Assessment
|
|
34
|
+
|
|
35
|
+
- [ ] Modifies authentication/authorization logic
|
|
36
|
+
- [ ] Handles financial, medical, or sensitive data
|
|
37
|
+
- [ ] Changes database schema or migrations
|
|
38
|
+
- [ ] Modifies external API integrations
|
|
39
|
+
- [ ] Affects error handling or recovery paths
|
|
40
|
+
|
|
41
|
+
## Human Review Focus
|
|
42
|
+
|
|
43
|
+
[1-3 specific areas where human expertise is most needed. Example: "Token refresh edge case in cgmData handler", "Dedup logic correctness"]
|
|
44
|
+
|
|
33
45
|
## Checklist
|
|
34
46
|
|
|
35
47
|
- [ ] Code follows project standards
|
|
@@ -44,7 +56,7 @@ gh pr create --base main --title "<type>(<scope>): <description>" --body "$(cat
|
|
|
44
56
|
Closes #issue_number (if applicable)
|
|
45
57
|
|
|
46
58
|
---
|
|
47
|
-
Generated with
|
|
59
|
+
Generated with SDD DevFlow
|
|
48
60
|
EOF
|
|
49
61
|
)"
|
|
50
62
|
```
|
|
@@ -60,12 +60,31 @@ _Pending — to be generated by the planner agent in Step 2._
|
|
|
60
60
|
|
|
61
61
|
---
|
|
62
62
|
|
|
63
|
+
## Workflow Checklist
|
|
64
|
+
|
|
65
|
+
<!-- Auto-fill based on complexity tier. Remove steps that don't apply. -->
|
|
66
|
+
|
|
67
|
+
- [ ] Step 0: `spec-creator` executed, specs updated
|
|
68
|
+
- [ ] Step 1: Branch created, ticket generated, tracker updated
|
|
69
|
+
- [ ] Step 2: `{backend|frontend}-planner` executed, plan approved
|
|
70
|
+
- [ ] Step 3: `{backend|frontend}-developer` executed with TDD
|
|
71
|
+
- [ ] Step 4: `production-code-validator` executed, quality gates pass
|
|
72
|
+
- [ ] Step 5: `code-review-specialist` executed
|
|
73
|
+
- [ ] Step 5: `qa-engineer` executed (Standard/Complex)
|
|
74
|
+
- [ ] Step 6: Ticket updated with final metrics, branch deleted
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
63
78
|
## Completion Log
|
|
64
79
|
|
|
65
80
|
| Date | Action | Notes |
|
|
66
81
|
|------|--------|-------|
|
|
67
82
|
| | | |
|
|
68
83
|
|
|
84
|
+
<!-- After code review, add a row documenting which findings were accepted/rejected:
|
|
85
|
+
| YYYY-MM-DD | Review findings | Accepted: C1-C3, H1-H2. Rejected: M5 (reason). Systemic: C4 logged in bugs.md |
|
|
86
|
+
This creates a feedback loop for improving future reviews. -->
|
|
87
|
+
|
|
69
88
|
---
|
|
70
89
|
|
|
71
90
|
*Ticket created: [YYYY-MM-DD]*
|
|
@@ -0,0 +1,105 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: health-check
|
|
3
|
+
description: "Quick project health scan. Invoke with: 'health check', 'project health', or 'health'. Verifies tests, build, specs sync, secrets, and documentation freshness."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Health Check Skill
|
|
7
|
+
|
|
8
|
+
Run a fast, systematic health scan across the project. Useful before starting new work, after merging, or when something feels off.
|
|
9
|
+
|
|
10
|
+
## Command
|
|
11
|
+
|
|
12
|
+
| Command | Action |
|
|
13
|
+
|---------|--------|
|
|
14
|
+
| `health` | Run full health check |
|
|
15
|
+
|
|
16
|
+
## Checks
|
|
17
|
+
|
|
18
|
+
Run all checks in order. For each, report PASS or FAIL with details.
|
|
19
|
+
|
|
20
|
+
### 1. Tests
|
|
21
|
+
|
|
22
|
+
```bash
|
|
23
|
+
npm test
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
FAIL if any test fails or the command exits non-zero.
|
|
27
|
+
|
|
28
|
+
### 2. Build
|
|
29
|
+
|
|
30
|
+
```bash
|
|
31
|
+
npm run build
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
FAIL if build errors. SKIP if no build script exists.
|
|
35
|
+
|
|
36
|
+
### 3. Type Check
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
npx tsc --noEmit
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
FAIL if type errors. SKIP if no `tsconfig.json`.
|
|
43
|
+
|
|
44
|
+
### 4. Critical TODOs
|
|
45
|
+
|
|
46
|
+
Search codebase for `TODO`, `FIXME`, `HACK`, `XXX` in source files (exclude `node_modules`, `dist`, `.git`).
|
|
47
|
+
|
|
48
|
+
WARN if any found. List file:line for each.
|
|
49
|
+
|
|
50
|
+
### 5. Spec Sync
|
|
51
|
+
|
|
52
|
+
- Compare routes registered in code vs endpoints in `docs/specs/api-spec.yaml`
|
|
53
|
+
- Compare exported components vs `docs/specs/ui-components.md`
|
|
54
|
+
- FAIL if mismatches found. SKIP if spec files don't exist.
|
|
55
|
+
|
|
56
|
+
### 6. Secrets Scan
|
|
57
|
+
|
|
58
|
+
Search for patterns that suggest leaked secrets:
|
|
59
|
+
- API keys, tokens, passwords in source files
|
|
60
|
+
- `.env` files tracked by git (`git ls-files '*.env'`)
|
|
61
|
+
- Hardcoded `localhost` URLs with ports (warn only)
|
|
62
|
+
|
|
63
|
+
FAIL if secrets found. WARN for localhost URLs.
|
|
64
|
+
|
|
65
|
+
### 7. Environment
|
|
66
|
+
|
|
67
|
+
- Check `.env.example` exists and lists all variables referenced in code
|
|
68
|
+
- WARN if `.env.example` is missing or incomplete
|
|
69
|
+
|
|
70
|
+
### 8. Tracker Coherence
|
|
71
|
+
|
|
72
|
+
- Read `docs/project_notes/product-tracker.md`
|
|
73
|
+
- Check Active Session is clean (no stale in-progress work)
|
|
74
|
+
- WARN if tracker looks stale or inconsistent
|
|
75
|
+
|
|
76
|
+
## Output Format
|
|
77
|
+
|
|
78
|
+
```
|
|
79
|
+
## Project Health Report
|
|
80
|
+
|
|
81
|
+
| # | Check | Status | Details |
|
|
82
|
+
|---|-------|--------|---------|
|
|
83
|
+
| 1 | Tests | PASS | 47 tests passing |
|
|
84
|
+
| 2 | Build | PASS | Clean |
|
|
85
|
+
| 3 | Types | PASS | No errors |
|
|
86
|
+
| 4 | TODOs | WARN | 3 found (see below) |
|
|
87
|
+
| 5 | Specs | PASS | Routes match |
|
|
88
|
+
| 6 | Secrets | PASS | None found |
|
|
89
|
+
| 7 | Env | PASS | .env.example up to date |
|
|
90
|
+
| 8 | Tracker | WARN | Active session not empty |
|
|
91
|
+
|
|
92
|
+
**Overall: HEALTHY / NEEDS ATTENTION / UNHEALTHY**
|
|
93
|
+
|
|
94
|
+
### Details
|
|
95
|
+
[Expand on any FAIL or WARN items]
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
**HEALTHY** = all PASS (WARNs ok). **NEEDS ATTENTION** = WARNs present. **UNHEALTHY** = any FAIL.
|
|
99
|
+
|
|
100
|
+
## Rules
|
|
101
|
+
|
|
102
|
+
- Run checks in order — stop early if tests or build fail (later checks may be unreliable)
|
|
103
|
+
- Be specific about failures — include file paths, line numbers, exact errors
|
|
104
|
+
- Don't fix anything — only report. The user decides what to act on
|
|
105
|
+
- Keep output concise — details only for non-PASS items
|
|
@@ -7,6 +7,8 @@
|
|
|
7
7
|
|
|
8
8
|
Implement the task following the Implementation Plan in the ticket. Use strict TDD (Red-Green-Refactor). Follow DDD layer order: Domain > Application > Infrastructure > Presentation.
|
|
9
9
|
|
|
10
|
+
**Standards take priority over legacy code.** When existing code contradicts `backend-standards.mdc`, follow the standards.
|
|
11
|
+
|
|
10
12
|
## Before Implementing
|
|
11
13
|
|
|
12
14
|
1. Read ticket (including Spec and Implementation Plan)
|
|
@@ -27,5 +29,6 @@ Implement the task following the Implementation Plan in the ticket. Use strict T
|
|
|
27
29
|
- ALWAYS follow the Implementation Plan
|
|
28
30
|
- ALWAYS use explicit types (no `any`)
|
|
29
31
|
- ALWAYS handle errors with domain error classes
|
|
32
|
+
- ALWAYS prioritize standards in `backend-standards.mdc` over patterns found in existing code (existing code may use legacy patterns)
|
|
30
33
|
- NEVER modify code outside the scope of the current ticket
|
|
31
34
|
- ALWAYS verify implementation matches the approved spec. If deviation needed, document in product tracker's Active Session and ask for approval
|
|
@@ -7,14 +7,16 @@
|
|
|
7
7
|
|
|
8
8
|
Generate a detailed Implementation Plan and write it into the ticket's `## Implementation Plan` section. The plan must be detailed enough for the backend-developer to implement autonomously.
|
|
9
9
|
|
|
10
|
+
**Standards take priority over legacy code.** When existing code contradicts `backend-standards.mdc`, follow the standards.
|
|
11
|
+
|
|
10
12
|
## Before Planning
|
|
11
13
|
|
|
12
|
-
1. Read `
|
|
13
|
-
2. Read
|
|
14
|
-
3. Read
|
|
15
|
-
4. Read `
|
|
16
|
-
5.
|
|
17
|
-
6.
|
|
14
|
+
1. Read `ai-specs/specs/backend-standards.mdc` — primary reference for conventions
|
|
15
|
+
2. Read `docs/project_notes/key_facts.md`
|
|
16
|
+
3. Read the ticket file (including `## Spec` section)
|
|
17
|
+
4. Read `docs/specs/api-spec.yaml` for current API endpoints and schemas
|
|
18
|
+
5. Read `shared/src/schemas/` (if exists) for current Zod data schemas
|
|
19
|
+
6. Explore existing domain entities, services, validators, repositories
|
|
18
20
|
|
|
19
21
|
**Reuse over recreate.** Only propose new code when existing doesn't fit.
|
|
20
22
|
|
|
@@ -31,4 +33,5 @@ Generate a detailed Implementation Plan and write it into the ticket's `## Imple
|
|
|
31
33
|
|
|
32
34
|
- NEVER write implementation code — only the plan
|
|
33
35
|
- ALWAYS check existing code before proposing new files
|
|
36
|
+
- ALWAYS prioritize standards in `backend-standards.mdc` over patterns found in existing code (existing code may use legacy patterns)
|
|
34
37
|
- ALWAYS save the plan into the ticket
|
|
@@ -14,6 +14,12 @@ Perform a multi-layer code review covering:
|
|
|
14
14
|
- **Performance**: N+1 queries, memory leaks, unnecessary computations
|
|
15
15
|
- **Maintainability**: Readability, test coverage, pattern consistency
|
|
16
16
|
|
|
17
|
+
Then go beyond checklist review — actively try to break the implementation:
|
|
18
|
+
- What if external APIs return garbage, time out, or change their contract?
|
|
19
|
+
- What happens under concurrent requests? Race conditions?
|
|
20
|
+
- What data could a malicious user inject?
|
|
21
|
+
- What if a transaction fails midway or cache is stale?
|
|
22
|
+
|
|
17
23
|
## Output Format
|
|
18
24
|
|
|
19
25
|
```
|
|
@@ -7,6 +7,8 @@
|
|
|
7
7
|
|
|
8
8
|
Implement the task following the Implementation Plan in the ticket. Use strict TDD (Red-Green-Refactor). Follow logical order: Types > Services > Stores > Components > Pages.
|
|
9
9
|
|
|
10
|
+
**Standards take priority over legacy code.** When existing code contradicts `frontend-standards.mdc`, follow the standards.
|
|
11
|
+
|
|
10
12
|
## Before Implementing
|
|
11
13
|
|
|
12
14
|
1. Read ticket (including Spec and Implementation Plan)
|
|
@@ -27,5 +29,6 @@ Implement the task following the Implementation Plan in the ticket. Use strict T
|
|
|
27
29
|
- ALWAYS use explicit types (no `any`)
|
|
28
30
|
- ALWAYS use `'use client'` for components with hooks
|
|
29
31
|
- ALWAYS handle loading and error states
|
|
32
|
+
- ALWAYS prioritize standards in `frontend-standards.mdc` over patterns found in existing code (existing code may use legacy patterns)
|
|
30
33
|
- NEVER modify code outside the scope of the current ticket
|
|
31
34
|
- ALWAYS verify implementation matches the approved spec. If deviation needed, document in product tracker's Active Session and ask for approval
|
|
@@ -7,14 +7,16 @@
|
|
|
7
7
|
|
|
8
8
|
Generate a detailed Implementation Plan and write it into the ticket's `## Implementation Plan` section. The plan must be detailed enough for the frontend-developer to implement autonomously.
|
|
9
9
|
|
|
10
|
+
**Standards take priority over legacy code.** When existing code contradicts `frontend-standards.mdc`, follow the standards.
|
|
11
|
+
|
|
10
12
|
## Before Planning
|
|
11
13
|
|
|
12
|
-
1. Read `
|
|
13
|
-
2. Read
|
|
14
|
-
3. Read
|
|
15
|
-
4. Read `docs/specs/
|
|
16
|
-
5.
|
|
17
|
-
6.
|
|
14
|
+
1. Read `ai-specs/specs/frontend-standards.mdc` — primary reference for conventions
|
|
15
|
+
2. Read `docs/project_notes/key_facts.md`
|
|
16
|
+
3. Read the ticket file (including `## Spec` section)
|
|
17
|
+
4. Read `docs/specs/ui-components.md` for current UI component specs
|
|
18
|
+
5. Read `docs/specs/api-spec.yaml` for API endpoints to consume
|
|
19
|
+
6. Explore existing components, services, stores, pages
|
|
18
20
|
|
|
19
21
|
**Reuse over recreate.** Only propose new components when existing ones don't fit.
|
|
20
22
|
|
|
@@ -31,4 +33,5 @@ Generate a detailed Implementation Plan and write it into the ticket's `## Imple
|
|
|
31
33
|
|
|
32
34
|
- NEVER write implementation code — only the plan
|
|
33
35
|
- ALWAYS check existing code before proposing new files
|
|
36
|
+
- ALWAYS prioritize standards in `frontend-standards.mdc` over patterns found in existing code (existing code may use legacy patterns)
|
|
34
37
|
- ALWAYS save the plan into the ticket
|
|
@@ -14,7 +14,7 @@ Scan code systematically for issues that should never reach production:
|
|
|
14
14
|
5. **Security Red Flags**: Disabled SSL, CORS *, hardcoded credentials
|
|
15
15
|
6. **Error Handling**: Empty catch blocks, swallowed errors
|
|
16
16
|
7. **Code Quality**: Unused imports, missing types, overly long functions
|
|
17
|
-
8. **Spec Drift
|
|
17
|
+
8. **Spec Drift** (BLOCKING): Enumerate every route in code vs `api-spec.yaml` — any mismatch is HIGH. Check components vs `ui-components.md`, schemas vs `shared/src/schemas/`. Verify ticket test counts match actual
|
|
18
18
|
|
|
19
19
|
## Output Format
|
|
20
20
|
|
|
@@ -7,9 +7,11 @@
|
|
|
7
7
|
|
|
8
8
|
You assume the happy path works (checked by Developer). Hunt for edge cases, security flaws, and spec deviations. Verify implementation against `docs/specs/`.
|
|
9
9
|
|
|
10
|
+
**Standards take priority over legacy code.** When existing tests contradict `backend-standards.mdc` / `frontend-standards.mdc`, follow the standards.
|
|
11
|
+
|
|
10
12
|
## Workflow
|
|
11
13
|
|
|
12
|
-
1. Read ticket, specs (`api-spec.yaml`, `ui-components.md`), implementation code, and existing tests
|
|
14
|
+
1. Read ticket, specs (`api-spec.yaml`, `ui-components.md`), standards (`backend-standards.mdc` / `frontend-standards.mdc`), implementation code, and existing tests
|
|
13
15
|
2. Identify missing test cases and spec deviations
|
|
14
16
|
3. Run full test suite for regressions
|
|
15
17
|
4. Create new edge-case tests (e.g., `*.edge-cases.test.ts`)
|
|
@@ -96,8 +96,9 @@ See `references/branching-strategy.md` for details.
|
|
|
96
96
|
## Step 2: Plan (Standard/Complex only)
|
|
97
97
|
|
|
98
98
|
1. Follow the planner agent instructions (`backend-planner` for backend features, `frontend-planner` for frontend features) in `.gemini/agents/`
|
|
99
|
-
2.
|
|
100
|
-
3.
|
|
99
|
+
2. **Fullstack features:** Run `backend-planner` first, then `frontend-planner`. Each writes its own section in the Implementation Plan
|
|
100
|
+
3. Write Implementation Plan into ticket's `## Implementation Plan`
|
|
101
|
+
4. Update tracker: step `2/6 (Plan)`
|
|
101
102
|
|
|
102
103
|
**→ CHECKPOINT: Plan Approval**
|
|
103
104
|
|
|
@@ -107,6 +108,8 @@ See `references/branching-strategy.md` for details.
|
|
|
107
108
|
|
|
108
109
|
**Simple:** Implement directly with TDD. **Std/Cplx:** Follow the developer agent instructions (`backend-developer` / `frontend-developer`) in `.gemini/agents/`.
|
|
109
110
|
|
|
111
|
+
**Fullstack features:** Implement backend first (APIs must exist before the frontend consumes them), then frontend. Use the corresponding developer agent for each.
|
|
112
|
+
|
|
110
113
|
**TDD Cycle:** Failing test → Minimum code to pass → Refactor → Repeat
|
|
111
114
|
|
|
112
115
|
**Update specs IN REAL TIME (do not wait until Finalize):**
|
|
@@ -117,6 +120,8 @@ See `references/branching-strategy.md` for details.
|
|
|
117
120
|
|
|
118
121
|
**Spec deviation** → document in product tracker Active Session and ask for approval.
|
|
119
122
|
|
|
123
|
+
**Commits:** Commit freely during implementation (one per logical unit is fine). Final history cleanup happens via squash merge in Step 5.
|
|
124
|
+
|
|
120
125
|
Update tracker: step `3/6 (Implement)`, context summary.
|
|
121
126
|
|
|
122
127
|
---
|
|
@@ -143,7 +148,7 @@ Update tracker: step `4/6 (Finalize)`
|
|
|
143
148
|
1. Push branch, create PR (use `references/pr-template.md`)
|
|
144
149
|
2. **Std/Cplx:** Follow `code-review-specialist` instructions in `.gemini/agents/` — **do NOT skip**
|
|
145
150
|
3. **Std/Cplx:** Also follow `qa-engineer` instructions in `.gemini/agents/`
|
|
146
|
-
4. **Merge:** Features/bugfixes → squash; Releases/hotfixes → merge commit
|
|
151
|
+
4. **Merge strategy:** Features/bugfixes → **squash merge** (clean single commit on target branch); Releases/hotfixes → merge commit
|
|
147
152
|
|
|
148
153
|
**→ CHECKPOINT: Merge Approval**
|
|
149
154
|
|
|
@@ -153,10 +158,11 @@ Update tracker: step `5/6 (Review)`
|
|
|
153
158
|
|
|
154
159
|
## Step 6: Complete
|
|
155
160
|
|
|
156
|
-
1.
|
|
157
|
-
2.
|
|
158
|
-
3.
|
|
159
|
-
4.
|
|
161
|
+
1. **Update ticket with final state:** correct test count in acceptance criteria, mark all checkboxes, update Completion Log with all commits and key events
|
|
162
|
+
2. Delete feature branch (local + remote)
|
|
163
|
+
3. Update product tracker: feature → done, add to Completion Log, update progress
|
|
164
|
+
4. Record bugs in `bugs.md`, decisions in `decisions.md`
|
|
165
|
+
5. Clear Active Session → "No active work"
|
|
160
166
|
|
|
161
167
|
---
|
|
162
168
|
|
|
@@ -30,6 +30,18 @@ gh pr create --base main --title "<type>(<scope>): <description>" --body "$(cat
|
|
|
30
30
|
- [x] Integration tests passing (if applicable)
|
|
31
31
|
- [x] Validated with production-code-validator
|
|
32
32
|
|
|
33
|
+
## Risk Assessment
|
|
34
|
+
|
|
35
|
+
- [ ] Modifies authentication/authorization logic
|
|
36
|
+
- [ ] Handles financial, medical, or sensitive data
|
|
37
|
+
- [ ] Changes database schema or migrations
|
|
38
|
+
- [ ] Modifies external API integrations
|
|
39
|
+
- [ ] Affects error handling or recovery paths
|
|
40
|
+
|
|
41
|
+
## Human Review Focus
|
|
42
|
+
|
|
43
|
+
[1-3 specific areas where human expertise is most needed. Example: "Token refresh edge case in cgmData handler", "Dedup logic correctness"]
|
|
44
|
+
|
|
33
45
|
## Checklist
|
|
34
46
|
|
|
35
47
|
- [ ] Code follows project standards
|
|
@@ -44,7 +56,7 @@ gh pr create --base main --title "<type>(<scope>): <description>" --body "$(cat
|
|
|
44
56
|
Closes #issue_number (if applicable)
|
|
45
57
|
|
|
46
58
|
---
|
|
47
|
-
Generated with
|
|
59
|
+
Generated with SDD DevFlow
|
|
48
60
|
EOF
|
|
49
61
|
)"
|
|
50
62
|
```
|
|
@@ -60,12 +60,31 @@ _Pending — to be generated by the planner agent in Step 2._
|
|
|
60
60
|
|
|
61
61
|
---
|
|
62
62
|
|
|
63
|
+
## Workflow Checklist
|
|
64
|
+
|
|
65
|
+
<!-- Auto-fill based on complexity tier. Remove steps that don't apply. -->
|
|
66
|
+
|
|
67
|
+
- [ ] Step 0: `spec-creator` executed, specs updated
|
|
68
|
+
- [ ] Step 1: Branch created, ticket generated, tracker updated
|
|
69
|
+
- [ ] Step 2: `{backend|frontend}-planner` executed, plan approved
|
|
70
|
+
- [ ] Step 3: `{backend|frontend}-developer` executed with TDD
|
|
71
|
+
- [ ] Step 4: `production-code-validator` executed, quality gates pass
|
|
72
|
+
- [ ] Step 5: `code-review-specialist` executed
|
|
73
|
+
- [ ] Step 5: `qa-engineer` executed (Standard/Complex)
|
|
74
|
+
- [ ] Step 6: Ticket updated with final metrics, branch deleted
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
63
78
|
## Completion Log
|
|
64
79
|
|
|
65
80
|
| Date | Action | Notes |
|
|
66
81
|
|------|--------|-------|
|
|
67
82
|
| | | |
|
|
68
83
|
|
|
84
|
+
<!-- After code review, add a row documenting which findings were accepted/rejected:
|
|
85
|
+
| YYYY-MM-DD | Review findings | Accepted: C1-C3, H1-H2. Rejected: M5 (reason). Systemic: C4 logged in bugs.md |
|
|
86
|
+
This creates a feedback loop for improving future reviews. -->
|
|
87
|
+
|
|
69
88
|
---
|
|
70
89
|
|
|
71
90
|
*Ticket created: [YYYY-MM-DD]*
|
|
@@ -0,0 +1,100 @@
|
|
|
1
|
+
# Health Check Skill
|
|
2
|
+
|
|
3
|
+
Run a fast, systematic health scan across the project. Useful before starting new work, after merging, or when something feels off.
|
|
4
|
+
|
|
5
|
+
## Command
|
|
6
|
+
|
|
7
|
+
| Command | Action |
|
|
8
|
+
|---------|--------|
|
|
9
|
+
| `health` | Run full health check |
|
|
10
|
+
|
|
11
|
+
## Checks
|
|
12
|
+
|
|
13
|
+
Run all checks in order. For each, report PASS or FAIL with details.
|
|
14
|
+
|
|
15
|
+
### 1. Tests
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
npm test
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
FAIL if any test fails or the command exits non-zero.
|
|
22
|
+
|
|
23
|
+
### 2. Build
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
npm run build
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
FAIL if build errors. SKIP if no build script exists.
|
|
30
|
+
|
|
31
|
+
### 3. Type Check
|
|
32
|
+
|
|
33
|
+
```bash
|
|
34
|
+
npx tsc --noEmit
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
FAIL if type errors. SKIP if no `tsconfig.json`.
|
|
38
|
+
|
|
39
|
+
### 4. Critical TODOs
|
|
40
|
+
|
|
41
|
+
Search codebase for `TODO`, `FIXME`, `HACK`, `XXX` in source files (exclude `node_modules`, `dist`, `.git`).
|
|
42
|
+
|
|
43
|
+
WARN if any found. List file:line for each.
|
|
44
|
+
|
|
45
|
+
### 5. Spec Sync
|
|
46
|
+
|
|
47
|
+
- Compare routes registered in code vs endpoints in `docs/specs/api-spec.yaml`
|
|
48
|
+
- Compare exported components vs `docs/specs/ui-components.md`
|
|
49
|
+
- FAIL if mismatches found. SKIP if spec files don't exist.
|
|
50
|
+
|
|
51
|
+
### 6. Secrets Scan
|
|
52
|
+
|
|
53
|
+
Search for patterns that suggest leaked secrets:
|
|
54
|
+
- API keys, tokens, passwords in source files
|
|
55
|
+
- `.env` files tracked by git (`git ls-files '*.env'`)
|
|
56
|
+
- Hardcoded `localhost` URLs with ports (warn only)
|
|
57
|
+
|
|
58
|
+
FAIL if secrets found. WARN for localhost URLs.
|
|
59
|
+
|
|
60
|
+
### 7. Environment
|
|
61
|
+
|
|
62
|
+
- Check `.env.example` exists and lists all variables referenced in code
|
|
63
|
+
- WARN if `.env.example` is missing or incomplete
|
|
64
|
+
|
|
65
|
+
### 8. Tracker Coherence
|
|
66
|
+
|
|
67
|
+
- Read `docs/project_notes/product-tracker.md`
|
|
68
|
+
- Check Active Session is clean (no stale in-progress work)
|
|
69
|
+
- WARN if tracker looks stale or inconsistent
|
|
70
|
+
|
|
71
|
+
## Output Format
|
|
72
|
+
|
|
73
|
+
```
|
|
74
|
+
## Project Health Report
|
|
75
|
+
|
|
76
|
+
| # | Check | Status | Details |
|
|
77
|
+
|---|-------|--------|---------|
|
|
78
|
+
| 1 | Tests | PASS | 47 tests passing |
|
|
79
|
+
| 2 | Build | PASS | Clean |
|
|
80
|
+
| 3 | Types | PASS | No errors |
|
|
81
|
+
| 4 | TODOs | WARN | 3 found (see below) |
|
|
82
|
+
| 5 | Specs | PASS | Routes match |
|
|
83
|
+
| 6 | Secrets | PASS | None found |
|
|
84
|
+
| 7 | Env | PASS | .env.example up to date |
|
|
85
|
+
| 8 | Tracker | WARN | Active session not empty |
|
|
86
|
+
|
|
87
|
+
**Overall: HEALTHY / NEEDS ATTENTION / UNHEALTHY**
|
|
88
|
+
|
|
89
|
+
### Details
|
|
90
|
+
[Expand on any FAIL or WARN items]
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
**HEALTHY** = all PASS (WARNs ok). **NEEDS ATTENTION** = WARNs present. **UNHEALTHY** = any FAIL.
|
|
94
|
+
|
|
95
|
+
## Rules
|
|
96
|
+
|
|
97
|
+
- Run checks in order — stop early if tests or build fail (later checks may be unreliable)
|
|
98
|
+
- Be specific about failures — include file paths, line numbers, exact errors
|
|
99
|
+
- Don't fix anything — only report. The user decides what to act on
|
|
100
|
+
- Keep output concise — details only for non-PASS items
|