create-ai-project 1.20.1 → 1.20.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.
|
@@ -16,12 +16,9 @@ This document provides practical behavioral guidelines for me (Claude) to effici
|
|
|
16
16
|
- **During flow execution**: STRICTLY follow scale-based flow
|
|
17
17
|
- **Each phase**: DELEGATE to appropriate subagent
|
|
18
18
|
- **Stop points**: ALWAYS wait for user approval
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
-
|
|
22
|
-
- Performing analysis or design without subagent delegation
|
|
23
|
-
- Saying "Let me first investigate" then starting work directly
|
|
24
|
-
- Skipping or postponing requirement-analyzer
|
|
19
|
+
- **Investigation**: Delegate all investigation to requirement-analyzer or codebase-analyzer (Grep/Glob/Read are specialist-internal tools)
|
|
20
|
+
- **Analysis/Design**: Delegate to the appropriate specialist subagent
|
|
21
|
+
- **First action**: Pass user requirements to requirement-analyzer before any other step
|
|
25
22
|
|
|
26
23
|
**First Action Rule**: To accurately analyze user requirements, pass them directly to requirement-analyzer and determine the workflow based on its analysis results.
|
|
27
24
|
|
|
@@ -68,6 +65,36 @@ graph TD
|
|
|
68
65
|
|
|
69
66
|
## My Orchestration Principles
|
|
70
67
|
|
|
68
|
+
### Delegation Boundary: What vs How
|
|
69
|
+
|
|
70
|
+
I pass **what to accomplish** and **where to work**. Each specialist determines **how to execute** autonomously.
|
|
71
|
+
|
|
72
|
+
**I pass to specialists** (what/where/constraints):
|
|
73
|
+
- Task file path — executor agents (task-executor, task-decomposer) receive a task file path; broader scope requires explicit user request
|
|
74
|
+
- Target directory or package scope — for discovery/review agents (codebase-analyzer, code-verifier, security-reviewer, integration-test-reviewer)
|
|
75
|
+
- Acceptance criteria and hard constraints from the user or design artifacts
|
|
76
|
+
|
|
77
|
+
**I let specialists determine** (how):
|
|
78
|
+
- Specific commands to run (specialists discover these from project configuration and repo conventions)
|
|
79
|
+
- Execution order and tool flags
|
|
80
|
+
- Executor/fixer agents: which files to inspect or modify within the given scope
|
|
81
|
+
- Review/discovery agents: which files to inspect within the given scope (read-only access)
|
|
82
|
+
|
|
83
|
+
| | Bad (I prescribe how) | Good (I pass what) |
|
|
84
|
+
|---|---|---|
|
|
85
|
+
| quality-fixer | "Run these checks: 1. lint 2. test" | "Execute all quality checks and fixes" |
|
|
86
|
+
| task-executor | "Edit file X and add handler Y" | "Task file: docs/plans/tasks/003-feature.md" |
|
|
87
|
+
|
|
88
|
+
**Decision precedence when outputs conflict**:
|
|
89
|
+
1. User instructions (explicit requests or constraints)
|
|
90
|
+
2. Task files and design artifacts (Design Doc, PRD, work plan)
|
|
91
|
+
3. Objective repo state (git status, file system, project configuration)
|
|
92
|
+
4. Specialist judgment
|
|
93
|
+
|
|
94
|
+
When two specialists conflict, or when a specialist conflicts with my expectation, I apply the precedence order above. I verify against objective repo state (item 3). I follow specialist output when it aligns with items 1 and 2. When specialist output conflicts with user instructions or design artifacts, I follow user instructions first, then design artifacts.
|
|
95
|
+
|
|
96
|
+
When a specialist cannot determine execution method from repo state and artifacts, the specialist escalates as blocked. I then escalate to the user with the specialist's blocked details.
|
|
97
|
+
|
|
71
98
|
### Task Assignment with Responsibility Separation
|
|
72
99
|
|
|
73
100
|
I understand each subagent's responsibilities and assign work appropriately:
|
|
@@ -109,16 +136,25 @@ I repeat this cycle for each task to ensure quality.
|
|
|
109
136
|
## Structured Response Specifications
|
|
110
137
|
|
|
111
138
|
Subagents respond in JSON format. Key fields for orchestrator decisions:
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
139
|
+
|
|
140
|
+
| Agent | Key Fields | Decision Logic |
|
|
141
|
+
|-------|-----------|----------------|
|
|
142
|
+
| requirement-analyzer | scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions | Select flow by scale; check adrRequired for ADR step |
|
|
143
|
+
| codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, focusAreas[], existingElements count, limitations | Pass focusAreas to technical-designer as context |
|
|
144
|
+
| code-verifier | consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent) | Flag discrepancies for document-reviewer |
|
|
145
|
+
| task-executor | status (escalation_needed/completed), escalation_type, testsAdded, requiresTestReview | On escalation_needed: handle by escalation_type (design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file) |
|
|
146
|
+
| quality-fixer | status (approved/blocked), reason, blockingIssues[], missingPrerequisites[] | On blocked: see quality-fixer blocked handling below |
|
|
147
|
+
| document-reviewer | approvalReady (true/false) | Proceed to next step on true; request fixes on false |
|
|
148
|
+
| design-sync | sync_status (synced/conflicts_found) | On conflicts_found: present conflicts to user before proceeding |
|
|
149
|
+
| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | On needs_revision: pass requiredFixes back to task-executor |
|
|
150
|
+
| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | On needs_revision: pass requiredFixes back to task-executor |
|
|
151
|
+
| acceptance-test-generator | status, generatedFiles | Pass generatedFiles to work-planner |
|
|
152
|
+
|
|
153
|
+
### quality-fixer Blocked Handling
|
|
154
|
+
|
|
155
|
+
When quality-fixer returns `status: "blocked"`, discriminate by `reason`:
|
|
156
|
+
- `"Cannot determine due to unclear specification"` → read `blockingIssues[]` for specification details
|
|
157
|
+
- `"Execution prerequisites not met"` → read `missingPrerequisites[]` with `resolutionSteps` and present to user as actionable next steps
|
|
122
158
|
|
|
123
159
|
## My Basic Flow for Work Planning
|
|
124
160
|
|
|
@@ -301,7 +337,7 @@ Construct the prompt from the agent's Input Parameters section and the deliverab
|
|
|
301
337
|
- **Structured response is MANDATORY**: Information transmission between subagents MUST use JSON format
|
|
302
338
|
- **Approval management**: Document creation -> Execute document-reviewer -> Get user approval BEFORE proceeding
|
|
303
339
|
- **Flow confirmation**: After getting approval, ALWAYS check next step with work planning flow (large/medium/small scale)
|
|
304
|
-
- **Consistency verification**:
|
|
340
|
+
- **Consistency verification**: When subagent outputs conflict, apply Decision precedence (see Delegation Boundary section)
|
|
305
341
|
|
|
306
342
|
## Required Dialogue Points with Humans
|
|
307
343
|
|
|
@@ -16,12 +16,9 @@ description: サブエージェントのタスク分担と連携を調整。規
|
|
|
16
16
|
- フロー実行中: 規模判定に基づくフローを厳守
|
|
17
17
|
- 各フェーズ: 適切なサブエージェントに委譲
|
|
18
18
|
- 停止ポイント: 必ずユーザー承認を待つ
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
-
|
|
22
|
-
- 自分で分析や設計を考え始める
|
|
23
|
-
- 「まず調べてみます」と言って作業を開始する
|
|
24
|
-
- requirement-analyzerを後回しにする
|
|
19
|
+
- **調査**: すべての調査はrequirement-analyzerまたはcodebase-analyzerに委譲（Grep/Glob/Readはサブエージェント内部のツール）
|
|
20
|
+
- **分析・設計**: 該当するサブエージェントに委譲
|
|
21
|
+
- **初動**: ユーザー要件はrequirement-analyzerに渡してから他のステップへ進む
|
|
25
22
|
|
|
26
23
|
**初動アクション規則**: ユーザー要件を正確に分析するため、requirement-analyzerに直接渡し、その分析結果に基づいてワークフローを決定する。
|
|
27
24
|
|
|
@@ -34,6 +31,8 @@ graph TD
|
|
|
34
31
|
Scale --> Flow[規模に応じたフロー実行]
|
|
35
32
|
```
|
|
36
33
|
|
|
34
|
+
**フロー実行中は規模判定表に従って次のサブエージェントを決定する**
|
|
35
|
+
|
|
37
36
|
### フロー実行中の要件変更検知
|
|
38
37
|
|
|
39
38
|
**フロー実行中**にユーザーレスポンスで以下を検知したら、フローを停止してrequirement-analyzerへ：
|
|
@@ -66,6 +65,36 @@ graph TD
|
|
|
66
65
|
|
|
67
66
|
## オーケストレーション原則
|
|
68
67
|
|
|
68
|
+
### 委譲の境界: What vs How
|
|
69
|
+
|
|
70
|
+
「何を達成するか」「どこで作業するか」を渡す。各サブエージェントは「どう実行するか」を自律的に決定する。
|
|
71
|
+
|
|
72
|
+
**渡す情報**（what/where/制約）:
|
|
73
|
+
- タスクファイルパス — executor系（task-executor, task-decomposer）にはタスクファイルパスを渡す。より広いスコープはユーザーの明示的な要求がある場合のみ
|
|
74
|
+
- ディレクトリまたはパッケージスコープ — discovery/review系（codebase-analyzer, code-verifier, security-reviewer, integration-test-reviewer）向け
|
|
75
|
+
- ユーザーまたは設計成果物からの受入条件とハード制約
|
|
76
|
+
|
|
77
|
+
**サブエージェントに委ねる判断**（how）:
|
|
78
|
+
- 実行するコマンド（プロジェクト設定やリポジトリの規約からサブエージェントが判断）
|
|
79
|
+
- 実行順序やツールフラグ
|
|
80
|
+
- Executor/fixer系: スコープ内で調査・変更するファイルの選択
|
|
81
|
+
- Review/discovery系: スコープ内で調査するファイルの選択（読み取り専用）
|
|
82
|
+
|
|
83
|
+
| | Bad（howを指定） | Good（whatを指定） |
|
|
84
|
+
|---|---|---|
|
|
85
|
+
| quality-fixer | 「lint → test の順でチェックして」 | 「品質チェックと修正をすべて実行して」 |
|
|
86
|
+
| task-executor | 「ファイルXにハンドラYを追加して」 | 「タスクファイル: docs/plans/tasks/003-feature.md」 |
|
|
87
|
+
|
|
88
|
+
**出力が矛盾した場合の優先順位**:
|
|
89
|
+
1. ユーザー指示（明示的な要求や制約）
|
|
90
|
+
2. タスクファイルと設計成果物（Design Doc, PRD, 作業計画書）
|
|
91
|
+
3. リポジトリの客観的状態（git status、ファイルシステム、プロジェクト設定）
|
|
92
|
+
4. サブエージェントの判断
|
|
93
|
+
|
|
94
|
+
サブエージェント同士の判断が衝突した場合、またはサブエージェントの出力が期待と異なる場合、上記の優先順位を適用する。リポジトリの客観的状態（3）で検証し、1・2と整合する出力に従う。矛盾がある場合はユーザー指示、次いで設計成果物に従う。
|
|
95
|
+
|
|
96
|
+
サブエージェントがリポジトリの状態や成果物から実行方法を判断できない場合、blockedステータスでエスカレーションする。その詳細をユーザーに伝える。
|
|
97
|
+
|
|
69
98
|
### 責務分離を意識した振り分け
|
|
70
99
|
|
|
71
100
|
**task-executorの責務**:
|
|
@@ -105,16 +134,25 @@ graph TD
|
|
|
105
134
|
## 構造化レスポンス仕様
|
|
106
135
|
|
|
107
136
|
サブエージェントはJSON形式で応答。オーケストレーター判断に必要なフィールド：
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
137
|
+
|
|
138
|
+
| Agent | 主要フィールド | 判断ロジック |
|
|
139
|
+
|-------|---------------|-------------|
|
|
140
|
+
| requirement-analyzer | scale, confidence, adrRequired, crossLayerScope, scopeDependencies, questions | scaleでフローを選択。adrRequiredでADRステップ要否を判断 |
|
|
141
|
+
| codebase-analyzer | analysisScope.categoriesDetected, dataModel.detected, focusAreas[], existingElements count, limitations | focusAreasをtechnical-designerにコンテキストとして渡す |
|
|
142
|
+
| code-verifier | consistencyScore, discrepancies[], reverseCoverage (dataOperationsInCode, testBoundariesSectionPresent) | discrepanciesをdocument-reviewerに連携 |
|
|
143
|
+
| task-executor | status (escalation_needed/completed), escalation_type, testsAdded, requiresTestReview | escalation_needed時: escalation_type別に対応（design_compliance_violation, similar_function_found, similar_component_found, investigation_target_not_found, out_of_scope_file） |
|
|
144
|
+
| quality-fixer | status (approved/blocked), reason, blockingIssues[], missingPrerequisites[] | blocked時: 下記quality-fixer blockedハンドリング参照 |
|
|
145
|
+
| document-reviewer | approvalReady (true/false) | trueで次ステップへ。falseで修正を依頼 |
|
|
146
|
+
| design-sync | sync_status (synced/conflicts_found) | conflicts_found時: 矛盾をユーザーに提示してから進む |
|
|
147
|
+
| integration-test-reviewer | status (approved/needs_revision/blocked), requiredFixes | needs_revision時: requiredFixesをtask-executorに戻す |
|
|
148
|
+
| security-reviewer | status (approved/approved_with_notes/needs_revision/blocked), findings, notes, requiredFixes | needs_revision時: requiredFixesをtask-executorに戻す |
|
|
149
|
+
| acceptance-test-generator | status, generatedFiles | generatedFilesをwork-plannerに渡す |
|
|
150
|
+
|
|
151
|
+
### quality-fixer blockedハンドリング
|
|
152
|
+
|
|
153
|
+
quality-fixerが `status: "blocked"` を返した場合、`reason`で判別：
|
|
154
|
+
- `"Cannot determine due to unclear specification"` → `blockingIssues[]`で仕様詳細を確認
|
|
155
|
+
- `"Execution prerequisites not met"` → `missingPrerequisites[]`の`resolutionSteps`をユーザーにアクション可能なステップとして提示
|
|
118
156
|
|
|
119
157
|
## 作業計画時の基本フロー
|
|
120
158
|
|
|
@@ -295,7 +333,7 @@ requirement-analyzerが複数レイヤー（backend + frontend）にまたがる
|
|
|
295
333
|
- **構造化レスポンス必須**: サブエージェント間の情報伝達はJSON形式
|
|
296
334
|
- **承認管理**: ドキュメント作成→document-reviewer実行→ユーザー承認を得てから次へ進む
|
|
297
335
|
- **フロー確認**: 承認取得後は必ず作業計画フロー（大規模/中規模/小規模）で次のステップを確認
|
|
298
|
-
- **整合性検証**:
|
|
336
|
+
- **整合性検証**: サブエージェントの出力が矛盾した場合、優先順位に従って解決（委譲の境界セクション参照）
|
|
299
337
|
|
|
300
338
|
## 人間との必須対話ポイント
|
|
301
339
|
|
package/CHANGELOG.md
CHANGED
|
@@ -5,6 +5,22 @@ All notable changes to this project will be documented in this file.
|
|
|
5
5
|
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
|
|
6
6
|
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
|
|
7
7
|
|
|
8
|
+
## [1.20.2] - 2026-04-03
|
|
9
|
+
|
|
10
|
+
### Added
|
|
11
|
+
|
|
12
|
+
- **Delegation Boundary: What vs How** (subagents-orchestration-guide): Orchestrator lacked a definition of what granularity to pass to specialists vs what to let them decide autonomously. Added what/where/constraints vs how separation, Bad/Good comparison table, 4-tier decision precedence for conflict resolution, and escalation rule for undeterminable execution methods
|
|
13
|
+
- **Scope granularity per agent type**: Executor agents receive task file paths by default (broader scope requires explicit user request); discovery/review agents receive directory or package scope with read-only access
|
|
14
|
+
- **quality-fixer blocked handling subsection** (Structured Response Specifications): Moved quality-fixer's multi-branch decision logic from an overloaded table cell into a dedicated subsection for scannability
|
|
15
|
+
|
|
16
|
+
### Changed
|
|
17
|
+
|
|
18
|
+
- **Prohibited Actions → positive-form Required Actions**: Negative instructions ("don't investigate directly", "don't skip requirement-analyzer") caused Pink Elephant Problem. Converted to affirmative delegation instructions ("Delegate all investigation to requirement-analyzer or codebase-analyzer")
|
|
19
|
+
- **Structured Response Specifications table format**: Bullet list with mixed-length entries replaced with Agent / Key Fields / Decision Logic table. Each agent's response-to-action mapping is now explicit
|
|
20
|
+
- **Consistency verification constraint**: Vague "prioritize these guidelines" replaced with reference to Decision precedence in the Delegation Boundary section
|
|
21
|
+
- **Remaining negative-form instructions cleaned**: "no modification" → "read-only access", "instead of guessing" removed, "higher-precedence source" → explicit "user instructions first, then design artifacts"
|
|
22
|
+
- **Japanese version: missing operational line added**: "フロー実行中は規模判定表に従って次のサブエージェントを決定する" was present in English but missing in Japanese
|
|
23
|
+
|
|
8
24
|
## [1.20.1] - 2026-04-02
|
|
9
25
|
|
|
10
26
|
### Added
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "create-ai-project",
|
|
3
|
-
"version": "1.20.
|
|
3
|
+
"version": "1.20.2",
|
|
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": [
|