create-ai-project 1.11.2
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/acceptance-test-generator.md +316 -0
- package/.claude/agents/code-reviewer.md +193 -0
- package/.claude/agents/document-reviewer.md +182 -0
- package/.claude/agents/prd-creator.md +186 -0
- package/.claude/agents/quality-fixer.md +295 -0
- package/.claude/agents/requirement-analyzer.md +161 -0
- package/.claude/agents/rule-advisor.md +194 -0
- package/.claude/agents/task-decomposer.md +291 -0
- package/.claude/agents/task-executor.md +270 -0
- package/.claude/agents/technical-designer.md +343 -0
- package/.claude/agents/work-planner.md +181 -0
- package/.claude/agents-en/acceptance-test-generator.md +256 -0
- package/.claude/agents-en/code-reviewer.md +195 -0
- package/.claude/agents-en/design-sync.md +225 -0
- package/.claude/agents-en/document-reviewer.md +190 -0
- package/.claude/agents-en/integration-test-reviewer.md +195 -0
- package/.claude/agents-en/prd-creator.md +196 -0
- package/.claude/agents-en/quality-fixer-frontend.md +334 -0
- package/.claude/agents-en/quality-fixer.md +291 -0
- package/.claude/agents-en/requirement-analyzer.md +165 -0
- package/.claude/agents-en/rule-advisor.md +194 -0
- package/.claude/agents-en/task-decomposer.md +291 -0
- package/.claude/agents-en/task-executor-frontend.md +276 -0
- package/.claude/agents-en/task-executor.md +272 -0
- package/.claude/agents-en/technical-designer-frontend.md +441 -0
- package/.claude/agents-en/technical-designer.md +371 -0
- package/.claude/agents-en/work-planner.md +216 -0
- package/.claude/agents-ja/acceptance-test-generator.md +256 -0
- package/.claude/agents-ja/code-reviewer.md +195 -0
- package/.claude/agents-ja/design-sync.md +225 -0
- package/.claude/agents-ja/document-reviewer.md +192 -0
- package/.claude/agents-ja/integration-test-reviewer.md +195 -0
- package/.claude/agents-ja/prd-creator.md +194 -0
- package/.claude/agents-ja/quality-fixer-frontend.md +335 -0
- package/.claude/agents-ja/quality-fixer.md +292 -0
- package/.claude/agents-ja/requirement-analyzer.md +164 -0
- package/.claude/agents-ja/rule-advisor.md +194 -0
- package/.claude/agents-ja/task-decomposer.md +291 -0
- package/.claude/agents-ja/task-executor-frontend.md +276 -0
- package/.claude/agents-ja/task-executor.md +272 -0
- package/.claude/agents-ja/technical-designer-frontend.md +442 -0
- package/.claude/agents-ja/technical-designer.md +370 -0
- package/.claude/agents-ja/work-planner.md +213 -0
- package/.claude/commands/build.md +78 -0
- package/.claude/commands/design.md +27 -0
- package/.claude/commands/implement.md +79 -0
- package/.claude/commands/plan.md +43 -0
- package/.claude/commands/project-inject.md +76 -0
- package/.claude/commands/refine-rule.md +206 -0
- package/.claude/commands/review.md +78 -0
- package/.claude/commands/sync-rules.md +116 -0
- package/.claude/commands/task.md +13 -0
- package/.claude/commands-en/build.md +77 -0
- package/.claude/commands-en/design.md +39 -0
- package/.claude/commands-en/front-build.md +103 -0
- package/.claude/commands-en/front-design.md +42 -0
- package/.claude/commands-en/front-plan.md +40 -0
- package/.claude/commands-en/implement.md +75 -0
- package/.claude/commands-en/plan.md +45 -0
- package/.claude/commands-en/project-inject.md +76 -0
- package/.claude/commands-en/refine-rule.md +208 -0
- package/.claude/commands-en/review.md +78 -0
- package/.claude/commands-en/sync-rules.md +116 -0
- package/.claude/commands-en/task.md +13 -0
- package/.claude/commands-ja/build.md +75 -0
- package/.claude/commands-ja/design.md +37 -0
- package/.claude/commands-ja/front-build.md +103 -0
- package/.claude/commands-ja/front-design.md +42 -0
- package/.claude/commands-ja/front-plan.md +40 -0
- package/.claude/commands-ja/implement.md +73 -0
- package/.claude/commands-ja/plan.md +43 -0
- package/.claude/commands-ja/project-inject.md +76 -0
- package/.claude/commands-ja/refine-rule.md +206 -0
- package/.claude/commands-ja/review.md +78 -0
- package/.claude/commands-ja/sync-rules.md +116 -0
- package/.claude/commands-ja/task.md +13 -0
- package/.claude/settings.local.json +74 -0
- package/.husky/pre-commit +1 -0
- package/.husky/pre-push +3 -0
- package/.madgerc +14 -0
- package/.tsprunerc +11 -0
- package/CLAUDE.en.md +102 -0
- package/CLAUDE.ja.md +102 -0
- package/CLAUDE.md +111 -0
- package/LICENSE +21 -0
- package/README.ja.md +233 -0
- package/README.md +243 -0
- package/bin/create-project.js +87 -0
- package/biome.json +51 -0
- package/docs/adr/template-en.md +64 -0
- package/docs/adr/template-ja.md +64 -0
- package/docs/design/template-en.md +281 -0
- package/docs/design/template-ja.md +285 -0
- package/docs/guides/en/quickstart.md +111 -0
- package/docs/guides/en/rule-editing-guide.md +266 -0
- package/docs/guides/en/sub-agents.md +343 -0
- package/docs/guides/en/use-cases.md +308 -0
- package/docs/guides/ja/quickstart.md +112 -0
- package/docs/guides/ja/rule-editing-guide.md +266 -0
- package/docs/guides/ja/sub-agents.md +343 -0
- package/docs/guides/ja/use-cases.md +290 -0
- package/docs/guides/sub-agents.md +306 -0
- package/docs/plans/20250123-integration-test-improvement.md +993 -0
- package/docs/plans/template-en.md +130 -0
- package/docs/plans/template-ja.md +130 -0
- package/docs/prd/template-en.md +109 -0
- package/docs/prd/template-ja.md +109 -0
- package/docs/rules/ai-development-guide.md +260 -0
- package/docs/rules/architecture/implementation-approach.md +136 -0
- package/docs/rules/documentation-criteria.md +180 -0
- package/docs/rules/project-context.md +38 -0
- package/docs/rules/rules-index.yaml +137 -0
- package/docs/rules/technical-spec.md +47 -0
- package/docs/rules/typescript-testing.md +188 -0
- package/docs/rules/typescript.md +166 -0
- package/docs/rules-en/architecture/implementation-approach.md +136 -0
- package/docs/rules-en/coding-standards.md +333 -0
- package/docs/rules-en/documentation-criteria.md +184 -0
- package/docs/rules-en/frontend/technical-spec.md +143 -0
- package/docs/rules-en/frontend/typescript-testing.md +124 -0
- package/docs/rules-en/frontend/typescript.md +131 -0
- package/docs/rules-en/integration-e2e-testing.md +149 -0
- package/docs/rules-en/project-context.md +38 -0
- package/docs/rules-en/rules-index.yaml +211 -0
- package/docs/rules-en/technical-spec.md +86 -0
- package/docs/rules-en/typescript-testing.md +149 -0
- package/docs/rules-en/typescript.md +116 -0
- package/docs/rules-ja/architecture/implementation-approach.md +136 -0
- package/docs/rules-ja/coding-standards.md +333 -0
- package/docs/rules-ja/documentation-criteria.md +180 -0
- package/docs/rules-ja/frontend/technical-spec.md +143 -0
- package/docs/rules-ja/frontend/typescript-testing.md +124 -0
- package/docs/rules-ja/frontend/typescript.md +131 -0
- package/docs/rules-ja/integration-e2e-testing.md +149 -0
- package/docs/rules-ja/project-context.md +38 -0
- package/docs/rules-ja/rules-index.yaml +196 -0
- package/docs/rules-ja/technical-spec.md +86 -0
- package/docs/rules-ja/typescript-testing.md +149 -0
- package/docs/rules-ja/typescript.md +116 -0
- package/package.json +98 -0
- package/scripts/check-unused-exports.js +69 -0
- package/scripts/cleanup-test-processes.sh +32 -0
- package/scripts/post-setup.js +110 -0
- package/scripts/set-language.js +310 -0
- package/scripts/setup-project.js +199 -0
- package/scripts/show-coverage.js +74 -0
- package/src/index.ts +11 -0
- package/templates/.gitignore.template +52 -0
- package/tsconfig.json +50 -0
- package/vitest.config.mjs +47 -0
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Execute decomposed tasks in autonomous execution mode
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Follow @docs/guides/sub-agents.md strictly and act as the **orchestrator**.
|
|
6
|
+
|
|
7
|
+
Work plan: $ARGUMENTS
|
|
8
|
+
|
|
9
|
+
## 📋 Pre-execution Prerequisites
|
|
10
|
+
|
|
11
|
+
### Task File Existence Check
|
|
12
|
+
```bash
|
|
13
|
+
# Check work plans
|
|
14
|
+
! ls -la docs/plans/*.md | grep -v template | tail -5
|
|
15
|
+
|
|
16
|
+
# Check task files
|
|
17
|
+
! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ No task files found"
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
### Task Generation Decision Flow
|
|
21
|
+
|
|
22
|
+
**Think deeply** Analyze task file existence state and determine the appropriate action:
|
|
23
|
+
|
|
24
|
+
| State | Criteria | Next Action |
|
|
25
|
+
|-------|----------|-------------|
|
|
26
|
+
| Tasks exist | .md files in tasks/ directory | Proceed to autonomous execution |
|
|
27
|
+
| No tasks + plan exists | Plan exists but no task files | Confirm with user → run task-decomposer |
|
|
28
|
+
| Neither exists | No plan or task files | Error: Prerequisites not met |
|
|
29
|
+
|
|
30
|
+
## 🔄 Task Decomposition Phase (Conditional)
|
|
31
|
+
|
|
32
|
+
When task files don't exist:
|
|
33
|
+
|
|
34
|
+
### 1. User Confirmation
|
|
35
|
+
```
|
|
36
|
+
No task files found.
|
|
37
|
+
Work plan: docs/plans/[plan-name].md
|
|
38
|
+
|
|
39
|
+
Generate tasks from the work plan? (y/n):
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### 2. Task Decomposition (if approved)
|
|
43
|
+
```
|
|
44
|
+
@task-decomposer Read work plan and decompose into atomic tasks:
|
|
45
|
+
- Input: docs/plans/[plan-name].md
|
|
46
|
+
- Output: Individual task files in docs/plans/tasks/
|
|
47
|
+
- Granularity: 1 task = 1 commit = independently executable
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
### 3. Verify Generation
|
|
51
|
+
```bash
|
|
52
|
+
# Verify generated task files
|
|
53
|
+
! ls -la docs/plans/tasks/*.md | head -10
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
✅ **Recommended**: After task generation, automatically proceed to autonomous execution
|
|
57
|
+
❌ **Avoid**: Starting implementation without task generation
|
|
58
|
+
|
|
59
|
+
## 🧠 Task Execution Flow
|
|
60
|
+
Following "Autonomous Execution Task Management" in sub-agents.md, manage 4 steps with TodoWrite:
|
|
61
|
+
1. task-executor execution
|
|
62
|
+
2. Escalation judgment and follow-up
|
|
63
|
+
3. quality-fixer execution
|
|
64
|
+
4. git commit
|
|
65
|
+
|
|
66
|
+
After approval confirmation, start autonomous execution mode. Stop immediately when requirement changes detected.
|
|
67
|
+
|
|
68
|
+
## Output Example
|
|
69
|
+
Implementation phase completed.
|
|
70
|
+
- Task decomposition: Generated under docs/plans/tasks/ (if executed)
|
|
71
|
+
- Implemented tasks: [number] tasks
|
|
72
|
+
- Quality checks: All passed
|
|
73
|
+
- Commits: [number] commits created
|
|
74
|
+
|
|
75
|
+
**Responsibility Boundary**:
|
|
76
|
+
- IN SCOPE: Task decomposition to implementation completion
|
|
77
|
+
- OUT OF SCOPE: Design phase, planning phase
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Execute from requirement analysis to design document creation
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
**Command Context**: This command is dedicated to the design phase.
|
|
6
|
+
|
|
7
|
+
Following the design flow described in @docs/guides/sub-agents.md, execute **from requirement-analyzer to design document creation and approval**.
|
|
8
|
+
|
|
9
|
+
Requirements: $ARGUMENTS
|
|
10
|
+
|
|
11
|
+
**Think harder** Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
|
|
12
|
+
- What problems do you want to solve?
|
|
13
|
+
- Expected outcomes and success criteria
|
|
14
|
+
- Relationship with existing systems
|
|
15
|
+
|
|
16
|
+
Once requirements are moderately clarified, analyze with requirement-analyzer and create appropriate design documents according to scale.
|
|
17
|
+
|
|
18
|
+
Clearly present design alternatives and trade-offs.
|
|
19
|
+
|
|
20
|
+
**Scope Boundary**:
|
|
21
|
+
- IN SCOPE: Design document (ADR/Design Doc) approval + Design Doc consistency verification
|
|
22
|
+
- OUT OF SCOPE: Work planning and implementation phases
|
|
23
|
+
|
|
24
|
+
## Execution Flow
|
|
25
|
+
|
|
26
|
+
1. requirement-analyzer → Requirement analysis
|
|
27
|
+
2. technical-designer → Design Doc creation
|
|
28
|
+
3. document-reviewer → Single document quality check
|
|
29
|
+
4. User approval (WAIT for approval)
|
|
30
|
+
5. design-sync → Design Doc consistency verification
|
|
31
|
+
- IF conflicts found → Report to user → Wait for fix instructions → Fix with technical-designer(update)
|
|
32
|
+
- IF no conflicts → End
|
|
33
|
+
|
|
34
|
+
## Output Example
|
|
35
|
+
Design phase completed.
|
|
36
|
+
- Design document: docs/design/[document-name].md
|
|
37
|
+
- Consistency: No conflicts with other Design Docs (or fixes completed)
|
|
38
|
+
|
|
39
|
+
**Important**: This command ends with design approval + consistency verification. Does not propose transition to next phase.
|
|
@@ -0,0 +1,103 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Execute frontend implementation in autonomous execution mode
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
**Command Context**: As orchestrator, autonomously completes frontend implementation in autonomous execution mode.
|
|
6
|
+
|
|
7
|
+
Work plan: $ARGUMENTS
|
|
8
|
+
|
|
9
|
+
## 📋 Pre-execution Prerequisites
|
|
10
|
+
|
|
11
|
+
### Task File Existence Check
|
|
12
|
+
```bash
|
|
13
|
+
# Check work plans
|
|
14
|
+
! ls -la docs/plans/*.md | grep -v template | tail -5
|
|
15
|
+
|
|
16
|
+
# Check task files
|
|
17
|
+
! ls docs/plans/tasks/*.md 2>/dev/null || echo "⚠️ No task files found"
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
### Task Generation Decision Flow
|
|
21
|
+
|
|
22
|
+
**Think deeply**: Analyze task file existence state and determine the appropriate action:
|
|
23
|
+
|
|
24
|
+
| State | Criteria | Next Action |
|
|
25
|
+
|-------|----------|-------------|
|
|
26
|
+
| Tasks exist | .md files in tasks/ directory | Proceed to autonomous execution |
|
|
27
|
+
| No tasks + plan exists | Plan exists but no task files | Confirm with user → run task-decomposer |
|
|
28
|
+
| Neither exists | No plan or task files | Error: Prerequisites not met |
|
|
29
|
+
|
|
30
|
+
## 🔄 Task Decomposition Phase (Conditional)
|
|
31
|
+
|
|
32
|
+
When task files don't exist:
|
|
33
|
+
|
|
34
|
+
### 1. User Confirmation
|
|
35
|
+
```
|
|
36
|
+
No task files found.
|
|
37
|
+
Work plan: docs/plans/[plan-name].md
|
|
38
|
+
|
|
39
|
+
Generate tasks from the work plan? (y/n):
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### 2. Task Decomposition (if approved)
|
|
43
|
+
```
|
|
44
|
+
@task-decomposer Read work plan and decompose into atomic tasks:
|
|
45
|
+
- Input: docs/plans/[plan-name].md
|
|
46
|
+
- Output: Individual task files in docs/plans/tasks/
|
|
47
|
+
- Granularity: 1 task = 1 commit = independently executable
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
### 3. Verify Generation
|
|
51
|
+
```bash
|
|
52
|
+
# Verify generated task files
|
|
53
|
+
! ls -la docs/plans/tasks/*.md | head -10
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
✅ **Recommended**: After task generation, automatically proceed to autonomous execution
|
|
57
|
+
❌ **Avoid**: Starting implementation without task generation
|
|
58
|
+
|
|
59
|
+
## 🧠 Metacognition for Each Task - Frontend Specialized
|
|
60
|
+
|
|
61
|
+
**Required Execution Cycle**: `task-executor-frontend → quality-fixer-frontend → commit`
|
|
62
|
+
|
|
63
|
+
### Sub-agent Invocation Method
|
|
64
|
+
Use Task tool to invoke sub-agents:
|
|
65
|
+
- `subagent_type`: Agent name
|
|
66
|
+
- `description`: Brief task description (3-5 words)
|
|
67
|
+
- `prompt`: Specific instructions
|
|
68
|
+
|
|
69
|
+
### Structured Response Specification
|
|
70
|
+
Each sub-agent responds in JSON format:
|
|
71
|
+
- **task-executor-frontend**: status, filesModified, testsAdded, readyForQualityCheck
|
|
72
|
+
- **quality-fixer-frontend**: status, checksPerformed, fixesApplied, approved
|
|
73
|
+
|
|
74
|
+
### Execution Flow for Each Task
|
|
75
|
+
|
|
76
|
+
Execute for EACH task:
|
|
77
|
+
|
|
78
|
+
1. **USE task-executor-frontend**: Execute frontend implementation
|
|
79
|
+
- Invocation example: `subagent_type: "task-executor-frontend"`, `description: "Task execution"`, `prompt: "Task file: docs/plans/tasks/[filename].md Execute implementation"`
|
|
80
|
+
2. **PROCESS structured responses**: When `readyForQualityCheck: true` is detected → Execute quality-fixer-frontend immediately
|
|
81
|
+
3. **USE quality-fixer-frontend**: Execute all quality checks (Biome, TypeScript build, tests)
|
|
82
|
+
- Invocation example: `subagent_type: "quality-fixer-frontend"`, `description: "Quality check"`, `prompt: "Execute all frontend quality checks and fixes"`
|
|
83
|
+
4. **EXECUTE commit**: After `approved: true` confirmation, execute git commit immediately
|
|
84
|
+
|
|
85
|
+
### Quality Assurance During Autonomous Execution (Details)
|
|
86
|
+
- task-executor-frontend execution → quality-fixer-frontend execution → **I (Main AI) execute commit** (using Bash tool)
|
|
87
|
+
- After quality-fixer-frontend's `approved: true` confirmation, execute git commit immediately
|
|
88
|
+
- Use changeSummary for commit message
|
|
89
|
+
|
|
90
|
+
**Think deeply**: Monitor all structured responses and ensure every quality gate is passed.
|
|
91
|
+
|
|
92
|
+
! ls -la docs/plans/*.md | head -10
|
|
93
|
+
|
|
94
|
+
Verify approval status before proceeding. Once confirmed, initiate autonomous execution mode. Stop immediately upon detecting any requirement changes.
|
|
95
|
+
|
|
96
|
+
## Output Example
|
|
97
|
+
Frontend implementation phase completed.
|
|
98
|
+
- Task decomposition: Generated under docs/plans/tasks/
|
|
99
|
+
- Implemented tasks: [number] tasks
|
|
100
|
+
- Quality checks: All passed (Biome, TypeScript build, tests)
|
|
101
|
+
- Commits: [number] commits created
|
|
102
|
+
|
|
103
|
+
**Important**: This command manages the entire autonomous execution flow for frontend implementation from task decomposition to completion. Automatically uses frontend-specialized agents (task-executor-frontend, quality-fixer-frontend).
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Execute from requirement analysis to frontend design document creation
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
**Command Context**: This command is dedicated to the frontend design phase.
|
|
6
|
+
|
|
7
|
+
Execute **from requirement analysis to frontend design document creation and approval**.
|
|
8
|
+
|
|
9
|
+
Requirements: $ARGUMENTS
|
|
10
|
+
|
|
11
|
+
## Execution Flow
|
|
12
|
+
|
|
13
|
+
### 1. Requirement Analysis Phase
|
|
14
|
+
**Think harder**: Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
|
|
15
|
+
- What problems do you want to solve?
|
|
16
|
+
- Expected outcomes and success criteria
|
|
17
|
+
- Relationship with existing systems
|
|
18
|
+
|
|
19
|
+
Once requirements are moderately clarified:
|
|
20
|
+
- Invoke **requirement-analyzer** using Task tool
|
|
21
|
+
- `subagent_type: "requirement-analyzer"`
|
|
22
|
+
- `description: "Requirement analysis"`
|
|
23
|
+
- `prompt: "Requirements: [user requirements] Execute requirement analysis and scale determination"`
|
|
24
|
+
- **[STOP]**: Review requirement analysis results and address question items
|
|
25
|
+
|
|
26
|
+
### 2. Design Document Creation Phase
|
|
27
|
+
Create appropriate design documents according to scale determination:
|
|
28
|
+
- Invoke **technical-designer-frontend** using Task tool
|
|
29
|
+
- For ADR: `subagent_type: "technical-designer-frontend"`, `description: "ADR creation"`, `prompt: "Create ADR for [technical decision]"`
|
|
30
|
+
- For Design Doc: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc creation"`, `prompt: "Create Design Doc based on requirements"`
|
|
31
|
+
- Invoke **document-reviewer** to verify consistency
|
|
32
|
+
- `subagent_type: "document-reviewer"`, `description: "Document review"`, `prompt: "Review [document path] for consistency and completeness"`
|
|
33
|
+
- **[STOP]**: Present design alternatives and trade-offs, obtain user approval
|
|
34
|
+
|
|
35
|
+
**Scope**: Up to frontend design document (ADR/Design Doc) approval. Work planning and beyond are outside the scope of this command.
|
|
36
|
+
|
|
37
|
+
## Output Example
|
|
38
|
+
Frontend design phase completed.
|
|
39
|
+
- Design document: docs/design/[document-name].md or docs/adr/[document-name].md
|
|
40
|
+
- Approval status: User approved
|
|
41
|
+
|
|
42
|
+
**Important**: This command ends with design approval. Does not propose transition to next phase.
|
|
@@ -0,0 +1,40 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Create frontend work plan from design document and obtain plan approval
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
**Command Context**: This command is dedicated to the frontend planning phase.
|
|
6
|
+
|
|
7
|
+
Create frontend work plan with the following process:
|
|
8
|
+
|
|
9
|
+
## Execution Process
|
|
10
|
+
|
|
11
|
+
### 1. Design Document Selection
|
|
12
|
+
! ls -la docs/design/*.md | head -10
|
|
13
|
+
- Check for existence of design documents, notify user if none exist
|
|
14
|
+
- Present options if multiple exist (can be specified with $ARGUMENTS)
|
|
15
|
+
|
|
16
|
+
### 2. Work Plan Creation
|
|
17
|
+
Invoke **work-planner** using Task tool:
|
|
18
|
+
- `subagent_type: "work-planner"`
|
|
19
|
+
- `description: "Work plan creation"`
|
|
20
|
+
- `prompt: "Create work plan from Design Doc at [path]"`
|
|
21
|
+
- Interact with user to complete plan and obtain approval for plan content
|
|
22
|
+
|
|
23
|
+
**Think deeply** Create a work plan from the selected design document, clarifying specific implementation steps and risks.
|
|
24
|
+
|
|
25
|
+
**Scope**: Up to work plan creation and obtaining approval for plan content.
|
|
26
|
+
|
|
27
|
+
## Response at Completion
|
|
28
|
+
✅ **Recommended**: End with the following standard response after plan content approval
|
|
29
|
+
```
|
|
30
|
+
Frontend planning phase completed.
|
|
31
|
+
- Work plan: docs/plans/[plan-name].md
|
|
32
|
+
- Status: Approved
|
|
33
|
+
|
|
34
|
+
Please provide separate instructions for implementation.
|
|
35
|
+
```
|
|
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,75 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Orchestrate the complete implementation lifecycle from requirements to deployment
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
**Command Context**: Full-cycle implementation management (Requirements Analysis → Design → Planning → Implementation → Quality Assurance)
|
|
6
|
+
|
|
7
|
+
Strictly adhere to @docs/guides/sub-agents.md and operate as an orchestrator.
|
|
8
|
+
|
|
9
|
+
## Execution Decision Flow
|
|
10
|
+
|
|
11
|
+
### 1. Current Situation Assessment
|
|
12
|
+
Instruction Content: $ARGUMENTS
|
|
13
|
+
|
|
14
|
+
**Think deeply** Assess the current situation:
|
|
15
|
+
|
|
16
|
+
| Situation Pattern | Decision Criteria | Next Action |
|
|
17
|
+
|------------------|------------------|-------------|
|
|
18
|
+
| New Requirements | No existing work, new feature/fix request | Start with requirement-analyzer |
|
|
19
|
+
| Flow Continuation | Existing docs/tasks present, continuation directive | Identify next step in sub-agents.md flow |
|
|
20
|
+
| Quality Errors | Error detection, test failures, build errors | Execute quality-fixer |
|
|
21
|
+
| Ambiguous | Intent unclear, multiple interpretations possible | Confirm with user |
|
|
22
|
+
|
|
23
|
+
### 2. Progress Verification for Continuation
|
|
24
|
+
When continuing existing flow, verify:
|
|
25
|
+
- Latest artifacts (PRD/ADR/Design Doc/Work Plan/Tasks)
|
|
26
|
+
- Current phase position (Requirements/Design/Planning/Implementation/QA)
|
|
27
|
+
- Identify next step in sub-agents.md corresponding flow
|
|
28
|
+
|
|
29
|
+
### 3. After Scale Determination: Register All Flow Steps to TodoWrite (Required)
|
|
30
|
+
|
|
31
|
+
After scale determination, **register all steps of the applicable sub-agents.md flow to TodoWrite**. After registration, proceed through the flow referencing TodoWrite.
|
|
32
|
+
|
|
33
|
+
### 4. Execute Next Action
|
|
34
|
+
|
|
35
|
+
**Execute the next pending task in TodoWrite**.
|
|
36
|
+
|
|
37
|
+
## 📋 sub-agents.md Compliance Execution
|
|
38
|
+
|
|
39
|
+
**Pre-execution Checklist (Required)**:
|
|
40
|
+
- [ ] Confirmed relevant sub-agents.md flow
|
|
41
|
+
- [ ] Identified current progress position
|
|
42
|
+
- [ ] Clarified next step
|
|
43
|
+
- [ ] Recognized stopping points
|
|
44
|
+
- [ ] Understood the 4-step cycle after task execution (task-executor → escalation judgment/follow-up → quality-fixer → commit)
|
|
45
|
+
|
|
46
|
+
**Flow Adherence**: Follow "Autonomous Execution Task Management" in sub-agents.md, managing 4 steps with TodoWrite
|
|
47
|
+
|
|
48
|
+
## 🚨 Sub-agent Invocation Constraints
|
|
49
|
+
|
|
50
|
+
Include the following at the end of prompts when invoking sub-agents, as rule-advisor invocation from sub-agents causes system crash:
|
|
51
|
+
```
|
|
52
|
+
[Constraint] rule-advisor can only be used by Main AI
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
## 🎯 Mandatory Orchestrator Responsibilities
|
|
56
|
+
|
|
57
|
+
### Task Execution Flow
|
|
58
|
+
Following "Autonomous Execution Task Management" in sub-agents.md, manage these 4 steps with TodoWrite:
|
|
59
|
+
1. task-executor execution
|
|
60
|
+
2. Escalation judgment and follow-up
|
|
61
|
+
3. quality-fixer execution
|
|
62
|
+
4. git commit
|
|
63
|
+
|
|
64
|
+
### Test Information Communication
|
|
65
|
+
After acceptance-test-generator execution, when calling work-planner, communicate:
|
|
66
|
+
- Generated integration test file path
|
|
67
|
+
- Generated E2E test file path
|
|
68
|
+
- Explicit note that integration tests run with implementation, E2E tests run after all implementations
|
|
69
|
+
|
|
70
|
+
## Responsibility Boundaries
|
|
71
|
+
|
|
72
|
+
**This Command's Responsibility**: Orchestrate sub-agents through the complete implementation lifecycle
|
|
73
|
+
**OUT OF SCOPE**:
|
|
74
|
+
- Direct implementation work (MUST delegate to task-executor)
|
|
75
|
+
- Investigation tasks using Grep/Glob/Read (MUST delegate to subagents)
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Create work plan from design document and obtain plan approval
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
**Command Context**: This command is dedicated to the planning phase.
|
|
6
|
+
|
|
7
|
+
Follow @docs/guides/sub-agents.md strictly and create work plan with the following process:
|
|
8
|
+
|
|
9
|
+
## Execution Process
|
|
10
|
+
|
|
11
|
+
1. **Design Document Selection**
|
|
12
|
+
! ls -la docs/design/*.md | head -10
|
|
13
|
+
- Check for existence of design documents, notify user if none exist
|
|
14
|
+
- Present options if multiple exist (can be specified with $ARGUMENTS)
|
|
15
|
+
|
|
16
|
+
2. **E2E Test Skeleton Generation Confirmation**
|
|
17
|
+
- Confirm with user whether to generate E2E test skeleton first
|
|
18
|
+
- If user wants generation: Generate test skeleton with acceptance-test-generator
|
|
19
|
+
- Pass generation results to next process according to sub-agents.md coordination specification
|
|
20
|
+
|
|
21
|
+
3. **Work Plan Creation**
|
|
22
|
+
- Create work plan with work-planner
|
|
23
|
+
- Utilize deliverables from previous process according to sub-agents.md coordination specification
|
|
24
|
+
- Interact with user to complete plan and obtain approval for plan content
|
|
25
|
+
|
|
26
|
+
**Think deeply** Create a work plan from the selected design document, clarifying specific implementation steps and risks.
|
|
27
|
+
|
|
28
|
+
**Scope Boundary**:
|
|
29
|
+
- IN SCOPE: Work plan creation and obtaining approval for plan content
|
|
30
|
+
- OUT OF SCOPE: Task decomposition, implementation start
|
|
31
|
+
|
|
32
|
+
## Response at Completion
|
|
33
|
+
✅ **REQUIRED**: End with the following standard response after plan content approval
|
|
34
|
+
```
|
|
35
|
+
Planning phase completed.
|
|
36
|
+
- Work plan: docs/plans/[plan-name].md
|
|
37
|
+
- Status: Approved
|
|
38
|
+
|
|
39
|
+
Please provide separate instructions for implementation.
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
❌ **Avoid**: Additional processing after plan approval (task decomposition, implementation start, etc.)
|
|
43
|
+
- Reason: Exceeds the scope of the planning phase
|
|
44
|
+
|
|
45
|
+
**Responsibility Boundary**: This command completes with plan content approval. Implementation phase is out of scope. Wait for user instructions after plan approval.
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Inject project-specific context into project-context.md
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
**Command Context**: When using the boilerplate, collect project-specific context and update project-context.md.
|
|
6
|
+
|
|
7
|
+
## Execution Process
|
|
8
|
+
|
|
9
|
+
### 1. Current State Verification
|
|
10
|
+
! ls -la docs/rules/project-context.md
|
|
11
|
+
! cat package.json | grep -E '"name":|"description":'
|
|
12
|
+
|
|
13
|
+
### 2. Project Context Collection
|
|
14
|
+
|
|
15
|
+
Interact with the user to collect the following information:
|
|
16
|
+
|
|
17
|
+
```
|
|
18
|
+
【Core Project Information】
|
|
19
|
+
1. What problem does your project solve?
|
|
20
|
+
Examples: "Manual time tracking is inefficient" "Inventory management is person-dependent"
|
|
21
|
+
|
|
22
|
+
2. Who is the system for?
|
|
23
|
+
Examples: "50-member sales team" "E-commerce site operators"
|
|
24
|
+
|
|
25
|
+
3. In what situations will it be used?
|
|
26
|
+
Examples: "Field staff entering daily reports" "Month-end aggregation tasks"
|
|
27
|
+
|
|
28
|
+
【Development Structure】
|
|
29
|
+
- Individual development / Team development (number of members)
|
|
30
|
+
- Development phase (Prototype / Production development / In operation)
|
|
31
|
+
|
|
32
|
+
【Critical Business Constraints】(Maximum 3)
|
|
33
|
+
Examples: "7-year audit log retention" "Mandatory approval workflow" "Real-time synchronization"
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
**Think deeply** From the collected information, understand the project's essence and construct context focused on single responsibility.
|
|
37
|
+
|
|
38
|
+
### 3. Generate project-context.md
|
|
39
|
+
|
|
40
|
+
## AI Execution Accuracy Maximization Criteria
|
|
41
|
+
|
|
42
|
+
Generated project-context.md must follow these criteria:
|
|
43
|
+
|
|
44
|
+
### Principles of Description
|
|
45
|
+
1. **Minimal yet maximally efficient**: Essential information only, eliminate redundancy
|
|
46
|
+
2. **AI-decidable**: Use only measurable and verifiable criteria ("quickly" → "within 5 seconds")
|
|
47
|
+
3. **Eliminate ambiguity**: Include specific numbers, conditions, and examples
|
|
48
|
+
4. **Preferred format**: Describe in "do this" form rather than "don't do that"
|
|
49
|
+
|
|
50
|
+
### Responsibility Boundaries
|
|
51
|
+
project-context.md's single responsibility is "project-specific contextual information" only:
|
|
52
|
+
- ✅ Include: Project objectives, target users, business constraints
|
|
53
|
+
- ❌ Exclude: Tech stack (→technical-spec.md), implementation principles (→typescript.md), architecture (→technical-spec.md)
|
|
54
|
+
|
|
55
|
+
### Structure
|
|
56
|
+
```markdown
|
|
57
|
+
# Project Context
|
|
58
|
+
|
|
59
|
+
## Project Overview
|
|
60
|
+
- **Problem being solved**: [Specific challenge]
|
|
61
|
+
- **Target users**: [Include number and attributes]
|
|
62
|
+
- **Usage scenarios**: [Specific situations]
|
|
63
|
+
|
|
64
|
+
## Development Structure
|
|
65
|
+
- **Team composition**: [Number and roles]
|
|
66
|
+
- **Development phase**: [Current stage]
|
|
67
|
+
|
|
68
|
+
## Business Constraints
|
|
69
|
+
1. [Measurable constraint]
|
|
70
|
+
2. [Verifiable requirement]
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
### 4. Update rules-index.yaml
|
|
74
|
+
Update the typical-use in the project-context section to match the project.
|
|
75
|
+
|
|
76
|
+
**Scope**: Update project-context.md only. Technology choices are the responsibility of other rule files.
|