speccrew 0.1.1 → 0.1.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.ar.md +98 -91
- package/README.bn.md +122 -0
- package/README.bs.md +321 -0
- package/README.da.md +321 -0
- package/README.de.md +321 -0
- package/README.el.md +122 -0
- package/README.en.md +92 -85
- package/README.es.md +96 -89
- package/README.fr.md +321 -0
- package/README.it.md +321 -0
- package/README.ja.md +321 -0
- package/README.ko.md +321 -0
- package/README.md +92 -109
- package/README.no.md +321 -0
- package/README.pl.md +321 -0
- package/README.pt-BR.md +321 -0
- package/README.ru.md +321 -0
- package/README.th.md +239 -0
- package/README.tr.md +239 -0
- package/README.uk.md +239 -0
- package/README.vi.md +122 -0
- package/README.zh-TW.md +321 -0
- package/bin/cli.js +5 -1
- package/bin/postinstall.js +157 -0
- package/docs/GETTING-STARTED.ar.md +452 -0
- package/docs/GETTING-STARTED.bn.md +449 -0
- package/docs/GETTING-STARTED.bs.md +449 -0
- package/docs/GETTING-STARTED.da.md +448 -0
- package/docs/GETTING-STARTED.de.md +448 -0
- package/docs/GETTING-STARTED.el.md +449 -0
- package/docs/GETTING-STARTED.en.md +448 -0
- package/docs/GETTING-STARTED.es.md +448 -0
- package/docs/GETTING-STARTED.fr.md +448 -0
- package/docs/GETTING-STARTED.it.md +448 -0
- package/docs/GETTING-STARTED.ja.md +448 -0
- package/docs/GETTING-STARTED.ko.md +448 -0
- package/docs/GETTING-STARTED.md +448 -0
- package/docs/GETTING-STARTED.no.md +449 -0
- package/docs/GETTING-STARTED.pl.md +449 -0
- package/docs/GETTING-STARTED.pt-BR.md +449 -0
- package/docs/GETTING-STARTED.ru.md +449 -0
- package/docs/GETTING-STARTED.th.md +449 -0
- package/docs/GETTING-STARTED.tr.md +449 -0
- package/docs/GETTING-STARTED.uk.md +449 -0
- package/docs/GETTING-STARTED.vi.md +449 -0
- package/docs/GETTING-STARTED.zh-TW.md +448 -0
- package/lib/commands/init.js +238 -41
- package/lib/commands/uninstall.js +150 -32
- package/lib/commands/update.js +159 -24
- package/lib/ide-adapters.js +257 -3
- package/lib/utils.js +23 -7
- package/package.json +7 -2
|
@@ -0,0 +1,448 @@
|
|
|
1
|
+
# SpecCrew クイックスタートガイド
|
|
2
|
+
|
|
3
|
+
<p align="center">
|
|
4
|
+
<a href="./GETTING-STARTED.md">简体中文</a> |
|
|
5
|
+
<a href="./GETTING-STARTED.zh-TW.md">繁體中文</a> |
|
|
6
|
+
<a href="./GETTING-STARTED.en.md">English</a> |
|
|
7
|
+
<a href="./GETTING-STARTED.ko.md">한국어</a> |
|
|
8
|
+
<a href="./GETTING-STARTED.de.md">Deutsch</a> |
|
|
9
|
+
<a href="./GETTING-STARTED.es.md">Español</a> |
|
|
10
|
+
<a href="./GETTING-STARTED.fr.md">Français</a> |
|
|
11
|
+
<a href="./GETTING-STARTED.it.md">Italiano</a> |
|
|
12
|
+
<a href="./GETTING-STARTED.da.md">Dansk</a> |
|
|
13
|
+
<a href="./GETTING-STARTED.ja.md">日本語</a> |
|
|
14
|
+
<a href="./GETTING-STARTED.ar.md">العربية</a>
|
|
15
|
+
</p>
|
|
16
|
+
|
|
17
|
+
このドキュメントは、SpecCrewのエージェントチームを使用して、標準的なエンジニアリングワークフローに従って要件からデリバリーまでの完全な開発を段階的に完了する方法を素早く理解するのに役立ちます。
|
|
18
|
+
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
## 1. 事前準備
|
|
22
|
+
|
|
23
|
+
### SpecCrewのインストール
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
npm install -g speccrew
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
### プロジェクトの初期化
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
speccrew init --ide qoder
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
サポートされているIDE:`qoder`、`cursor`、`claude`、`codex`
|
|
36
|
+
|
|
37
|
+
### 初期化後のディレクトリ構造
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
.
|
|
41
|
+
├── .qoder/
|
|
42
|
+
│ ├── agents/ # エージェント定義ファイル
|
|
43
|
+
│ └── skills/ # スキル定義ファイル
|
|
44
|
+
├── speccrew-workspace/ # ワークスペース
|
|
45
|
+
│ ├── docs/ # 設定、ルール、テンプレート、ソリューション
|
|
46
|
+
│ ├── iterations/ # 進行中のイテレーション
|
|
47
|
+
│ ├── iteration-archives/ # アーカイブされたイテレーション
|
|
48
|
+
│ └── knowledges/ # ナレッジベース
|
|
49
|
+
│ ├── base/ # 基本情報(診断レポート、技術的負債)
|
|
50
|
+
│ ├── bizs/ # ビジネスナレッジベース
|
|
51
|
+
│ └── techs/ # テクニカルナレッジベース
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
### CLIコマンドクイックリファレンス
|
|
55
|
+
|
|
56
|
+
| コマンド | 説明 |
|
|
57
|
+
|------|------|
|
|
58
|
+
| `speccrew list` | 利用可能なすべてのエージェントとスキルを一覧表示 |
|
|
59
|
+
| `speccrew doctor` | インストールの完全性をチェック |
|
|
60
|
+
| `speccrew update` | プロジェクト設定を最新バージョンに更新 |
|
|
61
|
+
| `speccrew uninstall` | SpecCrewをアンインストール |
|
|
62
|
+
|
|
63
|
+
---
|
|
64
|
+
|
|
65
|
+
## 2. ワークフロー概要
|
|
66
|
+
|
|
67
|
+
### 完全フロー図
|
|
68
|
+
|
|
69
|
+
```mermaid
|
|
70
|
+
flowchart LR
|
|
71
|
+
PRD[フェーズ1<br/>要件分析<br/>Product Manager] --> FD[フェーズ2<br/>機能設計<br/>Feature Designer]
|
|
72
|
+
FD --> SD[フェーズ3<br/>システム設計<br/>System Designer]
|
|
73
|
+
SD --> DEV[フェーズ4<br/>開発実装<br/>System Developer]
|
|
74
|
+
DEV --> TEST[フェーズ5<br/>システムテスト<br/>Test Manager]
|
|
75
|
+
TEST --> ARCHIVE[フェーズ6<br/>アーカイブ]
|
|
76
|
+
|
|
77
|
+
KB[(ナレッジベース<br/>全体を通して)] -.-> PRD
|
|
78
|
+
KB -.-> FD
|
|
79
|
+
KB -.-> SD
|
|
80
|
+
KB -.-> DEV
|
|
81
|
+
KB -.-> TEST
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
### 核心原則
|
|
85
|
+
|
|
86
|
+
1. **フェーズ依存関係**:各フェーズの成果物は次のフェーズの入力
|
|
87
|
+
2. **チェックポイント確認**:各フェーズに確認ポイントがあり、ユーザー確認後に次のフェーズに進む
|
|
88
|
+
3. **ナレッジベース駆動**:ナレッジベースは全体を通して各フェーズにコンテキストを提供
|
|
89
|
+
|
|
90
|
+
---
|
|
91
|
+
|
|
92
|
+
## 3. ステップ0:プロジェクト診断とナレッジベース初期化
|
|
93
|
+
|
|
94
|
+
正式なエンジニアリングフローを開始する前に、プロジェクトナレッジベースを初期化する必要があります。
|
|
95
|
+
|
|
96
|
+
### 3.1 プロジェクト診断
|
|
97
|
+
|
|
98
|
+
**会話例**:
|
|
99
|
+
```
|
|
100
|
+
@speccrew-team-leader プロジェクトを診断
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
**エージェントの動作**:
|
|
104
|
+
- プロジェクト構造をスキャン
|
|
105
|
+
- テクノロジースタックを検出
|
|
106
|
+
- ビジネスモジュールを識別
|
|
107
|
+
|
|
108
|
+
**成果物**:
|
|
109
|
+
```
|
|
110
|
+
speccrew-workspace/knowledges/base/diagnosis-reports/diagnosis-report-{date}.md
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
### 3.2 テクニカルナレッジベース初期化
|
|
114
|
+
|
|
115
|
+
**会話例**:
|
|
116
|
+
```
|
|
117
|
+
@speccrew-team-leader テクニカルナレッジベースを初期化
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
**3段階フロー**:
|
|
121
|
+
1. プラットフォーム検出 — プロジェクト内の技術プラットフォームを識別
|
|
122
|
+
2. 技術文書生成 — 各プラットフォームの技術仕様文書を生成
|
|
123
|
+
3. インデックス生成 — ナレッジベースインデックスを構築
|
|
124
|
+
|
|
125
|
+
**成果物**:
|
|
126
|
+
```
|
|
127
|
+
speccrew-workspace/knowledges/techs/{platform-id}/
|
|
128
|
+
├── tech-stack.md # テクノロジースタック定義
|
|
129
|
+
├── architecture.md # アーキテクチャ規約
|
|
130
|
+
├── dev-spec.md # 開発規約
|
|
131
|
+
├── test-spec.md # テスト規約
|
|
132
|
+
└── INDEX.md # インデックスファイル
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
### 3.3 ビジネスナレッジベース初期化
|
|
136
|
+
|
|
137
|
+
**会話例**:
|
|
138
|
+
```
|
|
139
|
+
@speccrew-team-leader ビジネスナレッジベースを初期化
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
**4段階フロー**:
|
|
143
|
+
1. 機能リスト — コードをスキャンしてすべての機能を識別
|
|
144
|
+
2. 機能分析 — 各機能のビジネスロジックを分析
|
|
145
|
+
3. モジュール要約 — モジュール別に機能を要約
|
|
146
|
+
4. システム要約 — システムレベルのビジネス概要を生成
|
|
147
|
+
|
|
148
|
+
**成果物**:
|
|
149
|
+
```
|
|
150
|
+
speccrew-workspace/knowledges/bizs/
|
|
151
|
+
├── {platform-type}/
|
|
152
|
+
│ └── {module-name}/
|
|
153
|
+
│ └── feature-spec.md
|
|
154
|
+
└── system-overview.md
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
## 4. フェーズ別会話ガイド
|
|
160
|
+
|
|
161
|
+
### 4.1 フェーズ1:要件分析(Product Manager)
|
|
162
|
+
|
|
163
|
+
**起動方法**:
|
|
164
|
+
```
|
|
165
|
+
@speccrew-product-manager 新しい要件があります:[要件を説明]
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
**エージェントワークフロー**:
|
|
169
|
+
1. システム概要を読み込んで既存モジュールを理解
|
|
170
|
+
2. ユーザー要件を分析
|
|
171
|
+
3. 構造化されたPRD文書を生成
|
|
172
|
+
|
|
173
|
+
**成果物**:
|
|
174
|
+
```
|
|
175
|
+
iterations/{シーケンス}-{タイプ}-{名前}/01.product-requirement/
|
|
176
|
+
├── [feature-name]-prd.md # 製品要件文書
|
|
177
|
+
└── [feature-name]-bizs-modeling.md # ビジネスモデリング(複雑な要件の場合)
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
**確認ポイント**:
|
|
181
|
+
- [ ] 要件の説明がユーザーの意図を正確に反映しているか
|
|
182
|
+
- [ ] ビジネスルールが完全か
|
|
183
|
+
- [ ] 既存システムとの統合ポイントが明確か
|
|
184
|
+
- [ ] 受け入れ基準が測定可能か
|
|
185
|
+
|
|
186
|
+
---
|
|
187
|
+
|
|
188
|
+
### 4.2 フェーズ2:機能設計(Feature Designer)
|
|
189
|
+
|
|
190
|
+
**起動方法**:
|
|
191
|
+
```
|
|
192
|
+
@speccrew-feature-designer 機能設計を開始
|
|
193
|
+
```
|
|
194
|
+
|
|
195
|
+
**エージェントワークフロー**:
|
|
196
|
+
1. 確認済みのPRD文書を自動検出
|
|
197
|
+
2. ビジネスナレッジベースをロード
|
|
198
|
+
3. 機能設計を生成(UIワイヤーフレーム、インタラクションフロー、データ定義、API契約を含む)
|
|
199
|
+
4. 複数のPRDがある場合、タスクワーカーで並列設計
|
|
200
|
+
|
|
201
|
+
**成果物**:
|
|
202
|
+
```
|
|
203
|
+
iterations/{iter}/02.feature-design/
|
|
204
|
+
└── [feature-name]-feature-spec.md # 機能設計文書
|
|
205
|
+
```
|
|
206
|
+
|
|
207
|
+
**確認ポイント**:
|
|
208
|
+
- [ ] すべてのユーザシナリオがカバーされているか
|
|
209
|
+
- [ ] インタラクションフローが明確か
|
|
210
|
+
- [ ] データフィールド定義が完全か
|
|
211
|
+
- [ ] 例外処理が適切か
|
|
212
|
+
|
|
213
|
+
---
|
|
214
|
+
|
|
215
|
+
### 4.3 フェーズ3:システム設計(System Designer)
|
|
216
|
+
|
|
217
|
+
**起動方法**:
|
|
218
|
+
```
|
|
219
|
+
@speccrew-system-designer システム設計を開始
|
|
220
|
+
```
|
|
221
|
+
|
|
222
|
+
**エージェントワークフロー**:
|
|
223
|
+
1. Feature SpecとAPI契約を検出
|
|
224
|
+
2. テクニカルナレッジベース(各エンドのテクノロジースタック、アーキテクチャ、規約)をロード
|
|
225
|
+
3. **チェックポイントA**:フレームワーク評価 — 技術ギャップを分析、新しいフレームワークを推奨(必要に応じて)、ユーザー確認を待機
|
|
226
|
+
4. DESIGN-OVERVIEW.mdを生成
|
|
227
|
+
5. タスクワーカーで各エンド設計を並列ディスパッチ(フロントエンド/バックエンド/モバイル/デスクトップ)
|
|
228
|
+
6. **チェックポイントB**:共同確認 — すべてのプラットフォーム設計の要約を表示、ユーザー確認を待機
|
|
229
|
+
|
|
230
|
+
**成果物**:
|
|
231
|
+
```
|
|
232
|
+
iterations/{iter}/03.system-design/
|
|
233
|
+
├── DESIGN-OVERVIEW.md # 設計概要
|
|
234
|
+
├── {platform-id}/
|
|
235
|
+
│ ├── INDEX.md # 各プラットフォーム設計インデックス
|
|
236
|
+
│ └── {module}-design.md # 擬似コードレベルモジュール設計
|
|
237
|
+
```
|
|
238
|
+
|
|
239
|
+
**確認ポイント**:
|
|
240
|
+
- [ ] 擬似コードが実際のフレームワーク構文を使用しているか
|
|
241
|
+
- [ ] クロスエンドAPI契約が一貫しているか
|
|
242
|
+
- [ ] エラー処理戦略が統一されているか
|
|
243
|
+
|
|
244
|
+
---
|
|
245
|
+
|
|
246
|
+
### 4.4 フェーズ4:開発実装(System Developer)
|
|
247
|
+
|
|
248
|
+
**起動方法**:
|
|
249
|
+
```
|
|
250
|
+
@speccrew-system-developer 開発を開始
|
|
251
|
+
```
|
|
252
|
+
|
|
253
|
+
**エージェントワークフロー**:
|
|
254
|
+
1. システム設計文書を読み込む
|
|
255
|
+
2. 各エンドの技術知識をロード
|
|
256
|
+
3. **チェックポイントA**:環境プレチェック — ランタイムバージョン、依存関係、サービス可用性をチェック、失敗時はユーザー解決を待機
|
|
257
|
+
4. タスクワーカーで各エンド開発を並列ディスパッチ
|
|
258
|
+
5. 統合チェック:API契約の整合性、データ一貫性
|
|
259
|
+
6. デリバリレポートを出力
|
|
260
|
+
|
|
261
|
+
**成果物**:
|
|
262
|
+
```
|
|
263
|
+
# ソースコードはプロジェクトの実際のソースディレクトリに書き込まれる
|
|
264
|
+
iterations/{iter}/04.development/
|
|
265
|
+
├── {platform-id}/
|
|
266
|
+
│ └── tasks/ # 開発タスク記録
|
|
267
|
+
└── delivery-report.md
|
|
268
|
+
```
|
|
269
|
+
|
|
270
|
+
**確認ポイント**:
|
|
271
|
+
- [ ] 環境が準備完了か
|
|
272
|
+
- [ ] 統合問題が許容範囲内か
|
|
273
|
+
- [ ] コードが開発規約に準拠しているか
|
|
274
|
+
|
|
275
|
+
---
|
|
276
|
+
|
|
277
|
+
### 4.5 フェーズ5:システムテスト(Test Manager)
|
|
278
|
+
|
|
279
|
+
**起動方法**:
|
|
280
|
+
```
|
|
281
|
+
@speccrew-test-manager テストを開始
|
|
282
|
+
```
|
|
283
|
+
|
|
284
|
+
**3段階テストフロー**:
|
|
285
|
+
|
|
286
|
+
| フェーズ | 説明 | チェックポイント |
|
|
287
|
+
|------|------|------------|
|
|
288
|
+
| テストケース設計 | PRDとFeature Specに基づいてテストケースを生成 | A:カバレッジ統計とトレースマトリックスを表示、ユーザー確認を待機 |
|
|
289
|
+
| テストコード生成 | 実行可能なテストコードを生成 | B:生成されたテストファイルとケースマッピングを表示、ユーザー確認を待機 |
|
|
290
|
+
| テスト実行とバグレポート | テストを自動実行、レポートを生成 | なし(自動実行) |
|
|
291
|
+
|
|
292
|
+
**成果物**:
|
|
293
|
+
```
|
|
294
|
+
iterations/{iter}/05.system-test/
|
|
295
|
+
├── cases/
|
|
296
|
+
│ └── {platform-id}/ # テストケース文書
|
|
297
|
+
├── code/
|
|
298
|
+
│ └── {platform-id}/ # テストコード計画
|
|
299
|
+
├── reports/
|
|
300
|
+
│ └── test-report-{date}.md # テストレポート
|
|
301
|
+
└── bugs/
|
|
302
|
+
└── BUG-{id}-{title}.md # バグレポート(バグごとに1ファイル)
|
|
303
|
+
```
|
|
304
|
+
|
|
305
|
+
**確認ポイント**:
|
|
306
|
+
- [ ] ケースカバレッジが完全か
|
|
307
|
+
- [ ] テストコードが実行可能か
|
|
308
|
+
- [ ] バグの重大度判定が正確か
|
|
309
|
+
|
|
310
|
+
---
|
|
311
|
+
|
|
312
|
+
### 4.6 フェーズ6:アーカイブ
|
|
313
|
+
|
|
314
|
+
イテレーション完了後に自動アーカイブ:
|
|
315
|
+
|
|
316
|
+
```
|
|
317
|
+
speccrew-workspace/iteration-archives/
|
|
318
|
+
└── {シーケンス}-{タイプ}-{名前}-{日付}/
|
|
319
|
+
├── 01.product-requirement/
|
|
320
|
+
├── 02.feature-design/
|
|
321
|
+
├── 03.system-design/
|
|
322
|
+
├── 04.development/
|
|
323
|
+
└── 05.system-test/
|
|
324
|
+
```
|
|
325
|
+
|
|
326
|
+
---
|
|
327
|
+
|
|
328
|
+
## 5. ナレッジベースの説明
|
|
329
|
+
|
|
330
|
+
### 5.1 ビジネスナレッジベース(bizs)
|
|
331
|
+
|
|
332
|
+
**目的**:プロジェクトのビジネス機能の説明、モジュール分割、API特性を保存
|
|
333
|
+
|
|
334
|
+
**ディレクトリ構造**:
|
|
335
|
+
```
|
|
336
|
+
knowledges/bizs/
|
|
337
|
+
├── {platform-type}/
|
|
338
|
+
│ └── {module-name}/
|
|
339
|
+
│ └── feature-spec.md
|
|
340
|
+
└── system-overview.md
|
|
341
|
+
```
|
|
342
|
+
|
|
343
|
+
**使用シーン**:Product Manager、Feature Designer
|
|
344
|
+
|
|
345
|
+
### 5.2 テクニカルナレッジベース(techs)
|
|
346
|
+
|
|
347
|
+
**目的**:プロジェクトのテクノロジースタック、アーキテクチャ規約、開発規約、テスト規約を保存
|
|
348
|
+
|
|
349
|
+
**ディレクトリ構造**:
|
|
350
|
+
```
|
|
351
|
+
knowledges/techs/{platform-id}/
|
|
352
|
+
├── tech-stack.md
|
|
353
|
+
├── architecture.md
|
|
354
|
+
├── dev-spec.md
|
|
355
|
+
├── test-spec.md
|
|
356
|
+
└── INDEX.md
|
|
357
|
+
```
|
|
358
|
+
|
|
359
|
+
**使用シーン**:System Designer、System Developer、Test Manager
|
|
360
|
+
|
|
361
|
+
---
|
|
362
|
+
|
|
363
|
+
## 6. よくある質問(FAQ)
|
|
364
|
+
|
|
365
|
+
### Q1: エージェントが期待通りに動作しない場合は?
|
|
366
|
+
|
|
367
|
+
1. `speccrew doctor`を実行してインストールの完全性をチェック
|
|
368
|
+
2. ナレッジベースが初期化されていることを確認
|
|
369
|
+
3. 現在のイテレーションディレクトリに前フェーズの成果物があることを確認
|
|
370
|
+
|
|
371
|
+
### Q2: フェーズをスキップするには?
|
|
372
|
+
|
|
373
|
+
**スキップは推奨されません**。各フェーズの成果物は次のフェーズの入力です。
|
|
374
|
+
|
|
375
|
+
スキップが必須の場合は、対応するフェーズの入力文書を手動で準備し、形式が仕様に準拠していることを確認してください。
|
|
376
|
+
|
|
377
|
+
### Q3: 複数の要件を並列処理するには?
|
|
378
|
+
|
|
379
|
+
各要件に独立したイテレーションディレクトリを作成:
|
|
380
|
+
```
|
|
381
|
+
iterations/
|
|
382
|
+
├── 001-feature-xxx/
|
|
383
|
+
├── 002-feature-yyy/
|
|
384
|
+
└── 003-feature-zzz/
|
|
385
|
+
```
|
|
386
|
+
|
|
387
|
+
各イテレーションは完全に隔離され、相互に影響しません。
|
|
388
|
+
|
|
389
|
+
### Q4: SpecCrewのバージョンを更新するには?
|
|
390
|
+
|
|
391
|
+
- **グローバル更新**:`npm update -g speccrew`
|
|
392
|
+
- **プロジェクト更新**:プロジェクトディレクトリで`speccrew update`を実行
|
|
393
|
+
|
|
394
|
+
### Q5: 過去のイテレーションを表示するには?
|
|
395
|
+
|
|
396
|
+
アーカイブ後、`speccrew-workspace/iteration-archives/`で表示、`{シーケンス}-{タイプ}-{名前}-{日付}/`形式で整理。
|
|
397
|
+
|
|
398
|
+
### Q6: ナレッジベースは定期的に更新が必要ですか?
|
|
399
|
+
|
|
400
|
+
以下の場合は再初期化が必要です:
|
|
401
|
+
- プロジェクト構造が大幅に変更
|
|
402
|
+
- テクノロジースタックのアップグレードまたは変更
|
|
403
|
+
- ビジネスモジュールの追加/削除
|
|
404
|
+
|
|
405
|
+
---
|
|
406
|
+
|
|
407
|
+
## 7. クイックリファレンス
|
|
408
|
+
|
|
409
|
+
### エージェント起動クイックリファレンス表
|
|
410
|
+
|
|
411
|
+
| フェーズ | エージェント | 起動会話 |
|
|
412
|
+
|------|-------|----------|
|
|
413
|
+
| 診断 | Team Leader | `@speccrew-team-leader プロジェクトを診断` |
|
|
414
|
+
| 初期化 | Team Leader | `@speccrew-team-leader テクニカルナレッジベースを初期化` |
|
|
415
|
+
| 要件分析 | Product Manager | `@speccrew-product-manager 新しい要件があります:[説明]` |
|
|
416
|
+
| 機能設計 | Feature Designer | `@speccrew-feature-designer 機能設計を開始` |
|
|
417
|
+
| システム設計 | System Designer | `@speccrew-system-designer システム設計を開始` |
|
|
418
|
+
| 開発実装 | System Developer | `@speccrew-system-developer 開発を開始` |
|
|
419
|
+
| システムテスト | Test Manager | `@speccrew-test-manager テストを開始` |
|
|
420
|
+
|
|
421
|
+
### チェックポイントチェックリスト
|
|
422
|
+
|
|
423
|
+
| フェーズ | チェックポイント数 | 主要チェック項目 |
|
|
424
|
+
|------|-----------------|------------|
|
|
425
|
+
| 要件分析 | 1 | 要件の正確性、ビジネスルールの完全性、受け入れ基準の測定可能性 |
|
|
426
|
+
| 機能設計 | 1 | シナリオカバレッジ、インタラクションの明確さ、データの完全性、例外処理 |
|
|
427
|
+
| システム設計 | 2 | A: フレームワーク評価;B: 擬似コード構文、クロスエンドの一貫性、エラー処理 |
|
|
428
|
+
| 開発実装 | 1 | A: 環境準備完了、統合問題、コード規約 |
|
|
429
|
+
| システムテスト | 2 | A: ケースカバレッジ;B: テストコードの実行可能性 |
|
|
430
|
+
|
|
431
|
+
### 成果物パスクイックリファレンス
|
|
432
|
+
|
|
433
|
+
| フェーズ | 出力ディレクトリ | ファイル形式 |
|
|
434
|
+
|------|----------|----------|
|
|
435
|
+
| 要件分析 | `iterations/{iter}/01.product-requirement/` | `[name]-prd.md`, `[name]-bizs-modeling.md` |
|
|
436
|
+
| 機能設計 | `iterations/{iter}/02.feature-design/` | `[name]-feature-spec.md` |
|
|
437
|
+
| システム設計 | `iterations/{iter}/03.system-design/` | `DESIGN-OVERVIEW.md`, `{platform}/INDEX.md`, `{platform}/{module}-design.md` |
|
|
438
|
+
| 開発実装 | `iterations/{iter}/04.development/` | ソースコード + `delivery-report.md` |
|
|
439
|
+
| システムテスト | `iterations/{iter}/05.system-test/` | `cases/`, `code/`, `reports/`, `bugs/` |
|
|
440
|
+
| アーカイブ | `iteration-archives/{iter}-{date}/` | 完全なイテレーションコピー |
|
|
441
|
+
|
|
442
|
+
---
|
|
443
|
+
|
|
444
|
+
## 次のステップ
|
|
445
|
+
|
|
446
|
+
1. `speccrew init --ide qoder`を実行してプロジェクトを初期化
|
|
447
|
+
2. ステップ0を実行:プロジェクト診断とナレッジベース初期化
|
|
448
|
+
3. ワークフローに従ってフェーズごとに進め、仕様駆動の開発体験を楽しんでください!
|