create-ai-project 1.14.10 → 1.14.12

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.
@@ -7,19 +7,22 @@ description: Add integration/E2E tests to existing backend codebase using Design
7
7
 
8
8
  **Scope**: Backend only (acceptance-test-generator supports backend only)
9
9
 
10
- ## Execution Method
10
+ ## Orchestrator Definition
11
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
12
+ **Core Identity**: "I am not a worker. I am an orchestrator."
17
13
 
18
- Orchestrator invokes sub-agents and passes structured JSON between them.
14
+ **First Action**: Register Steps 0-8 to TodoWrite before any execution.
19
15
 
20
- Design Doc path: $ARGUMENTS
16
+ **Why Delegate**: Orchestrator's context is shared across all steps. Direct implementation consumes context needed for review and quality check phases. Task files create context boundaries. Subagents work in isolated context.
17
+
18
+ **Execution Method**:
19
+ - Skeleton generation → delegate to acceptance-test-generator
20
+ - Task file creation → orchestrator creates directly (minimal context usage)
21
+ - Test implementation → delegate to task-executor
22
+ - Test review → delegate to integration-test-reviewer
23
+ - Quality checks → delegate to quality-fixer
21
24
 
22
- **Think deeply** Understand the essence of test addition and execute:
25
+ Design Doc path: $ARGUMENTS
23
26
 
24
27
  ## Prerequisites
25
28
  - Design Doc must exist (created manually or via reverse-engineer)
@@ -27,48 +30,100 @@ Design Doc path: $ARGUMENTS
27
30
 
28
31
  ## Execution Flow
29
32
 
30
- ### 1. Validate Design Doc
33
+ ### Step 0: Execute Skill
34
+
35
+ Execute Skill: documentation-criteria (for task file template in Step 3)
36
+
37
+ ### Step 1: Validate Design Doc
38
+
31
39
  ```bash
32
40
  # Verify Design Doc exists
33
41
  ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
34
42
  ```
35
43
 
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
44
+ ### Step 2: Skeleton Generation
45
+
46
+ Invoke acceptance-test-generator using Task tool:
47
+ - `subagent_type`: "acceptance-test-generator"
48
+ - `description`: "Generate test skeletons"
49
+ - `prompt`: "Generate test skeletons from Design Doc at [path from Step 1]"
50
+
51
+ **Expected output**: `generatedFiles` containing integration and e2e paths
52
+
53
+ ### Step 3: Create Task File [GATE]
54
+
55
+ Create task file at: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
56
+
57
+ **Template**:
58
+ ```markdown
59
+ ---
60
+ name: Implement integration tests for [feature name]
61
+ type: test-implementation
62
+ ---
63
+
64
+ ## Objective
65
+
66
+ Implement test cases defined in skeleton files.
67
+
68
+ ## Target Files
69
+
70
+ - Skeleton: [path from Step 2 generatedFiles]
71
+ - Design Doc: [path from Step 1]
72
+
73
+ ## Tasks
74
+
75
+ - [ ] Implement each test case in skeleton
76
+ - [ ] Verify all tests pass
77
+ - [ ] Ensure coverage meets requirements
78
+
79
+ ## Acceptance Criteria
80
+
81
+ - All skeleton test cases implemented
82
+ - All tests passing
83
+ - No quality issues
84
+ ```
85
+
86
+ **Output**: "Task file created at [path]. Ready for Step 4."
87
+
88
+ ### Step 4: Test Implementation
89
+
90
+ Invoke task-executor using Task tool:
91
+ - `subagent_type`: "task-executor"
92
+ - `description`: "Implement integration tests"
93
+ - `prompt`: "Task file: docs/plans/tasks/integration-tests-YYYYMMDD.md. Implement tests following the task file."
94
+
95
+ **Expected output**: `status`, `testsAdded`
96
+
97
+ ### Step 5: Test Review
98
+
99
+ Invoke integration-test-reviewer using Task tool:
100
+ - `subagent_type`: "integration-test-reviewer"
101
+ - `description`: "Review test quality"
102
+ - `prompt`: "Review test quality. Test files: [paths from Step 4 testsAdded]. Skeleton files: [paths from Step 2 generatedFiles]"
103
+
104
+ **Expected output**: `status` (approved/needs_revision), `requiredFixes`
105
+
106
+ ### Step 6: Apply Review Fixes
107
+
108
+ Check Step 5 result:
109
+ - `status: approved` → Mark complete, proceed to Step 7
110
+ - `status: needs_revision` → Invoke task-executor with requiredFixes, then return to Step 5
111
+
112
+ Invoke task-executor using Task tool:
113
+ - `subagent_type`: "task-executor"
114
+ - `description`: "Fix review findings"
115
+ - `prompt`: "Fix the following issues in test files: [requiredFixes from Step 5]"
116
+
117
+ ### Step 7: Quality Check
118
+
119
+ Invoke quality-fixer using Task tool:
120
+ - `subagent_type`: "quality-fixer"
121
+ - `description`: "Final quality assurance"
122
+ - `prompt`: "Final quality assurance for test files added in this workflow. Run all tests and verify coverage."
123
+
124
+ **Expected output**: `approved` (true/false)
125
+
126
+ ### Step 8: Commit
127
+
128
+ On `approved: true` from quality-fixer:
129
+ - Commit test files with appropriate message using Bash
@@ -19,7 +19,7 @@ Work plan: $ARGUMENTS
19
19
 
20
20
  ### Task Generation Decision Flow
