create-ai-project 1.14.6 → 1.14.8
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/.claude/agents-en/task-decomposer.md +1 -40
- package/.claude/agents-ja/task-decomposer.md +1 -40
- package/.claude/commands-en/add-integration-tests.md +74 -0
- package/.claude/commands-en/design.md +40 -4
- package/.claude/commands-en/diagnose.md +6 -2
- package/.claude/commands-en/front-build.md +29 -16
- package/.claude/commands-en/front-design.md +20 -1
- package/.claude/commands-en/front-plan.md +18 -5
- package/.claude/commands-en/front-reverse-design.md +183 -0
- package/.claude/commands-en/front-review.md +89 -0
- package/.claude/commands-en/plan.md +25 -9
- package/.claude/commands-en/review.md +12 -2
- package/.claude/commands-ja/add-integration-tests.md +74 -0
- package/.claude/commands-ja/design.md +40 -2
- package/.claude/commands-ja/diagnose.md +7 -3
- package/.claude/commands-ja/front-build.md +29 -16
- package/.claude/commands-ja/front-design.md +16 -1
- package/.claude/commands-ja/front-plan.md +14 -5
- package/.claude/commands-ja/front-reverse-design.md +183 -0
- package/.claude/commands-ja/front-review.md +89 -0
- package/.claude/commands-ja/plan.md +25 -7
- package/.claude/commands-ja/reverse-engineer.md +1 -1
- package/.claude/commands-ja/review.md +13 -2
- package/.claude/skills-en/documentation-criteria/SKILL.md +2 -0
- package/.claude/skills-en/documentation-criteria/references/task-template.md +38 -0
- package/.claude/skills-en/subagents-orchestration-guide/SKILL.md +14 -30
- package/.claude/skills-ja/documentation-criteria/SKILL.md +2 -0
- package/.claude/skills-ja/documentation-criteria/references/task-template.md +38 -0
- package/.claude/skills-ja/subagents-orchestration-guide/SKILL.md +15 -27
- package/README.ja.md +5 -2
- package/README.md +5 -2
- package/package.json +1 -1
|
@@ -101,46 +101,7 @@ Decompose tasks based on implementation strategy patterns determined in implemen
|
|
|
101
101
|
|
|
102
102
|
## Task File Template
|
|
103
103
|
|
|
104
|
-
|
|
105
|
-
# Task: [Task Name]
|
|
106
|
-
|
|
107
|
-
Metadata:
|
|
108
|
-
- Dependencies: task-01 → Deliverable: docs/plans/analysis/research-results.md
|
|
109
|
-
- Provides: docs/plans/analysis/api-spec.md (for research/design tasks)
|
|
110
|
-
- Size: Small (1-2 files)
|
|
111
|
-
|
|
112
|
-
## Implementation Content
|
|
113
|
-
[What this task will achieve]
|
|
114
|
-
*Reference dependency deliverables if applicable
|
|
115
|
-
|
|
116
|
-
## Target Files
|
|
117
|
-
- [ ] [Implementation file path]
|
|
118
|
-
- [ ] [Test file path]
|
|
119
|
-
|
|
120
|
-
## Implementation Steps (TDD: Red-Green-Refactor)
|
|
121
|
-
### 1. Red Phase
|
|
122
|
-
- [ ] Review dependency deliverables (if any)
|
|
123
|
-
- [ ] Verify/create type definitions
|
|
124
|
-
- [ ] Write failing tests
|
|
125
|
-
- [ ] Run tests and confirm failure
|
|
126
|
-
|
|
127
|
-
### 2. Green Phase
|
|
128
|
-
- [ ] Add minimal implementation to pass tests
|
|
129
|
-
- [ ] Run only added tests and confirm they pass
|
|
130
|
-
|
|
131
|
-
### 3. Refactor Phase
|
|
132
|
-
- [ ] Improve code (maintain passing tests)
|
|
133
|
-
- [ ] Confirm added tests still pass
|
|
134
|
-
|
|
135
|
-
## Completion Criteria
|
|
136
|
-
- [ ] All added tests pass
|
|
137
|
-
- [ ] Operation verified (select L1/L2/L3, per implementation-approach.md)
|
|
138
|
-
- [ ] Deliverables created (for research/design tasks)
|
|
139
|
-
|
|
140
|
-
## Notes
|
|
141
|
-
- Impact scope: [Areas where changes may propagate]
|
|
142
|
-
- Constraints: [Areas not to be modified]
|
|
143
|
-
```
|
|
104
|
+
See task template in documentation-criteria skill for details.
|
|
144
105
|
|
|
145
106
|
## Overall Design Document Template
|
|
146
107
|
|
|
@@ -101,46 +101,7 @@ implementation-approachスキルで決定された実装戦略パターンに基
|
|
|
101
101
|
|
|
102
102
|
## タスクファイルテンプレート
|
|
103
103
|
|
|
104
|
-
|
|
105
|
-
# タスク: [タスク名]
|
|
106
|
-
|
|
107
|
-
メタ情報:
|
|
108
|
-
- 依存: task-01 → 成果物: docs/plans/analysis/調査結果.md
|
|
109
|
-
- 提供: docs/plans/analysis/api-spec.md(調査・設計タスクの場合)
|
|
110
|
-
- サイズ: 小規模(1-2ファイル)
|
|
111
|
-
|
|
112
|
-
## 実装内容
|
|
113
|
-
[このタスクで実現すること]
|
|
114
|
-
※依存成果物がある場合、その内容を参照して実装
|
|
115
|
-
|
|
116
|
-
## 対象ファイル
|
|
117
|
-
- [ ] [実装ファイルパス]
|
|
118
|
-
- [ ] [テストファイルパス]
|
|
119
|
-
|
|
120
|
-
## 実装手順(TDD: Red-Green-Refactor)
|
|
121
|
-
### 1. Red Phase
|
|
122
|
-
- [ ] 依存成果物の確認(ある場合)
|
|
123
|
-
- [ ] 型定義の確認/作成
|
|
124
|
-
- [ ] 失敗するテストを作成
|
|
125
|
-
- [ ] テスト実行して失敗を確認
|
|
126
|
-
|
|
127
|
-
### 2. Green Phase
|
|
128
|
-
- [ ] テストが通る最小限の実装
|
|
129
|
-
- [ ] 追加したテストのみ実行して通ることを確認
|
|
130
|
-
|
|
131
|
-
### 3. Refactor Phase
|
|
132
|
-
- [ ] コード改善(テストが通る状態を維持)
|
|
133
|
-
- [ ] 追加したテストが引き続き通ることを確認
|
|
134
|
-
|
|
135
|
-
## 完了条件
|
|
136
|
-
- [ ] 追加したテストが全てパス
|
|
137
|
-
- [ ] 動作確認完了(L1/L2/L3から選択、implementation-approach.md準拠)
|
|
138
|
-
- [ ] 成果物作成完了(調査・設計タスクの場合)
|
|
139
|
-
|
|
140
|
-
## 注意事項
|
|
141
|
-
- 影響範囲: [変更が波及する箇所]
|
|
142
|
-
- 制約: [変更禁止箇所]
|
|
143
|
-
```
|
|
104
|
+
詳細はdocumentation-criteriaスキルのタスクテンプレートを参照。
|
|
144
105
|
|
|
145
106
|
## 全体設計書テンプレート
|
|
146
107
|
|
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: add-integration-tests
|
|
3
|
+
description: Add integration/E2E tests to existing backend codebase using Design Doc
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
**Command Context**: Test addition workflow for existing backend implementations
|
|
7
|
+
|
|
8
|
+
**Scope**: Backend only (acceptance-test-generator supports backend only)
|
|
9
|
+
|
|
10
|
+
## Execution Method
|
|
11
|
+
|
|
12
|
+
- Skeleton generation -> performed by acceptance-test-generator
|
|
13
|
+
- Task file creation -> following task template (see documentation-criteria skill)
|
|
14
|
+
- Test implementation -> performed by task-executor
|
|
15
|
+
- Test review -> performed by integration-test-reviewer
|
|
16
|
+
- Quality checks -> performed by quality-fixer
|
|
17
|
+
|
|
18
|
+
Orchestrator invokes sub-agents and passes structured JSON between them.
|
|
19
|
+
|
|
20
|
+
Design Doc path: $ARGUMENTS
|
|
21
|
+
|
|
22
|
+
**Think deeply** Understand the essence of test addition and execute:
|
|
23
|
+
|
|
24
|
+
## Prerequisites
|
|
25
|
+
- Design Doc must exist (created manually or via reverse-engineer)
|
|
26
|
+
- Existing implementation to test
|
|
27
|
+
|
|
28
|
+
## Execution Flow
|
|
29
|
+
|
|
30
|
+
### 1. Validate Design Doc
|
|
31
|
+
```bash
|
|
32
|
+
# Verify Design Doc exists
|
|
33
|
+
ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
### 2. Execute acceptance-test-generator
|
|
37
|
+
Generate test skeletons from Design Doc:
|
|
38
|
+
- Extract Acceptance Criteria (AC)
|
|
39
|
+
- Generate integration test skeletons (`*.int.test.ts`)
|
|
40
|
+
- Generate E2E test skeletons if applicable (`*.e2e.test.ts`)
|
|
41
|
+
|
|
42
|
+
### 3. Create Task File
|
|
43
|
+
Create task file following task template (see documentation-criteria skill):
|
|
44
|
+
- Path: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
|
|
45
|
+
- Content: Test implementation tasks based on generated skeletons
|
|
46
|
+
- Include skeleton file paths in Target Files section
|
|
47
|
+
|
|
48
|
+
### 4. Execute task-executor
|
|
49
|
+
Implement tests following the task file:
|
|
50
|
+
- Follow TDD principles (Red-Green-Refactor)
|
|
51
|
+
- Implement each skeleton test case
|
|
52
|
+
- Run tests and verify they pass
|
|
53
|
+
|
|
54
|
+
### 5. Execute integration-test-reviewer
|
|
55
|
+
Review test quality:
|
|
56
|
+
- Verify skeleton compliance
|
|
57
|
+
- Check test coverage
|
|
58
|
+
- If `needs_revision` -> Return to step 4 with `requiredFixes`
|
|
59
|
+
- If `approved` -> Proceed to quality check
|
|
60
|
+
|
|
61
|
+
### 6. Execute quality-fixer
|
|
62
|
+
Final quality assurance:
|
|
63
|
+
- Run all tests
|
|
64
|
+
- Verify coverage meets requirements
|
|
65
|
+
- Fix any quality issues
|
|
66
|
+
|
|
67
|
+
### 7. Commit
|
|
68
|
+
Commit test files with appropriate message.
|
|
69
|
+
|
|
70
|
+
## Delegation
|
|
71
|
+
- acceptance-test-generator: Skeleton generation
|
|
72
|
+
- task-executor: Test implementation
|
|
73
|
+
- integration-test-reviewer: Test quality review
|
|
74
|
+
- quality-fixer: Final quality check
|
|
@@ -4,7 +4,28 @@ description: Execute from requirement analysis to design document creation
|
|
|
4
4
|
|
|
5
5
|
**Command Context**: This command is dedicated to the design phase.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
## Orchestrator Definition
|
|
8
|
+
|
|
9
|
+
**Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
|
|
10
|
+
|
|
11
|
+
**Execution Protocol**:
|
|
12
|
+
1. **Delegate all work** to sub-agents (NEVER investigate/analyze yourself)
|
|
13
|
+
2. **Follow subagents-orchestration-guide skill design flow exactly**:
|
|
14
|
+
- Execute: requirement-analyzer → technical-designer → document-reviewer → design-sync
|
|
15
|
+
- **Stop at every `[Stop: ...]` marker** → Wait for user approval before proceeding
|
|
16
|
+
3. **Scope**: Complete when design documents receive approval
|
|
17
|
+
|
|
18
|
+
**CRITICAL**: NEVER skip document-reviewer, design-sync, or stopping points defined in subagents-orchestration-guide skill flows.
|
|
19
|
+
|
|
20
|
+
## Workflow Overview
|
|
21
|
+
|
|
22
|
+
```
|
|
23
|
+
Requirements → requirement-analyzer → [Stop: Scale determination]
|
|
24
|
+
↓
|
|
25
|
+
technical-designer → document-reviewer
|
|
26
|
+
↓
|
|
27
|
+
design-sync → [Stop: Design approval]
|
|
28
|
+
```
|
|
8
29
|
|
|
9
30
|
Requirements: $ARGUMENTS
|
|
10
31
|
|
|
@@ -17,9 +38,16 @@ Once requirements are moderately clarified, analyze with requirement-analyzer an
|
|
|
17
38
|
|
|
18
39
|
Clearly present design alternatives and trade-offs.
|
|
19
40
|
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
41
|
+
## Scope Boundaries
|
|
42
|
+
|
|
43
|
+
**Included in this command**:
|
|
44
|
+
- Requirement analysis with requirement-analyzer
|
|
45
|
+
- ADR creation (if architecture changes, new technology, or data flow changes)
|
|
46
|
+
- Design Doc creation with technical-designer
|
|
47
|
+
- Document review with document-reviewer
|
|
48
|
+
- Design Doc consistency verification with design-sync
|
|
49
|
+
|
|
50
|
+
**Responsibility Boundary**: This command completes with design document approval.
|
|
23
51
|
|
|
24
52
|
## Execution Flow
|
|
25
53
|
|
|
@@ -31,6 +59,14 @@ Clearly present design alternatives and trade-offs.
|
|
|
31
59
|
- IF conflicts found → Report to user → Wait for fix instructions → Fix with technical-designer(update)
|
|
32
60
|
- IF no conflicts → End
|
|
33
61
|
|
|
62
|
+
## Completion Criteria
|
|
63
|
+
|
|
64
|
+
- [ ] Executed requirement-analyzer and determined scale
|
|
65
|
+
- [ ] Created appropriate design document (ADR or Design Doc) with technical-designer
|
|
66
|
+
- [ ] Executed document-reviewer and addressed feedback
|
|
67
|
+
- [ ] Executed design-sync for consistency verification
|
|
68
|
+
- [ ] Obtained user approval for design document
|
|
69
|
+
|
|
34
70
|
## Output Example
|
|
35
71
|
Design phase completed.
|
|
36
72
|
- Design document: docs/design/[document-name].md
|
|
@@ -8,8 +8,12 @@ Target problem: $ARGUMENTS
|
|
|
8
8
|
|
|
9
9
|
**Role**: Orchestrator
|
|
10
10
|
|
|
11
|
-
**Execution Method**:
|
|
12
|
-
-
|
|
11
|
+
**Execution Method**:
|
|
12
|
+
- Investigation → performed by investigator
|
|
13
|
+
- Verification → performed by verifier
|
|
14
|
+
- Solution derivation → performed by solver
|
|
15
|
+
|
|
16
|
+
Orchestrator invokes sub-agents and passes structured JSON between them.
|
|
13
17
|
|
|
14
18
|
**TodoWrite Registration**: Register execution steps in TodoWrite and proceed systematically
|
|
15
19
|
|
|
@@ -2,11 +2,23 @@
|
|
|
2
2
|
description: Execute frontend implementation in autonomous execution mode
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
## Orchestrator Definition
|
|
6
|
+
|
|
7
|
+
**Core Identity**: "I am not a worker. I am an orchestrator." (see subagents-orchestration-guide skill)
|
|
8
|
+
|
|
9
|
+
**Execution Method**:
|
|
10
|
+
- Task decomposition → performed by task-decomposer
|
|
11
|
+
- Frontend implementation → performed by task-executor-frontend
|
|
12
|
+
- Quality checks and fixes → performed by quality-fixer-frontend
|
|
13
|
+
- Commits → performed by orchestrator (Bash tool)
|
|
14
|
+
|
|
15
|
+
Orchestrator invokes sub-agents and passes structured JSON between them.
|
|
16
|
+
|
|
17
|
+
**CRITICAL**: Run quality-fixer-frontend before every commit. Obtain batch approval before autonomous mode.
|
|
6
18
|
|
|
7
19
|
Work plan: $ARGUMENTS
|
|
8
20
|
|
|
9
|
-
##
|
|
21
|
+
## Pre-execution Prerequisites
|
|
10
22
|
|
|
11
23
|
### Task File Existence Check
|
|
12
24
|
```bash
|
|
@@ -27,7 +39,7 @@ Work plan: $ARGUMENTS
|
|
|
27
39
|
| No tasks + plan exists | Plan exists but no task files | Confirm with user → run task-decomposer |
|
|
28
40
|
| Neither exists | No plan or task files | Error: Prerequisites not met |
|
|
29
41
|
|
|
30
|
-
##
|
|
42
|
+
## Task Decomposition Phase (Conditional)
|
|
31
43
|
|
|
32
44
|
When task files don't exist:
|
|
33
45
|
|
|
@@ -53,12 +65,11 @@ Generate tasks from the work plan? (y/n):
|
|
|
53
65
|
! ls -la docs/plans/tasks/*.md | head -10
|
|
54
66
|
```
|
|
55
67
|
|
|
56
|
-
✅ **
|
|
57
|
-
❌ **Avoid**: Starting implementation without task generation
|
|
68
|
+
✅ **Flow**: Task generation → Autonomous execution (in this order)
|
|
58
69
|
|
|
59
|
-
##
|
|
70
|
+
## Task Execution Cycle (4-Step Cycle) - Frontend Specialized
|
|
60
71
|
|
|
61
|
-
**
|
|
72
|
+
**MANDATORY EXECUTION CYCLE**: `task-executor-frontend → escalation check → quality-fixer-frontend → commit`
|
|
62
73
|
|
|
63
74
|
### Sub-agent Invocation Method
|
|
64
75
|
Use Task tool to invoke sub-agents:
|
|
@@ -73,21 +84,23 @@ Each sub-agent responds in JSON format:
|
|
|
73
84
|
|
|
74
85
|
### Execution Flow for Each Task
|
|
75
86
|
|
|
76
|
-
|
|
87
|
+
For EACH task, YOU MUST:
|
|
77
88
|
|
|
78
|
-
1. **
|
|
89
|
+
1. **UPDATE TodoWrite**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity"
|
|
90
|
+
2. **USE task-executor-frontend**: Execute frontend implementation
|
|
79
91
|
- Invocation example: `subagent_type: "task-executor-frontend"`, `description: "Task execution"`, `prompt: "Task file: docs/plans/tasks/[filename].md Execute implementation"`
|
|
80
|
-
|
|
81
|
-
|
|
92
|
+
3. **CHECK ESCALATION**: Check task-executor-frontend status → If `status: "escalation_needed"` → STOP and escalate to user
|
|
93
|
+
4. **PROCESS structured responses**: When `readyForQualityCheck: true` is detected → EXECUTE quality-fixer-frontend IMMEDIATELY
|
|
94
|
+
5. **USE quality-fixer-frontend**: Execute all quality checks (Biome, TypeScript build, tests)
|
|
82
95
|
- Invocation example: `subagent_type: "quality-fixer-frontend"`, `description: "Quality check"`, `prompt: "Execute all frontend quality checks and fixes"`
|
|
83
|
-
|
|
96
|
+
6. **EXECUTE commit**: After `approved: true` confirmation, execute git commit IMMEDIATELY
|
|
84
97
|
|
|
85
98
|
### Quality Assurance During Autonomous Execution (Details)
|
|
86
|
-
- task-executor-frontend execution → quality-fixer-frontend execution → **
|
|
87
|
-
- After quality-fixer-frontend's `approved: true` confirmation, execute git commit
|
|
88
|
-
- Use changeSummary for commit message
|
|
99
|
+
- task-executor-frontend execution → escalation check → quality-fixer-frontend execution → **orchestrator executes commit** (using Bash tool)
|
|
100
|
+
- After quality-fixer-frontend's `approved: true` confirmation, execute git commit IMMEDIATELY
|
|
101
|
+
- Use `changeSummary` for commit message
|
|
89
102
|
|
|
90
|
-
**
|
|
103
|
+
**CRITICAL**: Monitor ALL structured responses WITHOUT EXCEPTION and ENSURE every quality gate is passed.
|
|
91
104
|
|
|
92
105
|
! ls -la docs/plans/*.md | head -10
|
|
93
106
|
|
|
@@ -4,7 +4,26 @@ description: Execute from requirement analysis to frontend design document creat
|
|
|
4
4
|
|
|
5
5
|
**Command Context**: This command is dedicated to the frontend design phase.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
## Orchestrator Definition
|
|
8
|
+
|
|
9
|
+
**Role**: Orchestrator
|
|
10
|
+
|
|
11
|
+
**Execution Method**:
|
|
12
|
+
- Requirement analysis → performed by requirement-analyzer
|
|
13
|
+
- Design document creation → performed by technical-designer-frontend
|
|
14
|
+
- Document review → performed by document-reviewer
|
|
15
|
+
|
|
16
|
+
Orchestrator invokes sub-agents and passes structured JSON between them.
|
|
17
|
+
|
|
18
|
+
## Scope Boundaries
|
|
19
|
+
|
|
20
|
+
**Included in this command**:
|
|
21
|
+
- Requirement analysis with requirement-analyzer
|
|
22
|
+
- ADR creation (if architecture changes, new technology, or data flow changes)
|
|
23
|
+
- Design Doc creation with technical-designer-frontend
|
|
24
|
+
- Document review with document-reviewer
|
|
25
|
+
|
|
26
|
+
**Responsibility Boundary**: This command completes with design document approval.
|
|
8
27
|
|
|
9
28
|
Requirements: $ARGUMENTS
|
|
10
29
|
|
|
@@ -4,6 +4,24 @@ description: Create frontend work plan from design document and obtain plan appr
|
|
|
4
4
|
|
|
5
5
|
**Command Context**: This command is dedicated to the frontend planning phase.
|
|
6
6
|
|
|
7
|
+
## Orchestrator Definition
|
|
8
|
+
|
|
9
|
+
**Role**: Orchestrator
|
|
10
|
+
|
|
11
|
+
**Execution Method**:
|
|
12
|
+
- Work plan creation → performed by work-planner
|
|
13
|
+
|
|
14
|
+
Orchestrator invokes sub-agents and passes structured JSON between them.
|
|
15
|
+
|
|
16
|
+
## Scope Boundaries
|
|
17
|
+
|
|
18
|
+
**Included in this command**:
|
|
19
|
+
- Design document selection
|
|
20
|
+
- Work plan creation with work-planner
|
|
21
|
+
- Plan approval obtainment
|
|
22
|
+
|
|
23
|
+
**Responsibility Boundary**: This command completes with work plan approval.
|
|
24
|
+
|
|
7
25
|
Create frontend work plan with the following process:
|
|
8
26
|
|
|
9
27
|
## Execution Process
|
|
@@ -33,8 +51,3 @@ Frontend planning phase completed.
|
|
|
33
51
|
|
|
34
52
|
Please provide separate instructions for implementation.
|
|
35
53
|
```
|
|
36
|
-
|
|
37
|
-
❌ **Avoid**: Additional processing after plan approval (task decomposition, implementation start, etc.)
|
|
38
|
-
- Reason: Exceeds the scope of the planning phase
|
|
39
|
-
|
|
40
|
-
**Responsibility Boundary**: This command is responsible for the frontend planning phase and completes its responsibility with plan content approval. The implementation phase is outside the scope of responsibility, so quality cannot be guaranteed and automatic transition does not occur.
|
|
@@ -0,0 +1,183 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: front-reverse-design
|
|
3
|
+
description: Generate frontend Design Docs from existing codebase using existing PRD
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
**Command Context**: Reverse engineering workflow to create frontend Design Docs from existing code
|
|
7
|
+
|
|
8
|
+
**Prerequisites**: PRD must exist (created via reverse-engineer or manually)
|
|
9
|
+
|
|
10
|
+
Target PRD: $ARGUMENTS
|
|
11
|
+
|
|
12
|
+
**TodoWrite**: Register phases first, then steps within each phase as you enter it.
|
|
13
|
+
|
|
14
|
+
## Step 0: Initial Configuration
|
|
15
|
+
|
|
16
|
+
### 0.1 Scope Confirmation
|
|
17
|
+
|
|
18
|
+
Use AskUserQuestion to confirm:
|
|
19
|
+
1. **PRD path**: Which PRD to use as basis
|
|
20
|
+
2. **Target path**: Which frontend directory/module to document
|
|
21
|
+
3. **Human review**: Yes (recommended) / No (fully autonomous)
|
|
22
|
+
|
|
23
|
+
### 0.2 Output Configuration
|
|
24
|
+
|
|
25
|
+
- Design Doc output: `docs/design/` or existing design directory
|
|
26
|
+
- Verify directories exist, create if needed
|
|
27
|
+
|
|
28
|
+
## Workflow Overview
|
|
29
|
+
|
|
30
|
+
```
|
|
31
|
+
Step 1: Scope Discovery (all frontend components per PRD)
|
|
32
|
+
Step 2-5: Per-component loop (Generation -> Verification -> Review -> Revision)
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
**Context Passing**: Pass structured JSON output between steps. Use `$STEP_N_OUTPUT` placeholder notation.
|
|
36
|
+
|
|
37
|
+
## Step 1: Design Doc Scope Discovery
|
|
38
|
+
|
|
39
|
+
**Task invocation**:
|
|
40
|
+
```
|
|
41
|
+
subagent_type: scope-discoverer
|
|
42
|
+
prompt: |
|
|
43
|
+
Discover frontend Design Doc targets within PRD scope.
|
|
44
|
+
|
|
45
|
+
scope_type: design-doc
|
|
46
|
+
existing_prd: $USER_PRD_PATH
|
|
47
|
+
target_path: $USER_TARGET_PATH
|
|
48
|
+
focus: frontend (React/TypeScript components, hooks, state management)
|
|
49
|
+
```
|
|
50
|
+
|
|
51
|
+
**Store output as**: `$STEP_1_OUTPUT`
|
|
52
|
+
|
|
53
|
+
**Quality Gate**:
|
|
54
|
+
- At least one component discovered -> proceed
|
|
55
|
+
- No components -> ask user for hints
|
|
56
|
+
|
|
57
|
+
**Human Review Point** (if enabled): Present discovered components for confirmation.
|
|
58
|
+
|
|
59
|
+
## Step 2-5: Per-Component Processing
|
|
60
|
+
|
|
61
|
+
**Complete Steps 2->3->4->5 for each component before proceeding to the next component.**
|
|
62
|
+
|
|
63
|
+
### Step 2: Design Doc Generation
|
|
64
|
+
|
|
65
|
+
**Task invocation**:
|
|
66
|
+
```
|
|
67
|
+
subagent_type: technical-designer-frontend
|
|
68
|
+
prompt: |
|
|
69
|
+
Create Design Doc for the following frontend component based on existing code.
|
|
70
|
+
|
|
71
|
+
Operation Mode: create
|
|
72
|
+
|
|
73
|
+
Component: $COMPONENT_NAME (from $STEP_1_OUTPUT)
|
|
74
|
+
Responsibility: $COMPONENT_RESPONSIBILITY
|
|
75
|
+
Primary Files: $COMPONENT_PRIMARY_FILES
|
|
76
|
+
Public Interfaces: $COMPONENT_PUBLIC_INTERFACES
|
|
77
|
+
Dependencies: $COMPONENT_DEPENDENCIES
|
|
78
|
+
|
|
79
|
+
Parent PRD: $USER_PRD_PATH
|
|
80
|
+
|
|
81
|
+
Document current architecture. Do not propose changes.
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
**Store output as**: `$STEP_2_OUTPUT`
|
|
85
|
+
|
|
86
|
+
### Step 3: Code Verification
|
|
87
|
+
|
|
88
|
+
**Task invocation**:
|
|
89
|
+
```
|
|
90
|
+
subagent_type: code-verifier
|
|
91
|
+
prompt: |
|
|
92
|
+
Verify consistency between Design Doc and code implementation.
|
|
93
|
+
|
|
94
|
+
doc_type: design-doc
|
|
95
|
+
document_path: $STEP_2_OUTPUT
|
|
96
|
+
code_paths: $COMPONENT_PRIMARY_FILES
|
|
97
|
+
verbose: false
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
**Store output as**: `$STEP_3_OUTPUT`
|
|
101
|
+
|
|
102
|
+
**Quality Gate**:
|
|
103
|
+
- consistencyScore >= 70 -> proceed to review
|
|
104
|
+
- consistencyScore < 70 -> flag for detailed review
|
|
105
|
+
|
|
106
|
+
### Step 4: Review
|
|
107
|
+
|
|
108
|
+
**Required Input**: $STEP_3_OUTPUT (verification JSON from Step 3)
|
|
109
|
+
|
|
110
|
+
**Task invocation**:
|
|
111
|
+
```
|
|
112
|
+
subagent_type: document-reviewer
|
|
113
|
+
prompt: |
|
|
114
|
+
Review the following Design Doc considering code verification findings.
|
|
115
|
+
|
|
116
|
+
doc_type: DesignDoc
|
|
117
|
+
target: $STEP_2_OUTPUT
|
|
118
|
+
mode: composite
|
|
119
|
+
|
|
120
|
+
## Code Verification Results
|
|
121
|
+
$STEP_3_OUTPUT
|
|
122
|
+
|
|
123
|
+
## Parent PRD
|
|
124
|
+
$USER_PRD_PATH
|
|
125
|
+
|
|
126
|
+
## Additional Review Focus
|
|
127
|
+
- Technical accuracy of documented interfaces
|
|
128
|
+
- Consistency with parent PRD scope
|
|
129
|
+
- Completeness of component boundary definitions
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
**Store output as**: `$STEP_4_OUTPUT`
|
|
133
|
+
|
|
134
|
+
### Step 5: Revision (conditional)
|
|
135
|
+
|
|
136
|
+
**Trigger Conditions** (any one of the following):
|
|
137
|
+
- Review status is "Needs Revision" or "Rejected"
|
|
138
|
+
- Critical discrepancies exist in `$STEP_3_OUTPUT`
|
|
139
|
+
- consistencyScore < 70
|
|
140
|
+
|
|
141
|
+
**Task invocation**:
|
|
142
|
+
```
|
|
143
|
+
subagent_type: technical-designer-frontend
|
|
144
|
+
prompt: |
|
|
145
|
+
Update Design Doc based on review feedback.
|
|
146
|
+
|
|
147
|
+
Operation Mode: update
|
|
148
|
+
Existing Design Doc: $STEP_2_OUTPUT
|
|
149
|
+
|
|
150
|
+
## Review Feedback
|
|
151
|
+
$STEP_4_OUTPUT
|
|
152
|
+
|
|
153
|
+
## Discrepancies to Address
|
|
154
|
+
(Extract critical and major discrepancies from $STEP_3_OUTPUT)
|
|
155
|
+
|
|
156
|
+
Apply corrections and improvements.
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
**Loop Control**: Maximum 2 revision cycles. After 2 cycles, flag for human review regardless of status.
|
|
160
|
+
|
|
161
|
+
### Component Completion
|
|
162
|
+
|
|
163
|
+
- [ ] Review status is "Approved" or "Approved with Conditions"
|
|
164
|
+
- [ ] Human review passed (if enabled in Step 0)
|
|
165
|
+
|
|
166
|
+
**Next**: Proceed to next component. After all components -> Final Report.
|
|
167
|
+
|
|
168
|
+
## Final Report
|
|
169
|
+
|
|
170
|
+
Output summary including:
|
|
171
|
+
- Generated documents table (Component, Design Doc Path, Consistency Score, Review Status)
|
|
172
|
+
- Action items (critical discrepancies, undocumented features, flagged items)
|
|
173
|
+
- Next steps checklist
|
|
174
|
+
|
|
175
|
+
## Error Handling
|
|
176
|
+
|
|
177
|
+
| Error | Action |
|
|
178
|
+
|-------|--------|
|
|
179
|
+
| PRD not found | Ask user for correct PRD path |
|
|
180
|
+
| Discovery finds nothing | Ask user for project structure hints |
|
|
181
|
+
| Generation fails | Log failure, continue with other components, report in summary |
|
|
182
|
+
| consistencyScore < 50 | Flag for mandatory human review, do not auto-approve |
|
|
183
|
+
| Review rejects after 2 revisions | Stop loop, flag for human intervention |
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: front-review
|
|
3
|
+
description: Design Doc compliance validation with optional auto-fixes
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
**Command Context**: Post-implementation quality assurance command for React/TypeScript frontend
|
|
7
|
+
|
|
8
|
+
## Execution Method
|
|
9
|
+
|
|
10
|
+
- Compliance validation -> performed by code-reviewer
|
|
11
|
+
- Rule analysis -> performed by rule-advisor
|
|
12
|
+
- Fix implementation -> performed by task-executor-frontend
|
|
13
|
+
- Quality checks -> performed by quality-fixer-frontend
|
|
14
|
+
- Re-validation -> performed by code-reviewer
|
|
15
|
+
|
|
16
|
+
Orchestrator invokes sub-agents and passes structured JSON between them.
|
|
17
|
+
|
|
18
|
+
Design Doc (uses most recent if omitted): $ARGUMENTS
|
|
19
|
+
|
|
20
|
+
**Think deeply** Understand the essence of compliance validation and execute:
|
|
21
|
+
|
|
22
|
+
## Execution Flow
|
|
23
|
+
|
|
24
|
+
### 1. Prerequisite Check
|
|
25
|
+
```bash
|
|
26
|
+
# Identify Design Doc
|
|
27
|
+
ls docs/design/*.md | grep -v template | tail -1
|
|
28
|
+
|
|
29
|
+
# Check implementation files
|
|
30
|
+
git diff --name-only main...HEAD
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
### 2. Execute code-reviewer
|
|
34
|
+
Validate Design Doc compliance:
|
|
35
|
+
- Acceptance criteria fulfillment
|
|
36
|
+
- Code quality check
|
|
37
|
+
- Implementation completeness assessment
|
|
38
|
+
|
|
39
|
+
### 3. Verdict and Response
|
|
40
|
+
|
|
41
|
+
**Criteria (considering project stage)**:
|
|
42
|
+
- Prototype: Pass at 70%+
|
|
43
|
+
- Production: 90%+ recommended
|
|
44
|
+
- Critical items (security, etc.): Required regardless of rate
|
|
45
|
+
|
|
46
|
+
**Compliance-based response**:
|
|
47
|
+
|
|
48
|
+
For low compliance (production <90%):
|
|
49
|
+
```
|
|
50
|
+
Validation Result: [X]% compliance
|
|
51
|
+
Unfulfilled items:
|
|
52
|
+
- [item list]
|
|
53
|
+
|
|
54
|
+
Execute fixes? (y/n):
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
If user selects `y`:
|
|
58
|
+
|
|
59
|
+
## Pre-fix Metacognition
|
|
60
|
+
**Required**: `rule-advisor -> TodoWrite -> task-executor-frontend -> quality-fixer-frontend`
|
|
61
|
+
|
|
62
|
+
1. **Execute rule-advisor**: Understand fix essence (symptomatic treatment vs root solution)
|
|
63
|
+
2. **Update TodoWrite**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Create task file following task template (see documentation-criteria skill) -> `docs/plans/tasks/review-fixes-YYYYMMDD.md`
|
|
64
|
+
3. **Execute task-executor-frontend**: Staged auto-fixes (stops at 5 files)
|
|
65
|
+
4. **Execute quality-fixer-frontend**: Confirm quality gate passage
|
|
66
|
+
5. **Re-validate**: Measure improvement with code-reviewer
|
|
67
|
+
|
|
68
|
+
### 4. Final Report
|
|
69
|
+
```
|
|
70
|
+
Initial compliance: [X]%
|
|
71
|
+
Final compliance: [Y]% (if fixes executed)
|
|
72
|
+
Improvement: [Y-X]%
|
|
73
|
+
|
|
74
|
+
Remaining issues:
|
|
75
|
+
- [items requiring manual intervention]
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
## Auto-fixable Items
|
|
79
|
+
- Simple unimplemented acceptance criteria
|
|
80
|
+
- Error handling additions
|
|
81
|
+
- Contract definition fixes
|
|
82
|
+
- Function splitting (length/complexity improvements)
|
|
83
|
+
|
|
84
|
+
## Non-fixable Items
|
|
85
|
+
- Fundamental business logic changes
|
|
86
|
+
- Architecture-level modifications
|
|
87
|
+
- Design Doc deficiencies
|
|
88
|
+
|
|
89
|
+
**Scope**: Design Doc compliance validation and auto-fixes.
|