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.
@@ -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
- Following the design flow described in subagents-orchestration-guide skill, execute **from requirement-analyzer to design document creation and approval**.
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
- **Scope Boundary**:
21
- - IN SCOPE: Design document (ADR/Design Doc) approval + Design Doc consistency verification
22
- - OUT OF SCOPE: Work planning and implementation phases
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**: All work is executed through sub-agents
12
- - investigatorverifier solver
11
+ **Execution Method**:
12
+ - Investigationperformed 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
- **Command Context**: As orchestrator, autonomously completes frontend implementation in autonomous execution mode.
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
- ## 📋 Pre-execution Prerequisites
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
- ## 🔄 Task Decomposition Phase (Conditional)
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
- ✅ **Recommended**: After task generation, automatically proceed to autonomous execution
57
- ❌ **Avoid**: Starting implementation without task generation
68
+ ✅ **Flow**: Task generation Autonomous execution (in this order)
58
69
 
59
- ## 🧠 Metacognition for Each Task - Frontend Specialized
70
+ ## Task Execution Cycle (4-Step Cycle) - Frontend Specialized
60
71
 
61
- **Required Execution Cycle**: `task-executor-frontend → quality-fixer-frontend → commit`
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
- Execute for EACH task:
87
+ For EACH task, YOU MUST:
77
88
 
78
- 1. **USE task-executor-frontend**: Execute frontend implementation
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
- 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)
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
- 4. **EXECUTE commit**: After `approved: true` confirmation, execute git commit immediately
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 → **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
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
- **Think deeply**: Monitor all structured responses and ensure every quality gate is passed.
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
- Execute **from requirement analysis to frontend design document creation and approval**.
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 Boundary**:
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
- ## 🧠 Pre-fix Metacognition
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
- subagents-orchestration-guideスキルの設計フローに従い、**requirement-analyzer から設計書作成・承認まで**を実行します。
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
- **スコープ**: 設計書(ADR/Design Doc)承認+Design Doc間整合性確認まで。作業計画以降は本コマンドの責務外。
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
- - investigatorverifier → solver
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. **task-executor-frontend使用**: フロントエンド実装を実行
89
+ 1. **TodoWrite更新**: 作業ステップを登録。必ず含める: 最初に「スキル制約の確認」、最後に「スキル忠実度の検証」
90
+ 2. **task-executor-frontend使用**: フロントエンド実装を実行
79
91
  - 呼び出し例: `subagent_type: "task-executor-frontend"`, `description: "タスク実行"`, `prompt: "タスクファイル: docs/plans/tasks/[ファイル名].md 実装を実行"`
80
- 2. **構造化レスポンス処理**: `readyForQualityCheck: true` 検出時即座にquality-fixer-frontend実行
81
- 3. **quality-fixer-frontend使用**: 全品質チェック実行(Biome、TypeScriptビルド、テスト)
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
- 4. **コミット実行**: `approved: true`確認後、即座にgit commitを実行
96
+ 6. **コミット実行**: `approved: true`確認後、即座にgit commitを実行
84
97
 
85
98
  ### 自律実行中の品質保証(詳細)
86
- - task-executor-frontend実行 → quality-fixer-frontend実行 → **私(メインAI)がコミット実行**(Bashツール使用)
99
+ - task-executor-frontend実行 → エスカレーションチェック → quality-fixer-frontend実行 → **オーケストレーターがコミット実行**(Bashツール使用)
87
100
  - quality-fixer-frontendの`approved: true`確認後、即座にgit commitを実行
88
- - changeSummaryをコミットメッセージに使用
101
+ - `changeSummary`をコミットメッセージに使用
89
102
 
90
- **THINK DEEPLY**: 例外なく全ての構造化レスポンスを監視し、全ての品質ゲートが通過することを確保。
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
- subagents-orchestration-guideスキルの指針に従い、以下のプロセスで作業計画書を作成します:
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更新**: 修正タスクを構造化 → `docs/plans/tasks/review-fixes-YYYYMMDD.md`
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.6",
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": [