21
21
 
22
- **Think deeply** Analyze task file existence state and determine the appropriate action:
22
+ Analyze task file existence state and determine the appropriate action:
23
23
 
24
24
  | State | Criteria | Next Action |
25
25
  |-------|----------|-------------|
@@ -40,12 +40,11 @@ Generate tasks from the work plan? (y/n):
40
40
  ```
41
41
 
42
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
- ```
43
+
44
+ Invoke task-decomposer using Task tool:
45
+ - `subagent_type`: "task-decomposer"
46
+ - `description`: "Decompose work plan into tasks"
47
+ - `prompt`: "Read work plan and decompose into atomic tasks. Input: docs/plans/[plan-name].md. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"
49
48
 
50
49
  ### 3. Verify Generation
51
50
  ```bash
@@ -29,7 +29,7 @@ Requirements → requirement-analyzer → [Stop: Scale determination]
29
29
 
30
30
  Requirements: $ARGUMENTS
31
31
 
32
- **Think harder** Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
32
+ Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
33
33
  - What problems do you want to solve?
34
34
  - Expected outcomes and success criteria
35
35
  - Relationship with existing systems
@@ -37,11 +37,10 @@ If the following are unclear, **ask with AskUserQuestion** before proceeding:
37
37
 
38
38
  ### 0.3 Problem Essence Understanding
39
39
 
40
- **Invoke rule-advisor via Task tool**:
41
- ```
42
- subagent_type: rule-advisor
43
- prompt: Identify the essence and required rules for this problem: [Problem reported by user]
44
- ```
40
+ Invoke rule-advisor using Task tool:
41
+ - `subagent_type`: "rule-advisor"
42
+ - `description`: "Identify problem essence"
43
+ - `prompt`: "Identify the essence and required rules for this problem: [Problem reported by user]"
45
44
 
46
45
  Confirm from rule-advisor output:
47
46
  - `taskAnalysis.mainFocus`: Primary focus of the problem
@@ -79,13 +78,10 @@ Register the following in TodoWrite and execute:
79
78
 
80
79
  ### Step 1: Investigation (investigator)
81
80
 
82
- **Task tool invocation**:
83
- ```
84
- subagent_type: investigator
85
- prompt: Comprehensively collect information related to the following phenomenon.
86
-
87
- Phenomenon: [Problem reported by user]
88
- ```
81
+ Invoke investigator using Task tool:
82
+ - `subagent_type`: "investigator"
83
+ - `description`: "Collect problem information"
84
+ - `prompt`: "Comprehensively collect information related to the following phenomenon. Phenomenon: [Problem reported by user]"
89
85
 
90
86
  **Expected output**: Evidence matrix, comparison analysis results, causal tracking results, list of unexplored areas, investigation limitations
91
87
 
@@ -115,13 +111,10 @@ Proceed to verifier once quality is satisfied.
115
111
 
116
112
  ### Step 3: Verification (verifier)
117
113
 
118
- **Task tool invocation**:
119
- ```
120
- subagent_type: verifier
121
- prompt: Verify the following investigation results.
122
-
123
- Investigation results: [Investigation JSON output]
124
- ```
114
+ Invoke verifier using Task tool:
115
+ - `subagent_type`: "verifier"
116
+ - `description`: "Verify investigation results"
117
+ - `prompt`: "Verify the following investigation results. Investigation results: [Investigation JSON output]"
125
118
 
126
119
  **Expected output**: Alternative hypotheses (at least 3), Devil's Advocate evaluation, final conclusion, confidence
127
120
 
@@ -132,15 +125,10 @@ Investigation results: [Investigation JSON output]
132
125
 
133
126
  ### Step 4: Solution Derivation (solver)
134
127
 
135
- **Task tool invocation**:
136
- ```
137
- subagent_type: solver
138
- prompt: Derive solutions based on the following verified conclusion.
139
-
140
- Causes: [verifier's conclusion.causes]
141
- Causes relationship: [causesRelationship: independent/dependent/exclusive]
142
- Confidence: [high/medium/low]
143
- ```
128
+ Invoke solver using Task tool:
129
+ - `subagent_type`: "solver"
130
+ - `description`: "Derive solutions"
131
+ - `prompt`: "Derive solutions based on the following verified conclusion. Causes: [verifier's conclusion.causes]. Causes relationship: [causesRelationship: independent/dependent/exclusive]. Confidence: [high/medium/low]"
144
132
 
145
133
  **Expected output**: Multiple solutions (at least 3), tradeoff analysis, recommendation and implementation steps, residual risks
146
134
 
@@ -31,7 +31,7 @@ Work plan: $ARGUMENTS
31
31
 
32
32
  ### Task Generation Decision Flow
33
33
 
34
- **Think deeply**: Analyze task file existence state and determine the appropriate action:
34
+ Analyze task file existence state and determine the appropriate action:
35
35
 
36
36
  | State | Criteria | Next Action |
37
37
  |-------|----------|-------------|
@@ -52,12 +52,11 @@ Generate tasks from the work plan? (y/n):
52
52
  ```
53
53
 
54
54
  ### 2. Task Decomposition (if approved)
55
- ```
56
- @task-decomposer Read work plan and decompose into atomic tasks:
57
- - Input: docs/plans/[plan-name].md
58
- - Output: Individual task files in docs/plans/tasks/
59
- - Granularity: 1 task = 1 commit = independently executable
60
- ```
55
+
56
+ Invoke task-decomposer using Task tool:
57
+ - `subagent_type`: "task-decomposer"
58
+ - `description`: "Decompose work plan into tasks"
59
+ - `prompt`: "Read work plan and decompose into atomic tasks. Input: docs/plans/[plan-name].md. Output: Individual task files in docs/plans/tasks/. Granularity: 1 task = 1 commit = independently executable"
61
60
 
62
61
  ### 3. Verify Generation
63
62
  ```bash
@@ -30,7 +30,7 @@ Requirements: $ARGUMENTS
30
30
  ## Execution Flow
31
31
 
32
32
  ### 1. Requirement Analysis Phase
33
- **Think harder**: Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
33
+ Considering the deep impact on design, first engage in dialogue to understand the background and purpose of requirements:
34
34
  - What problems do you want to solve?
35
35
  - Expected outcomes and success criteria
36
36
  - Relationship with existing systems
@@ -38,7 +38,7 @@ Invoke **work-planner** using Task tool:
38
38
  - `prompt: "Create work plan from Design Doc at [path]"`
39
39
  - Interact with user to complete plan and obtain approval for plan content
40
40
 
41
- **Think deeply** Create a work plan from the selected design document, clarifying specific implementation steps and risks.
41
+ Create a work plan from the selected design document, clarifying specific implementation steps and risks.
42
42
 
43
43
  **Scope**: Up to work plan creation and obtaining approval for plan content.
44
44
 
@@ -46,7 +46,7 @@ Follow subagents-orchestration-guide skill strictly and create work plan with th
46
46
  - Utilize deliverables from previous process according to subagents-orchestration-guide skill coordination specification
47
47
  - Interact with user to complete plan and obtain approval for plan content
48
48
 
49
- **Think deeply** Create a work plan from the selected design document, clarifying specific implementation steps and risks.
49
+ Create a work plan from the selected design document, clarifying specific implementation steps and risks.
50
50
 
51
51
  **Scope**: Up to work plan creation and obtaining approval for plan content.
52
52
 
@@ -7,7 +7,6 @@ description: Design Doc compliance validation with optional auto-fixes
7
7
  ## Execution Method
8
8
 
9
9
  - Compliance validation → performed by code-reviewer
10
- - Rule analysis → performed by rule-advisor
11
10
  - Fix implementation → performed by task-executor
12
11
  - Quality checks → performed by quality-fixer
13
12
  - Re-validation → performed by code-reviewer
@@ -16,7 +15,7 @@ Orchestrator invokes sub-agents and passes structured JSON between them.
16
15
 
17
16
  Design Doc (uses most recent if omitted): $ARGUMENTS
18
17
 
19
- **Think deeply** Understand the essence of compliance validation and execute:
18
+ Understand the essence of compliance validation and execute the following steps:
20
19
 
21
20
  ## Execution Flow
22
21
 
@@ -55,14 +54,13 @@ Execute fixes? (y/n):
55
54
 
56
55
  If user selects `y`:
57
56
 
58
- ## Pre-fix Metacognition
59
- **Required**: `rule-advisor → TodoWrite → task-executor → quality-fixer`
57
+ #### Fix Execution Steps
58
+ **Required**: `TodoWrite → task-executor → quality-fixer`
60
59
 
61
- 1. **Execute rule-advisor**: Understand fix essence (symptomatic treatment vs root solution)
62
- 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`
63
- 3. **Execute task-executor**: Staged auto-fixes (stops at 5 files)
64
- 4. **Execute quality-fixer**: Confirm quality gate passage
65
- 5. **Re-validate**: Measure improvement with code-reviewer
60
+ 1. **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`
61
+ 2. **Execute task-executor**: Staged auto-fixes (stops at 5 files)
62
+ 3. **Execute quality-fixer**: Confirm quality gate passage
63
+ 4. **Re-validate**: Measure improvement with code-reviewer
66
64
 
67
65
  ### 4. Final Report
68
66
  ```
@@ -85,4 +83,4 @@ Remaining issues:
85
83
  - Architecture-level modifications
86
84
  - Design Doc deficiencies
87
85
 
88
- **Scope**: Design Doc compliance validation and auto-fixes.
86
+ **Scope**: Design Doc compliance validation and auto-fixes.
@@ -7,19 +7,22 @@ description: Design Docを使用して既存バックエンドコードベース
7
7
 
8
8
  **スコープ**: バックエンドのみ(acceptance-test-generatorはバックエンドのみ対応)
9
9
 
10
- ## 実行方法
10
+ ## オーケストレーター定義
11
11
 
12
- - スケルトン生成 → acceptance-test-generatorが実行
13
- - タスクファイル作成 → タスクテンプレートに従う(documentation-criteriaスキル参照)
14
- - テスト実装 → task-executorが実行
15
- - テストレビュー → integration-test-reviewerが実行
16
- - 品質チェック → quality-fixerが実行
12
+ **コアアイデンティティ**: 「私は作業者ではない。オーケストレーターである。」
17
13
 
18
- オーケストレーターがサブエージェントを呼び出し、構造化JSONを受け渡す。
14
+ **初動アクション**: ステップ0-8をTodoWriteに登録してから実行を開始。
19
15
 
20
- Design Docパス: $ARGUMENTS
16
+ **委譲理由**: オーケストレーターとして、レビュー・品質チェックを含む全てのステップを完遂させるために、必要なコンテキストを維持する必要がある。タスクファイルをコンテキスト境界とし、全ての作業をサブエージェントが担うことでこれを実現する。
17
+
18
+ **実行方法**:
19
+ - スケルトン生成 → acceptance-test-generatorに委譲
20
+ - タスクファイル作成 → オーケストレーターが作成(テスト、設計書の最小限情報のみ)
21
+ - テスト実装 → task-executorに委譲
22
+ - テストレビュー → integration-test-reviewerに委譲
23
+ - 品質チェック → quality-fixerに委譲
21
24
 
22
- **Think deeply** テスト追加の本質を理解して実行:
25
+ Design Docパス: $ARGUMENTS
23
26
 
24
27
  ## 前提条件
25
28
  - Design Docが存在すること(手動またはreverse-engineerで作成)
@@ -27,48 +30,100 @@ Design Docパス: $ARGUMENTS
27
30
 
28
31
  ## 実行フロー
29
32
 
30
- ### 1. Design Doc検証
33
+ ### ステップ0: スキル実行
34
+
35
+ スキル実行: documentation-criteria(ステップ3のタスクファイルテンプレート用)
36
+
37
+ ### ステップ1: Design Doc検証
38
+
31
39
  ```bash
32
40
  # Design Docの存在確認
33
41
  ls $ARGUMENTS || ls docs/design/*.md | grep -v template | tail -1
34
42
  ```
35
43
 
36
- ### 2. acceptance-test-generator実行
37
- Design Docからテストスケルトンを生成:
38
- - 受入条件(AC)を抽出
39
- - 統合テストスケルトン生成(`*.int.test.ts`)
40
- - 該当する場合はE2Eテストスケルトン生成(`*.e2e.test.ts`)
41
-
42
- ### 3. タスクファイル作成
43
- タスクテンプレートに従ってタスクファイルを作成(documentation-criteriaスキル参照):
44
- - パス: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
45
- - 内容: 生成されたスケルトンに基づくテスト実装タスク
46
- - 対象ファイルセクションにスケルトンファイルパスを含める
47
-
48
- ### 4. task-executor実行
49
- タスクファイルに従ってテストを実装:
50
- - TDD原則に従う(Red-Green-Refactor)
51
- - 各スケルトンテストケースを実装
52
- - テストを実行してパスを確認
53
-
54
- ### 5. integration-test-reviewer実行
55
- テスト品質をレビュー:
56
- - スケルトン準拠を確認
57
- - テストカバレッジをチェック
58
- - `needs_revision`の場合 → `requiredFixes`と共にステップ4に戻る
59
- - `approved`の場合 → 品質チェックに進む
60
-
61
- ### 6. quality-fixer実行
62
- 最終品質保証:
63
- - 全テストを実行
64
- - カバレッジが要件を満たすことを確認
65
- - 品質問題を修正
66
-
67
- ### 7. コミット
68
- 適切なメッセージでテストファイルをコミット。
69
-
70
- ## 委譲先
71
- - acceptance-test-generator: スケルトン生成
72
- - task-executor: テスト実装
73
- - integration-test-reviewer: テスト品質レビュー
74
- - quality-fixer: 最終品質チェック
44
+ ### ステップ2: スケルトン生成
45
+
46
+ Taskツールでacceptance-test-generatorを呼び出す:
47
+ - `subagent_type`: "acceptance-test-generator"
48
+ - `description`: "テストスケルトン生成"
49
+ - `prompt`: "[ステップ1のパス]のDesign Docからテストスケルトンを生成"
50
+
51
+ **期待される出力**: `generatedFiles`(統合テストとE2Eのパスを含む)
52
+
53
+ ### ステップ3: タスクファイル作成 [GATE]
54
+
55
+ タスクファイル作成先: `docs/plans/tasks/integration-tests-YYYYMMDD.md`
56
+
57
+ **テンプレート**:
58
+ ```markdown
59
+ ---
60
+ name: [機能名]の統合テスト実装
61
+ type: test-implementation
62
+ ---
63
+
64
+ ## 目的
65
+
66
+ スケルトンファイルに定義されたテストケースを実装する。
67
+
68
+ ## 対象ファイル
69
+
70
+ - スケルトン: [ステップ2のgeneratedFilesのパス]
71
+ - Design Doc: [ステップ1のパス]
72
+
73
+ ## タスク
74
+
75
+ - [ ] スケルトンの各テストケースを実装
76
+ - [ ] 全テストがパスすることを確認
77
+ - [ ] カバレッジが要件を満たすことを確認
78
+
79
+ ## 受入条件
80
+
81
+ - 全スケルトンテストケースが実装済み
82
+ - 全テストがパス
83
+ - 品質チェック全項目パス
84
+ ```
85
+
86
+ **出力**: "タスクファイルを[パス]に作成しました。ステップ4へ進む準備完了。"
87
+
88
+ ### ステップ4: テスト実装
89
+
90
+ Taskツールでtask-executorを呼び出す:
91
+ - `subagent_type`: "task-executor"
92
+ - `description`: "統合テスト実装"
93
+ - `prompt`: "タスクファイル: docs/plans/tasks/integration-tests-YYYYMMDD.md。タスクファイルに従ってテストを実装。"
94
+
95
+ **期待される出力**: `status`, `testsAdded`
96
+
97
+ ### ステップ5: テストレビュー
98
+
99
+ Taskツールでintegration-test-reviewerを呼び出す:
100
+ - `subagent_type`: "integration-test-reviewer"
101
+ - `description`: "テスト品質レビュー"
102
+ - `prompt`: "テスト品質をレビュー。テストファイル: [ステップ4のtestsAdded]。スケルトンファイル: [ステップ2のgeneratedFiles]"
103
+
104
+ **期待される出力**: `status` (approved/needs_revision), `requiredFixes`
105
+
106
+ ### ステップ6: レビュー修正の適用
107
+
108
+ ステップ5の結果を確認:
109
+ - `status: approved` → 完了としてマーク、ステップ7へ進む
110
+ - `status: needs_revision` → requiredFixesでtask-executorを呼び出し、ステップ5に戻る
111
+
112
+ Taskツールでtask-executorを呼び出す:
113
+ - `subagent_type`: "task-executor"
114
+ - `description`: "レビュー指摘の修正"
115
+ - `prompt`: "テストファイルの以下の問題を修正: [ステップ5のrequiredFixes]"
116
+
117
+ ### ステップ7: 品質チェック
118
+
119
+ Taskツールでquality-fixerを呼び出す:
120
+ - `subagent_type`: "quality-fixer"
121
+ - `description`: "最終品質保証"
122
+ - `prompt`: "このワークフローで追加されたテストファイルの最終品質保証。全テストを実行しカバレッジを確認。"
123
+
124
+ **期待される出力**: `approved` (true/false)
125
+
126
+ ### ステップ8: コミット
127
+
128
+ quality-fixerから`approved: true`の場合:
129
+ - Bashで適切なメッセージを付けてテストファイルをコミット
@@ -19,7 +19,7 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
19
19
 
20
20
  ### タスク生成判定フロー
21
21
 
22
- **Think deeply** タスクファイルの存在状態を確認し、適切な対応を決定:
22
+ タスクファイルの存在状態を確認し、適切な対応を決定:
23
23
 
24
24
  | 状態 | 判定基準 | 次のアクション |
25
25
  |------|---------|--------------|
@@ -40,12 +40,11 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
40
40
  ```
41
41
 
42
42
  ### 2. タスク分解実行(承認時)
43
- ```
44
- @task-decomposer 作業計画書を読み込み、1コミット粒度の独立したタスクに分解:
45
- - 入力: docs/plans/[計画書名].md
46
- - 出力: docs/plans/tasks/配下に個別タスクファイル生成
47
- - 粒度: 1タスク = 1コミット = 独立して実行可能
48
- ```
43
+
44
+ Taskツールでtask-decomposerを呼び出す:
45
+ - `subagent_type`: "task-decomposer"
46
+ - `description`: "作業計画をタスクに分解"
47
+ - `prompt`: "作業計画書を読み込み、1コミット粒度の独立したタスクに分解。入力: docs/plans/[計画書名].md。出力: docs/plans/tasks/配下に個別タスクファイル生成。粒度: 1タスク = 1コミット = 独立して実行可能"
49
48
 
50
49
  ### 3. 生成確認
51
50
  ```bash
@@ -29,7 +29,7 @@ description: 要件分析から設計書作成まで実行
29
29
 
30
30
  要件: $ARGUMENTS
31
31
 
32
- **Think harder** 設計への影響を深く考慮し、まず要件の背景と目的を理解するため対話を行い:
32
+ 設計への影響を深く考慮し、まず要件の背景と目的を理解するため対話を行い:
33
33
  - どのような問題を解決したいか
34
34
  - 期待される成果と成功基準
35
35
  - 既存システムとの関係性
@@ -42,7 +42,7 @@ description: 要件分析から設計書作成まで実行
42
42
 
43
43
  **実行内容**:
44
44
  - requirement-analyzerによる要件分析
45
- - ADR作成(アーキテクチャ変更、データフロー変更がある場合)
45
+ - ADR作成(アーキテクチャ変更、新技術、データフロー変更がある場合)
46
46
  - technical-designerによるDesign Doc作成
47
47
  - document-reviewerによるドキュメントレビュー
48
48
  - design-syncによるDesign Doc間整合性検証
@@ -54,7 +54,7 @@ description: 要件分析から設計書作成まで実行
54
54
  1. requirement-analyzer → 要件分析
55
55
  2. technical-designer → Design Doc作成
56
56
  3. document-reviewer → 単一ドキュメント品質チェック
57
- 4. ユーザー承認
57
+ 4. ユーザー承認(承認を待つ)
58
58
  5. design-sync → Design Doc間整合性検証
59
59
  - 矛盾あり → ユーザーに報告 → 修正指示待ち → technical-designer(update)で修正
60
60
  - 矛盾なし → 終了
@@ -72,4 +72,4 @@ description: 要件分析から設計書作成まで実行
72
72
  - 設計書: docs/design/[ドキュメント名].md
73
73
  - 整合性: 他Design Docと矛盾なし(または修正完了)
74
74
 
75
- **重要**: 本コマンドは設計承認+整合性確認で終了。次フェーズへの移行提案は行わない。
75
+ **重要**: 本コマンドは設計承認+整合性確認で終了。次フェーズへの移行提案は行わない。
@@ -6,14 +6,14 @@ description: 問題を調査し、検証を経て解決策を導出する
6
6
 
7
7
  対象問題: $ARGUMENTS
8
8
 
9
- subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
9
+ **Role**: オーケストレーター
10
10
 
11
11
  **実行方法**:
12
- - 調査 → investigator
13
- - 検証 → verifier
14
- - 解決策導出 → solver
12
+ - 調査 → investigatorに委譲
13
+ - 検証 → verifierに委譲
14
+ - 解決策導出 → solverに委譲
15
15
 
16
- オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
16
+ オーケストレーターがサブエージェントを呼び出し、構造化JSONを受け渡します。
17
17
 
18
18
  **TodoWrite登録**: 実行ステップをTodoWriteに登録し、計画的にタスクを進める
19
19
 
@@ -37,11 +37,10 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
37
37
 
38
38
  ### 0.3 問題の本質理解
39
39
 
40
- **Taskツールでrule-advisorを呼び出す**:
41
- ```
42
- subagent_type: rule-advisor
43
- prompt: 以下の問題について、本質と必要なルールを特定してください: [ユーザーが報告した問題]
44
- ```
40
+ Taskツールでrule-advisorを呼び出す:
41
+ - `subagent_type`: "rule-advisor"
42
+ - `description`: "問題の本質特定"
43
+ - `prompt`: "以下の問題について、本質と必要なルールを特定してください: [ユーザーが報告した問題]"
45
44
 
46
45
  rule-advisorの出力から以下を確認:
47
46
  - `taskAnalysis.mainFocus`: 問題の主要な焦点
@@ -79,13 +78,10 @@ rule-advisorの出力から以下を確認:
79
78
 
80
79
  ### ステップ1: 調査(investigator)
81
80
 
82
- **Taskツールでの呼び出し**:
83
- ```
84
- subagent_type: investigator
85
- prompt: 以下の現象について、関連する情報を網羅的に収集してください。
86
-
87
- 現象: [ユーザーが報告した問題]
88
- ```
81
+ Taskツールでinvestigatorを呼び出す:
82
+ - `subagent_type`: "investigator"
83
+ - `description`: "問題情報の収集"
84
+ - `prompt`: "以下の現象について、関連する情報を網羅的に収集してください。現象: [ユーザーが報告した問題]"
89
85
 
90
86
  **期待される出力**: 証拠マトリクス、比較分析結果、因果追跡結果、未探索領域のリスト、調査の限界
91
87
 
@@ -115,13 +111,10 @@ investigatorの出力で`causeCategory: design_gap`または`recurrenceRisk: hig
115
111
 
116
112
  ### ステップ3: 検証(verifier)
117
113
 
118
- **Taskツールでの呼び出し**:
119
- ```
120
- subagent_type: verifier
121
- prompt: 以下の調査結果を検証してください。
122
-
123
- 調査結果: [調査のJSON出力]
124
- ```
114
+ Taskツールでverifierを呼び出す:
115
+ - `subagent_type`: "verifier"
116
+ - `description`: "調査結果の検証"
117
+ - `prompt`: "以下の調査結果を検証してください。調査結果: [調査のJSON出力]"
125
118
 
126
119
  **期待される出力**: 代替仮説(最低3つ)、Devil's Advocate評価、最終結論、信頼度
127
120
 
@@ -132,15 +125,10 @@ prompt: 以下の調査結果を検証してください。
132
125
 
133
126
  ### ステップ4: 解決策導出(solver)
134
127
 
135
- **Taskツールでの呼び出し**:
136
- ```
137
- subagent_type: solver
138
- prompt: 以下の検証済み結論に基づいて、解決策を導出してください。
139
-
140
- 原因: [verifierのconclusion.causes]
141
- 原因の関係性: [causesRelationship: independent/dependent/exclusive]
142
- 信頼度: [high/medium/low]
143
- ```
128
+ Taskツールでsolverを呼び出す:
129
+ - `subagent_type`: "solver"
130
+ - `description`: "解決策の導出"
131
+ - `prompt`: "以下の検証済み結論に基づいて、解決策を導出してください。原因: [verifierのconclusion.causes]。原因の関係性: [causesRelationship: independent/dependent/exclusive]。信頼度: [high/medium/low]"
144
132
 
145
133
  **期待される出力**: 複数の解決策(最低3つ)、トレードオフ分析、推奨案と実装ステップ、残存リスク
146
134
 
@@ -31,7 +31,7 @@ description: フロントエンド実装を自律実行モードで実行
31
31
 
32
32
  ### タスク生成判定フロー
33
33
 
34
- **THINK DEEPLY AND SYSTEMATICALLY**: タスクファイルの存在状態を分析し、必要なアクションを決定:
34
+ タスクファイルの存在状態を分析し、必要なアクションを決定:
35
35
 
36
36
  | 状態 | 基準 | 次のアクション |
37
37
  |------|------|--------------|
@@ -52,12 +52,11 @@ description: フロントエンド実装を自律実行モードで実行
52
52
  ```
53
53
 
54
54
  ### 2. タスク分解(承認された場合)
55
- ```
56
- @task-decomposer 作業計画を読み込み、アトミックなタスクに分解:
57
- - 入力: docs/plans/[plan-name].md
58
- - 出力: docs/plans/tasks/ 配下の個別タスクファイル
59
- - 粒度: 1タスク = 1コミット = 独立実行可能
60
- ```
55
+
56
+ Taskツールでtask-decomposerを呼び出す:
57
+ - `subagent_type`: "task-decomposer"
58
+ - `description`: "作業計画をタスクに分解"
59
+ - `prompt`: "作業計画を読み込み、アトミックなタスクに分解。入力: docs/plans/[plan-name].md。出力: docs/plans/tasks/配下に個別タスクファイル。粒度: 1タスク = 1コミット = 独立実行可能"
61
60
 
62
61
  ### 3. 生成確認
63
62
  ```bash
@@ -4,18 +4,22 @@ description: 要件分析からフロントエンド設計ドキュメント作
4
4
 
5
5
  **コマンドコンテキスト**: このコマンドはフロントエンド設計フェーズ専用です。
6
6
 
7
- subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
7
+ ## オーケストレーター定義
8
+
9
+ **Role**: オーケストレーター
8
10
 
9
11
  **実行方法**:
10
- - 要件分析 → requirement-analyzer
11
- - 設計書作成 → technical-designer-frontend
12
- - ドキュメントレビュー → document-reviewer
12
+ - 要件分析 → requirement-analyzerが実行
13
+ - 設計書作成 → technical-designer-frontendが実行
14
+ - ドキュメントレビュー → document-reviewerが実行
13
15
 
14
16
  オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
15
17
 
18
+ ## スコープ境界
19
+
16
20
  **実行内容**:
17
21
  - requirement-analyzerによる要件分析
18
- - ADR作成(アーキテクチャ変更、データフロー変更がある場合)
22
+ - ADR作成(アーキテクチャ変更、新技術、データフロー変更がある場合)
19
23
  - technical-designer-frontendによるDesign Doc作成
20
24
  - document-reviewerによるドキュメントレビュー
21
25
 
@@ -26,24 +30,24 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
26
30
  ## 実行フロー
27
31
 
28
32
  ### 1. 要件分析フェーズ
29
- **Think harder**: 設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解:
33
+ 設計への影響が深いことを考慮し、まず対話により要件の背景と目的を理解:
30
34
  - 何の問題を解決したいか
31
35
  - 期待する成果と成功基準
32
36
  - 既存システムとの関係
33
37
 
34
- 要件がある程度明確になったら:
35
- - Taskツールで **requirement-analyzer** を呼び出し
38
+ 要件がある程度明確になったら:
39
+ - Taskツールで**requirement-analyzer**を呼び出す
36
40
  - `subagent_type: "requirement-analyzer"`
37
41
  - `description: "要件分析"`
38
42
  - `prompt: "要件: [ユーザー要件] 要件分析と規模判定を実施してください"`
39
43
  - **[停止]**: 要件分析結果を確認し、質問事項に対応
40
44
 
41
45
  ### 2. 設計ドキュメント作成フェーズ
42
- 規模判定に応じて適切な設計ドキュメントを作成:
43
- - Taskツールで **technical-designer-frontend** を呼び出し
46
+ 規模判定に応じて適切な設計ドキュメントを作成:
47
+ - Taskツールで**technical-designer-frontend**を呼び出す
44
48
  - ADRの場合: `subagent_type: "technical-designer-frontend"`, `description: "ADR作成"`, `prompt: "[技術決定]のADRを作成"`
45
49
  - Design Docの場合: `subagent_type: "technical-designer-frontend"`, `description: "Design Doc作成"`, `prompt: "要件に基づいてDesign Docを作成"`
46
- - Taskツールで **document-reviewer** を呼び出して整合性検証
50
+ - Taskツールで**document-reviewer**を呼び出して整合性検証
47
51
  - `subagent_type: "document-reviewer"`, `description: "ドキュメントレビュー"`, `prompt: "[ドキュメントパス]の整合性と完成度をレビュー"`
48
52
  - **[停止]**: 設計の選択肢とトレードオフを提示し、ユーザー承認を取得
49
53
 
@@ -4,13 +4,17 @@ description: 設計ドキュメントからフロントエンド作業計画書
4
4
 
5
5
  **コマンドコンテキスト**: このコマンドはフロントエンド計画フェーズ専用です。
6
6
 
7
- subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
7
+ ## オーケストレーター定義
8
+
9
+ **Role**: オーケストレーター
8
10
 
9
11
  **実行方法**:
10
- - 作業計画書作成 → work-planner
12
+ - 作業計画書作成 → work-plannerが実行
11
13
 
12
14
  オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
13
15
 
16
+ ## スコープ境界
17
+
14
18
  **実行内容**:
15
19
  - 設計書の選択
16
20
  - work-plannerによる作業計画書作成
@@ -18,7 +22,7 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
18
22
 
19
23
  **責務境界**: このコマンドは作業計画書承認で責務完了。
20
24
 
21
- 以下のプロセスでフロントエンド作業計画書を作成:
25
+ 以下のプロセスでフロントエンド作業計画書を作成:
22
26
 
23
27
  ## 実行プロセス
24
28
 
@@ -28,13 +32,13 @@ subagents-orchestration-guideスキルの指針に従い、**オーケストレ
28
32
  - 複数ある場合は選択肢を提示($ARGUMENTSで指定可能)
29
33
 
30
34
  ### 2. 作業計画書作成
31
- Taskツールで **work-planner** を呼び出し:
35
+ Taskツールで**work-planner**を呼び出す:
32
36
  - `subagent_type: "work-planner"`
33
37
  - `description: "作業計画書作成"`
34
38
  - `prompt: "[パス]のDesign Docから作業計画を作成"`
35
39
  - ユーザーと対話して計画を完成させ、計画内容の承認を得る
36
40
 
37
- **深く考える** 選択された設計ドキュメントから作業計画を作成し、具体的な実装ステップとリスクを明確化。
41
+ 選択された設計ドキュメントから作業計画を作成し、具体的な実装ステップとリスクを明確化。
38
42
 
39
43
  **スコープ**: 作業計画書作成と計画内容の承認取得まで。
40
44
 
@@ -21,13 +21,13 @@ description: 設計書から作業計画書を作成し計画承認を取得
21
21
 
22
22
  **実行内容**:
23
23
  - 設計書の選択
24
- - acceptance-test-generatorによるテストスケルトン生成
24
+ - E2Eテストスケルトン生成(オプション、ユーザー確認後)
25
25
  - work-plannerによる作業計画書作成
26
26
  - 計画承認の取得
27
27
 
28
28
  **責務境界**: このコマンドは作業計画書承認で責務完了。
29
29
 
30
- 以下のプロセスで作業計画書を作成します:
30
+ 以下のプロセスで作業計画書を作成:
31
31
 
32
32
  ## 実行プロセス
33
33
 
@@ -46,16 +46,16 @@ description: 設計書から作業計画書を作成し計画承認を取得
46
46
  - 前工程の成果物を subagents-orchestration-guideスキル の連携仕様に従って活用
47
47
  - ユーザーと対話して計画を完成させ、計画内容の承認を得る
48
48
 
49
- **Think deeply** 選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
49
+ 選択された設計書から作業計画書を作成し、実装の具体的なステップとリスクを明確にします。
50
50
 
51
51
  **スコープ**: 作業計画書作成と計画内容の承認取得まで。
52
52
 
53
53
  ## 終了時の応答
54
- **推奨**: 計画内容の承認後は以下の定型応答で終了
54
+ **必須**: 計画内容の承認後は以下の定型応答で終了
55
55
  ```
56
56
  計画フェーズが完了しました。
57
57
  - 作業計画書: docs/plans/[計画書名].md
58
58
  - 状態: 承認済み
59
59
 
60
60
  実装は別途ご指示ください。
61
- ```
61
+ ```
@@ -4,20 +4,18 @@ description: Design Doc準拠検証と必要に応じた自動修正
4
4
 
5
5
  **コマンドコンテキスト**: 実装完了後の品質保証専用コマンド
6
6
 
7
- subagents-orchestration-guideスキルの指針に従い、**オーケストレーター**として振る舞います。
7
+ ## 実行方法
8
8
 
9
- **実行方法**:
10
- - Design Doc準拠検証 code-reviewer
11
- - 修正の本質理解rule-advisor
12
- - 実装修正task-executor
13
- - 品質チェック → quality-fixer
14
- - 再検証 → code-reviewer
9
+ - 準拠検証 → code-reviewerが実行
10
+ - 修正実装task-executorが実行
11
+ - 品質チェックquality-fixerが実行
12
+ - 再検証code-reviewerが実行
15
13
 
16
14
  オーケストレーターはサブエージェントを呼び出し、構造化JSONを渡します。
17
15
 
18
16
  Design Doc(省略時は直近のもの): $ARGUMENTS
19
17
 
20
- **Think deeply** 準拠検証の本質を理解し、以下のステップで実行:
18
+ 準拠検証の本質を理解し、以下のステップで実行:
21
19
 
22
20
  ## 実行フロー
23
21
 
@@ -31,7 +29,7 @@ git diff --name-only main...HEAD
31
29
  ```
32
30
 
33
31
  ### 2. code-reviewer実行
34
- Design Doc準拠率を検証:
32
+ Design Doc準拠率を検証:
35
33
  - 受入条件の充足確認
36
34
  - コード品質チェック
37
35
  - 実装完全性の評価
@@ -51,19 +49,18 @@ Design Doc準拠率を検証:
51
49
  未充足項目:
52
50
  - [項目リスト]
53
51
 
54
- 修正を実行しますか? (y/n):
52
+ 修正を実行しますか? (y/n):
55
53
  ```
56
54
 
57
55
  ユーザーが `y` を選択した場合:
58
56
 
59
- ## 修正実行前のメタ認知
60
- **必須**: `rule-advisor → TodoWrite → task-executor → quality-fixer`
57
+ #### 修正実行手順
58
+ **必須**: `TodoWrite → task-executor → quality-fixer`
61
59
 
62
- 1. **rule-advisor実行**: 修正の本質を理解(表面的な対症療法 vs 根本解決)
63
- 2. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレート(documentation-criteriaスキル参照)に従いタスクファイル作成 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
64
- 3. **task-executor実行**: 自動修正を段階的実行(5ファイル超過で停止)
65
- 4. **quality-fixer実行**: 品質ゲート通過を確認
66
- 5. **再検証**: code-reviewerで改善度を測定
60
+ 1. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」。タスクテンプレート(documentation-criteriaスキル参照)に従いタスクファイル作成 `docs/plans/tasks/review-fixes-YYYYMMDD.md`
61
+ 2. **task-executor実行**: 自動修正を段階的実行(5ファイル超過で停止)
62
+ 3. **quality-fixer実行**: 品質ゲート通過を確認
63
+ 4. **再検証**: code-reviewerで改善度を測定
67
64
 
68
65
  ### 4. 最終レポート
69
66
  ```
@@ -86,4 +83,4 @@ Design Doc準拠率を検証:
86
83
  - アーキテクチャレベルの修正
87
84
  - Design Doc自体の不備
88
85
 
89
- **スコープ**: Design Doc準拠検証と自動修正まで。
86
+ **スコープ**: Design Doc準拠検証と自動修正まで。
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "create-ai-project",
3
- "version": "1.14.10",
3
+ "version": "1.14.12",
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": [