create-ai-project 1.14.6 → 1.14.7
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/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/plan.md +25 -9
- package/.claude/commands-en/review.md +12 -2
- 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/plan.md +25 -7
- package/.claude/commands-ja/review.md +13 -2
- package/package.json +1 -1
|
@@ -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.
|
|
@@ -4,6 +4,29 @@ description: Create work plan from design document and obtain plan approval
|
|
|
4
4
|
|
|
5
5
|
**Command Context**: This command is dedicated to the planning phase.
|
|
6
6
|
|
|
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 create plans yourself)
|
|
13
|
+
2. **Follow subagents-orchestration-guide skill planning flow exactly**:
|
|
14
|
+
- Execute steps defined below
|
|
15
|
+
- **Stop and obtain approval** for plan content before completion
|
|
16
|
+
3. **Scope**: Complete when work plan receives approval
|
|
17
|
+
|
|
18
|
+
**CRITICAL**: NEVER skip acceptance-test-generator when user requests test generation.
|
|
19
|
+
|
|
20
|
+
## Scope Boundaries
|
|
21
|
+
|
|
22
|
+
**Included in this command**:
|
|
23
|
+
- Design document selection
|
|
24
|
+
- E2E test skeleton generation (optional, with user confirmation)
|
|
25
|
+
- Work plan creation with work-planner
|
|
26
|
+
- Plan approval obtainment
|
|
27
|
+
|
|
28
|
+
**Responsibility Boundary**: This command completes with work plan approval.
|
|
29
|
+
|
|
7
30
|
Follow subagents-orchestration-guide skill strictly and create work plan with the following process:
|
|
8
31
|
|
|
9
32
|
## Execution Process
|
|
@@ -25,9 +48,7 @@ Follow subagents-orchestration-guide skill strictly and create work plan with th
|
|
|
25
48
|
|
|
26
49
|
**Think deeply** Create a work plan from the selected design document, clarifying specific implementation steps and risks.
|
|
27
50
|
|
|
28
|
-
**Scope
|
|
29
|
-
- IN SCOPE: Work plan creation and obtaining approval for plan content
|
|
30
|
-
- OUT OF SCOPE: Task decomposition, implementation start
|
|
51
|
+
**Scope**: Up to work plan creation and obtaining approval for plan content.
|
|
31
52
|
|
|
32
53
|
## Response at Completion
|
|
33
54
|
✅ **REQUIRED**: End with the following standard response after plan content approval
|
|
@@ -37,9 +58,4 @@ Planning phase completed.
|
|
|
37
58
|
- Status: Approved
|
|
38
59
|
|
|
39
60
|
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.
|
|
61
|
+
```
|
|
@@ -4,6 +4,16 @@ description: Design Doc compliance validation with optional auto-fixes
|
|
|
4
4
|
|
|
5
5
|
**Command Context**: Post-implementation quality assurance command
|
|
6
6
|
|
|
7
|
+
## Execution Method
|
|
8
|
+
|
|
9
|
+
- Compliance validation → performed by code-reviewer
|
|
10
|
+
- Rule analysis → performed by rule-advisor
|
|
11
|
+
- Fix implementation → performed by task-executor
|
|
12
|
+
- Quality checks → performed by quality-fixer
|
|
13
|
+
- Re-validation → performed by code-reviewer
|
|
14
|
+
|
|
15
|
+
Orchestrator invokes sub-agents and passes structured JSON between them.
|
|
16
|
+
|
|
7
17
|
Design Doc (uses most recent if omitted): $ARGUMENTS
|
|
8
18
|
|
|
9
19
|
**Think deeply** Understand the essence of compliance validation and execute:
|
|
@@ -45,11 +55,11 @@ Execute fixes? (y/n):
|
|
|
45
55
|
|
|
46
56
|
If user selects `y`:
|
|
47
57
|
|
|
48
|
-
##
|
|
58
|
+
## Pre-fix Metacognition
|
|
49
59
|
**Required**: `rule-advisor → TodoWrite → task-executor → quality-fixer`
|
|
50
60
|
|
|
51
61
|
1. **Execute rule-advisor**: Understand fix essence (symptomatic treatment vs root solution)
|
|
52
|
-
2. **Update TodoWrite**: Structure fix tasks → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
|
|
62
|
+
2. **Update TodoWrite**: Register work steps. Always include: first "Confirm skill constraints", final "Verify skill fidelity". Structure fix tasks → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
|
|
53
63
|
3. **Execute task-executor**: Staged auto-fixes (stops at 5 files)
|
|
54
64
|
4. **Execute quality-fixer**: Confirm quality gate passage
|
|
55
65
|
5. **Re-validate**: Measure improvement with code-reviewer
|
|
@@ -4,7 +4,28 @@ description: 要件分析から設計書作成まで実行
|
|
|
4
4
|
|
|
5
5
|
**コマンドコンテキスト**: このコマンドは設計フェーズ専用です。
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
## オーケストレーター定義
|
|
8
|
+
|
|
9
|
+
**コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」(subagents-orchestration-guideスキル参照)
|
|
10
|
+
|
|
11
|
+
**実行プロトコル**:
|
|
12
|
+
1. **全作業をサブエージェントに委譲**(自分で調査・分析しない)
|
|
13
|
+
2. **subagents-orchestration-guideスキルの設計フローに厳密に従う**:
|
|
14
|
+
- 実行: requirement-analyzer → technical-designer → document-reviewer → design-sync
|
|
15
|
+
- **`[停止: ...]`マーカーで必ず停止** → 次に進む前にユーザー承認を待つ
|
|
16
|
+
3. **スコープ**: 設計書が承認されたら完了
|
|
17
|
+
|
|
18
|
+
**重要**: document-reviewer、design-sync、subagents-orchestration-guideスキルで定義された停止ポイントは必ず実行する。
|
|
19
|
+
|
|
20
|
+
## ワークフロー概要
|
|
21
|
+
|
|
22
|
+
```
|
|
23
|
+
要件 → requirement-analyzer → [停止: 規模判定]
|
|
24
|
+
↓
|
|
25
|
+
technical-designer → document-reviewer
|
|
26
|
+
↓
|
|
27
|
+
design-sync → [停止: 設計承認]
|
|
28
|
+
```
|
|
8
29
|
|
|
9
30
|
要件: $ARGUMENTS
|
|
10
31
|
|
|
@@ -17,7 +38,16 @@ subagents-orchestration-guideスキルの設計フローに従い、**requiremen
|
|
|
17
38
|
|
|
18
39
|
設計の代替案とトレードオフを明確に提示します。
|
|
19
40
|
|
|
20
|
-
|
|
41
|
+
## スコープ境界
|
|
42
|
+
|
|
43
|
+
**実行内容**:
|
|
44
|
+
- requirement-analyzerによる要件分析
|
|
45
|
+
- ADR作成(アーキテクチャ変更、データフロー変更がある場合)
|
|
46
|
+
- technical-designerによるDesign Doc作成
|
|
47
|
+
- document-reviewerによるドキュメントレビュー
|
|
48
|
+
- design-syncによるDesign Doc間整合性検証
|
|
49
|
+
|
|
50
|
+
**責務境界**: このコマンドは設計書承認で責務完了。
|
|
21
51
|
|
|
22
52
|
## 実行フロー
|
|
23
53
|
|
|
@@ -29,6 +59,14 @@ subagents-orchestration-guideスキルの設計フローに従い、**requiremen
|
|
|
29
59
|
- 矛盾あり → ユーザーに報告 → 修正指示待ち → technical-designer(update)で修正
|
|
30
60
|
- 矛盾なし → 終了
|
|
31
61
|
|
|
62
|
+
## 完了条件
|
|
63
|
+
|
|
64
|
+
- [ ] requirement-analyzerを実行し規模を判定した
|
|
65
|
+
- [ ] technical-designerで適切な設計書(ADRまたはDesign Doc)を作成した
|
|
66
|
+
- [ ] document-reviewerを実行しフィードバックに対応した
|
|
67
|
+
- [ ] design-syncで整合性検証を実行した
|
|
68
|
+
- [ ] ユーザーから設計書の承認を取得した
|
|
69
|
+
|
|
32
70
|
## 出力例
|
|
33
71
|
設計フェーズが完了しました。
|
|
34
72
|
- 設計書: docs/design/[ドキュメント名].md
|
|
@@ -6,10 +6,14 @@ description: 問題を調査し、検証を経て解決策を導出する
|
|
|
6
6
|
|
|
7
7
|
対象問題: $ARGUMENTS
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
|
|
10
10
|
|
|
11
|
-
**実行方法**:
|
|
12
|
-
-
|
|
11
|
+
**実行方法**:
|
|
12
|
+
- 調査 → investigator
|
|
13
|
+
- 検証 → verifier
|
|
14
|
+
- 解決策導出 → solver
|
|
15
|
+
|
|
16
|
+
オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
|
|
13
17
|
|
|
14
18
|
**TodoWrite登録**: 実行ステップをTodoWriteに登録し、計画的にタスクを進める
|
|
15
19
|
|
|
@@ -2,11 +2,23 @@
|
|
|
2
2
|
description: フロントエンド実装を自律実行モードで実行
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
## オーケストレーター定義
|
|
6
|
+
|
|
7
|
+
**コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」(subagents-orchestration-guideスキル参照)
|
|
8
|
+
|
|
9
|
+
**実行方法**:
|
|
10
|
+
- タスク分解 → task-decomposer
|
|
11
|
+
- フロントエンド実装 → task-executor-frontend
|
|
12
|
+
- 品質チェックと修正 → quality-fixer-frontend
|
|
13
|
+
- コミット → オーケストレーター(Bashツール)
|
|
14
|
+
|
|
15
|
+
オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
|
|
16
|
+
|
|
17
|
+
**重要**: 全てのコミット前にquality-fixer-frontendを実行。自律実行モード前にバッチ承認を取得。
|
|
6
18
|
|
|
7
19
|
作業計画: $ARGUMENTS
|
|
8
20
|
|
|
9
|
-
##
|
|
21
|
+
## 実行前提条件
|
|
10
22
|
|
|
11
23
|
### タスクファイル存在チェック
|
|
12
24
|
```bash
|
|
@@ -19,7 +31,7 @@ description: フロントエンド実装を自律実行モードで実行
|
|
|
19
31
|
|
|
20
32
|
### タスク生成判定フロー
|
|
21
33
|
|
|
22
|
-
**THINK DEEPLY AND SYSTEMATICALLY**:
|
|
34
|
+
**THINK DEEPLY AND SYSTEMATICALLY**: タスクファイルの存在状態を分析し、必要なアクションを決定:
|
|
23
35
|
|
|
24
36
|
| 状態 | 基準 | 次のアクション |
|
|
25
37
|
|------|------|--------------|
|
|
@@ -27,7 +39,7 @@ description: フロントエンド実装を自律実行モードで実行
|
|
|
27
39
|
| タスクなし+計画あり | 計画書は存在するがタスクファイルなし | ユーザー確認 → task-decomposer実行 |
|
|
28
40
|
| どちらもなし | 計画書もタスクファイルもなし | エラー: 前提条件未達成 |
|
|
29
41
|
|
|
30
|
-
##
|
|
42
|
+
## タスク分解フェーズ(条件付き)
|
|
31
43
|
|
|
32
44
|
タスクファイルが存在しない場合:
|
|
33
45
|
|
|
@@ -53,12 +65,11 @@ description: フロントエンド実装を自律実行モードで実行
|
|
|
53
65
|
! ls -la docs/plans/tasks/*.md | head -10
|
|
54
66
|
```
|
|
55
67
|
|
|
56
|
-
✅
|
|
57
|
-
❌ **禁止**: タスク生成なしで実装開始
|
|
68
|
+
✅ **フロー**: タスク生成 → 自律実行
|
|
58
69
|
|
|
59
|
-
##
|
|
70
|
+
## タスク実行サイクル(4ステップサイクル) - フロントエンド特化
|
|
60
71
|
|
|
61
|
-
**必須実行サイクル**: `task-executor-frontend → quality-fixer-frontend → commit`
|
|
72
|
+
**必須実行サイクル**: `task-executor-frontend → エスカレーションチェック → quality-fixer-frontend → commit`
|
|
62
73
|
|
|
63
74
|
### サブエージェント呼び出し方法
|
|
64
75
|
Taskツールを使用してサブエージェントを呼び出す:
|
|
@@ -73,21 +84,23 @@ Taskツールを使用してサブエージェントを呼び出す:
|
|
|
73
84
|
|
|
74
85
|
### 各タスクの実行フロー
|
|
75
86
|
|
|
76
|
-
|
|
87
|
+
各タスクで必須:
|
|
77
88
|
|
|
78
|
-
1. **
|
|
89
|
+
1. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」
|
|
90
|
+
2. **task-executor-frontend使用**: フロントエンド実装を実行
|
|
79
91
|
- 呼び出し例: `subagent_type: "task-executor-frontend"`, `description: "タスク実行"`, `prompt: "タスクファイル: docs/plans/tasks/[ファイル名].md 実装を実行"`
|
|
80
|
-
|
|
81
|
-
|
|
92
|
+
3. **エスカレーションチェック**: task-executor-frontendのステータス確認 → `status: "escalation_needed"` の場合 → 停止してユーザーにエスカレーション
|
|
93
|
+
4. **構造化レスポンス処理**: `readyForQualityCheck: true` 検出時 → 即座にquality-fixer-frontend実行
|
|
94
|
+
5. **quality-fixer-frontend使用**: 全品質チェック実行(Biome、TypeScriptビルド、テスト)
|
|
82
95
|
- 呼び出し例: `subagent_type: "quality-fixer-frontend"`, `description: "品質チェック"`, `prompt: "全てのフロントエンド品質チェックと修正を実行"`
|
|
83
|
-
|
|
96
|
+
6. **コミット実行**: `approved: true`確認後、即座にgit commitを実行
|
|
84
97
|
|
|
85
98
|
### 自律実行中の品質保証(詳細)
|
|
86
|
-
- task-executor-frontend実行 → quality-fixer-frontend実行 →
|
|
99
|
+
- task-executor-frontend実行 → エスカレーションチェック → quality-fixer-frontend実行 → **オーケストレーターがコミット実行**(Bashツール使用)
|
|
87
100
|
- quality-fixer-frontendの`approved: true`確認後、即座にgit commitを実行
|
|
88
|
-
- changeSummary
|
|
101
|
+
- `changeSummary`をコミットメッセージに使用
|
|
89
102
|
|
|
90
|
-
|
|
103
|
+
**重要**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。
|
|
91
104
|
|
|
92
105
|
! ls -la docs/plans/*.md | head -10
|
|
93
106
|
|
|
@@ -4,7 +4,22 @@ description: 要件分析からフロントエンド設計ドキュメント作
|
|
|
4
4
|
|
|
5
5
|
**コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用です。
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
|
|
8
|
+
|
|
9
|
+
**実行方法**:
|
|
10
|
+
- 要件分析 → requirement-analyzer
|
|
11
|
+
- 設計書作成 → technical-designer-frontend
|
|
12
|
+
- ドキュメントレビュー → document-reviewer
|
|
13
|
+
|
|
14
|
+
オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
|
|
15
|
+
|
|
16
|
+
**実行内容**:
|
|
17
|
+
- requirement-analyzerによる要件分析
|
|
18
|
+
- ADR作成(アーキテクチャ変更、データフロー変更がある場合)
|
|
19
|
+
- technical-designer-frontendによるDesign Doc作成
|
|
20
|
+
- document-reviewerによるドキュメントレビュー
|
|
21
|
+
|
|
22
|
+
**責務境界**: このコマンドは設計書承認で責務完了。
|
|
8
23
|
|
|
9
24
|
要件: $ARGUMENTS
|
|
10
25
|
|
|
@@ -4,6 +4,20 @@ description: 設計ドキュメントからフロントエンド作業計画書
|
|
|
4
4
|
|
|
5
5
|
**コマンドコンテキスト**: このコマンドはフロントエンド計画フェーズ専用です。
|
|
6
6
|
|
|
7
|
+
subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
|
|
8
|
+
|
|
9
|
+
**実行方法**:
|
|
10
|
+
- 作業計画書作成 → work-planner
|
|
11
|
+
|
|
12
|
+
オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
|
|
13
|
+
|
|
14
|
+
**実行内容**:
|
|
15
|
+
- 設計書の選択
|
|
16
|
+
- work-plannerによる作業計画書作成
|
|
17
|
+
- 計画承認の取得
|
|
18
|
+
|
|
19
|
+
**責務境界**: このコマンドは作業計画書承認で責務完了。
|
|
20
|
+
|
|
7
21
|
以下のプロセスでフロントエンド作業計画書を作成:
|
|
8
22
|
|
|
9
23
|
## 実行プロセス
|
|
@@ -33,8 +47,3 @@ Taskツールで **work-planner** を呼び出し:
|
|
|
33
47
|
|
|
34
48
|
実装は別途指示してください。
|
|
35
49
|
```
|
|
36
|
-
|
|
37
|
-
❌ **回避**: 計画承認後の追加処理(タスク分解、実装開始等)
|
|
38
|
-
- 理由: 計画フェーズの範囲を超える
|
|
39
|
-
|
|
40
|
-
**責任範囲**: このコマンドはフロントエンド計画フェーズを担当し、計画内容承認で責任完了。実装フェーズは責任範囲外のため品質保証できず、自動移行しません。
|
|
@@ -4,7 +4,30 @@ description: 設計書から作業計画書を作成し計画承認を取得
|
|
|
4
4
|
|
|
5
5
|
**コマンドコンテキスト**: このコマンドは計画フェーズ専用です。
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
## オーケストレーター定義
|
|
8
|
+
|
|
9
|
+
**コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」(subagents-orchestration-guideスキル参照)
|
|
10
|
+
|
|
11
|
+
**実行プロトコル**:
|
|
12
|
+
1. **全作業をサブエージェントに委譲**(自分で計画を作成しない)
|
|
13
|
+
2. **subagents-orchestration-guideスキルの計画フローに厳密に従う**:
|
|
14
|
+
- 以下のステップを実行
|
|
15
|
+
- **完了前に計画承認を取得**
|
|
16
|
+
3. **スコープ**: 作業計画書が承認されたら完了
|
|
17
|
+
|
|
18
|
+
**重要**: ユーザーがテスト生成を要求した場合、acceptance-test-generatorは必ず実行する。
|
|
19
|
+
|
|
20
|
+
## スコープ境界
|
|
21
|
+
|
|
22
|
+
**実行内容**:
|
|
23
|
+
- 設計書の選択
|
|
24
|
+
- acceptance-test-generatorによるテストスケルトン生成
|
|
25
|
+
- work-plannerによる作業計画書作成
|
|
26
|
+
- 計画承認の取得
|
|
27
|
+
|
|
28
|
+
**責務境界**: このコマンドは作業計画書承認で責務完了。
|
|
29
|
+
|
|
30
|
+
以下のプロセスで作業計画書を作成します:
|
|
8
31
|
|
|
9
32
|
## 実行プロセス
|
|
10
33
|
|
|
@@ -35,9 +58,4 @@ subagents-orchestration-guideスキルの指針に従い、以下のプロセス
|
|
|
35
58
|
- 状態: 承認済み
|
|
36
59
|
|
|
37
60
|
実装は別途ご指示ください。
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
❌ **避ける**: 計画承認後の追加処理(タスク分解、実装開始等)
|
|
41
|
-
- 理由: 計画フェーズの責務を超えるため
|
|
42
|
-
|
|
43
|
-
**責務境界**: 本コマンドは計画フェーズに責任を持ち、計画内容の承認で責務完了。実装フェーズは責務範囲外のため、計画承認後はユーザーからの指示を待機する。
|
|
61
|
+
```
|
|
@@ -4,6 +4,17 @@ description: Design Doc準拠検証と必要に応じた自動修正
|
|
|
4
4
|
|
|
5
5
|
**コマンドコンテキスト**: 実装完了後の品質保証専用コマンド
|
|
6
6
|
|
|
7
|
+
subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
|
|
8
|
+
|
|
9
|
+
**実行方法**:
|
|
10
|
+
- Design Doc準拠検証 → code-reviewer
|
|
11
|
+
- 修正の本質理解 → rule-advisor
|
|
12
|
+
- 実装修正 → task-executor
|
|
13
|
+
- 品質チェック → quality-fixer
|
|
14
|
+
- 再検証 → code-reviewer
|
|
15
|
+
|
|
16
|
+
オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
|
|
17
|
+
|
|
7
18
|
Design Doc(省略時は直近のもの): $ARGUMENTS
|
|
8
19
|
|
|
9
20
|
**Think deeply** 準拠検証の本質を理解し、以下のステップで実行:
|
|
@@ -45,11 +56,11 @@ Design Doc準拠率を検証:
|
|
|
45
56
|
|
|
46
57
|
ユーザーが `y` を選択した場合:
|
|
47
58
|
|
|
48
|
-
##
|
|
59
|
+
## 修正実行前のメタ認知
|
|
49
60
|
**必須**: `rule-advisor → TodoWrite → task-executor → quality-fixer`
|
|
50
61
|
|
|
51
62
|
1. **rule-advisor実行**: 修正の本質を理解(表面的な対症療法 vs 根本解決)
|
|
52
|
-
2. **TodoWrite更新**:
|
|
63
|
+
2. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。修正タスクを構造化 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
|
|
53
64
|
3. **task-executor実行**: 自動修正を段階的実行(5ファイル超過で停止)
|
|
54
65
|
4. **quality-fixer実行**: 品質ゲート通過を確認
|
|
55
66
|
5. **再検証**: code-reviewerで改善度を測定
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "create-ai-project",
|
|
3
|
-
"version": "1.14.
|
|
3
|
+
"version": "1.14.7",
|
|
4
4
|
"packageManager": "npm@10.8.2",
|
|
5
5
|
"description": "TypeScript boilerplate with skills and sub-agents for Claude Code. Prevents context exhaustion through role-based task splitting.",
|
|
6
6
|
"keywords": [
|