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
package/README.ja.md
ADDED
|
@@ -0,0 +1,321 @@
|
|
|
1
|
+
# SpecCrew - AI駆動ソフトウェアエンジニアリングフレームワーク
|
|
2
|
+
|
|
3
|
+
<p align="center">
|
|
4
|
+
<a href="./README.md">简体中文</a> |
|
|
5
|
+
<a href="./README.zh-TW.md">繁體中文</a> |
|
|
6
|
+
<a href="./README.en.md">English</a> |
|
|
7
|
+
<a href="./README.ko.md">한국어</a> |
|
|
8
|
+
<a href="./README.de.md">Deutsch</a> |
|
|
9
|
+
<a href="./README.es.md">Español</a> |
|
|
10
|
+
<a href="./README.fr.md">Français</a> |
|
|
11
|
+
<a href="./README.it.md">Italiano</a> |
|
|
12
|
+
<a href="./README.da.md">Dansk</a> |
|
|
13
|
+
<a href="./README.ja.md">日本語</a> |
|
|
14
|
+
<a href="./README.pl.md">Polski</a> |
|
|
15
|
+
<a href="./README.ru.md">Русский</a> |
|
|
16
|
+
<a href="./README.bs.md">Bosanski</a> |
|
|
17
|
+
<a href="./README.ar.md">العربية</a> |
|
|
18
|
+
<a href="./README.no.md">Norsk</a> |
|
|
19
|
+
<a href="./README.pt-BR.md">Português (Brasil)</a> |
|
|
20
|
+
<a href="./README.th.md">ไทย</a> |
|
|
21
|
+
<a href="./README.tr.md">Türkçe</a> |
|
|
22
|
+
<a href="./README.uk.md">Українська</a> |
|
|
23
|
+
<a href="./README.bn.md">বাংলা</a> |
|
|
24
|
+
<a href="./README.el.md">Ελληνικά</a> |
|
|
25
|
+
<a href="./README.vi.md">Tiếng Việt</a>
|
|
26
|
+
</p>
|
|
27
|
+
|
|
28
|
+
<p align="center">
|
|
29
|
+
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/v/speccrew.svg" alt="npm version"></a>
|
|
30
|
+
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/dm/speccrew.svg" alt="npm downloads"></a>
|
|
31
|
+
<a href="https://github.com/charlesmu99/speccrew/blob/main/LICENSE"><img src="https://img.shields.io/npm/l/speccrew.svg" alt="license"></a>
|
|
32
|
+
</p>
|
|
33
|
+
|
|
34
|
+
> あらゆるソフトウェアプロジェクトに迅速なエンジニアリング実装を実現する仮想AI開発チーム
|
|
35
|
+
|
|
36
|
+
## SpecCrewとは?
|
|
37
|
+
|
|
38
|
+
SpecCrewは組み込み型の仮想AI開発チームフレームワークです。専門的なソフトウェアエンジニアリングワークフロー(PRD → 機能設計 → システム設計 → 開発 → テスト)を再利用可能なエージェントワークフローに変換し、開発チームが仕様駆動開発(SDD)を実現するのを支援します。特に既存プロジェクトに適しています。
|
|
39
|
+
|
|
40
|
+
エージェントとスキルを既存プロジェクトに統合することで、プロジェクトドキュメント体系と仮想ソフトウェアチームを迅速に初期化し、標準的なエンジニアリングワークフローに従って新機能の追加や変更を段階的に実装できます。
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## 解決する8つのコア問題
|
|
45
|
+
|
|
46
|
+
### 1. AIが既存プロジェクトドキュメントを無視する(知識の断絶)
|
|
47
|
+
**問題**: 既存のSDDやVibe Codingメソッドは、AIがリアルタイムでプロジェクトを要約することに依存しており、重要なコンテキストを見落としやすく、開発結果が期待から逸れる原因となります。
|
|
48
|
+
|
|
49
|
+
**解決**: `knowledge/`リポジトリがプロジェクトの「唯一の信頼できる情報源」として機能し、アーキテクチャ設計、機能モジュール、ビジネスプロセスを蓄積し、要件が源から逸れないことを保証します。
|
|
50
|
+
|
|
51
|
+
### 2. 要件ドキュメントから技術ドキュメントへの直接変換(内容の欠落)
|
|
52
|
+
**問題**: PRDから詳細設計へ直接進むと、要件の詳細を見落としやすく、実装された機能が要件から逸れる原因となります。
|
|
53
|
+
|
|
54
|
+
**解決**: **機能設計ドキュメント**フェーズを導入し、技術的詳細を考慮せず、要件の骨組みにのみ焦点を当てます:
|
|
55
|
+
- どのページとコンポーネントが含まれるか?
|
|
56
|
+
- ページ操作フロー
|
|
57
|
+
- バックエンド処理ロジック
|
|
58
|
+
- データ保存構造
|
|
59
|
+
|
|
60
|
+
開発段階では、特定のテックスタックに基づいて「肉を埋める」だけでよく、機能が「骨(要件)に近く」成長することを保証します。
|
|
61
|
+
|
|
62
|
+
### 3. エージェントの検索範囲が不確定(不確実性)
|
|
63
|
+
**問題**: 複雑なプロジェクトでは、AIの広範なコードとドキュメント検索が不確実な結果をもたらし、一貫性の保証が困難です。
|
|
64
|
+
|
|
65
|
+
**解決**: 各エージェントのニーズに基づいて設計された明確なドキュメントディレクトリ構造とテンプレートにより、**段階的な開示とオンデマンドロード**を実装し、決定論を保証します。
|
|
66
|
+
|
|
67
|
+
### 4. フェーズとタスクの欠落(プロセスの断絶)
|
|
68
|
+
**問題**: 完全なエンジニアリングプロセスカバレッジの欠如により、重要なステップを見落としやすく、品質の保証が困難です。
|
|
69
|
+
|
|
70
|
+
**解決**: ソフトウェアエンジニアリングライフサイクル全体をカバー:
|
|
71
|
+
```
|
|
72
|
+
PRD(要件)→ 機能設計 → API契約(コントラクト)
|
|
73
|
+
→ システム設計 → 開発 → テスト
|
|
74
|
+
```
|
|
75
|
+
- 各フェーズの出力は次のフェーズの入力
|
|
76
|
+
- 各ステップは進行前に人間の確認が必要
|
|
77
|
+
- すべてのエージェント実行にはtodoリストがあり、完了後に自己チェック
|
|
78
|
+
|
|
79
|
+
### 5. チームコラボレーション効率の低さ(知識のサイロ)
|
|
80
|
+
**問題**: AIプログラミング経験はチーム間で共有しにくく、繰り返しのミスにつながります。
|
|
81
|
+
|
|
82
|
+
**解決**: すべてのエージェント、スキル、関連ドキュメントがソースコードと共にバージョン管理:
|
|
83
|
+
- 一人の最適化をチームが共有
|
|
84
|
+
- 知識がコードベースに蓄積
|
|
85
|
+
- チームコラボレーション効率の向上
|
|
86
|
+
|
|
87
|
+
### 7. 単一エージェントのコンテキスト過多(パフォーマンスのボトルネック)
|
|
88
|
+
**問題**: 大規模で複雑なタスクは単一エージェントのコンテキストウィンドウを超え、理解のズレや出力品質の低下を引き起こします。
|
|
89
|
+
|
|
90
|
+
**解決**: **サブエージェント自動ディスパッチメカニズム**:
|
|
91
|
+
- 複雑なタスクが自動的に識別され、サブタスクに分割
|
|
92
|
+
- 各サブタスクは分離されたコンテキストを持つ独立したサブエージェントによって実行
|
|
93
|
+
- 親エージェントが調整・集約し、全体的な一貫性を保証
|
|
94
|
+
- 単一エージェントのコンテキスト拡張を回避し、出力品質を保証
|
|
95
|
+
|
|
96
|
+
### 8. 要件反復の混乱(管理の困難さ)
|
|
97
|
+
**問題**: 複数の要件が同じブランチに混在し、互いに影響し合い、追跡とロールバックが困難です。
|
|
98
|
+
|
|
99
|
+
**解決**: **各要件を独立したプロジェクトとして**:
|
|
100
|
+
- 各要件が独立した反復ディレクトリ`iterations/iXXX-[要件名]/`を作成
|
|
101
|
+
- 完全な分離:ドキュメント、設計、コード、テストが独立して管理
|
|
102
|
+
- 迅速な反復:小粒度の納品、迅速な検証、迅速なデプロイ
|
|
103
|
+
- 柔軟なアーカイブ:完了後、`archive/`にアーカイブし、明確な履歴追跡
|
|
104
|
+
|
|
105
|
+
### 6. ドキュメント更新の遅れ(知識の劣化)
|
|
106
|
+
**問題**: プロジェクトが進化するにつれてドキュメントが古くなり、AIが誤った情報で作業します。
|
|
107
|
+
|
|
108
|
+
**解決**: エージェントは自動ドキュメント更新機能を持ち、プロジェクトの変更をリアルタイムで同期し、ナレッジベースの正確性を維持します。
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## コアワークフロー
|
|
113
|
+
|
|
114
|
+
```mermaid
|
|
115
|
+
graph LR
|
|
116
|
+
A[PRD<br/>要件ドキュメント] --> B[機能設計<br/>Feature Design]
|
|
117
|
+
B --> C[API契約<br/>インターフェース契約]
|
|
118
|
+
C --> D[システム設計<br/>System Design]
|
|
119
|
+
D --> E[開発<br/>Dev]
|
|
120
|
+
E --> F[システムテスト<br/>System Test]
|
|
121
|
+
F --> G[アーカイブ<br/>Archive]
|
|
122
|
+
|
|
123
|
+
H[ナレッジ<br/>Knowledge] -.-> A
|
|
124
|
+
H -.-> B
|
|
125
|
+
H -.-> D
|
|
126
|
+
H -.-> E
|
|
127
|
+
|
|
128
|
+
E -.-> H
|
|
129
|
+
F -.-> H
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
### 各フェーズの説明
|
|
133
|
+
|
|
134
|
+
| フェーズ | エージェント | 入力 | 出力 | 人間の確認 |
|
|
135
|
+
|----------|-------------|------|------|------------|
|
|
136
|
+
| PRD | PM | ユーザー要件 | 製品要件ドキュメント | ✅ 必須 |
|
|
137
|
+
| 機能設計 | 機能デザイナー | PRD | 機能設計ドキュメント + API契約 | ✅ 必須 |
|
|
138
|
+
| システム設計 | システムデザイナー | 機能仕様 | フロントエンド/バックエンド設計ドキュメント | ✅ 必須 |
|
|
139
|
+
| 開発 | 開発者 | 設計 | コード + タスク記録 | ✅ 必須 |
|
|
140
|
+
| システムテスト | テストマネージャー | 開発成果物 + 機能仕様 | テストケース + テストコード + テストレポート + バグレポート | ✅ 必須 |
|
|
141
|
+
|
|
142
|
+
---
|
|
143
|
+
|
|
144
|
+
## 既存ソリューションとの比較
|
|
145
|
+
|
|
146
|
+
| 次元 | Vibe Coding | Ralphループ | **SpecCrew** |
|
|
147
|
+
|------|-------------|-------------|-------------|
|
|
148
|
+
| ドキュメント依存 | 既存ドキュメントを無視 | AGENTS.mdに依存 | **構造化ナレッジベース** |
|
|
149
|
+
| 要件転送 | 直接コーディング | PRD → コード | **PRD → 機能設計 → システム設計 → コード** |
|
|
150
|
+
| 人間の介入 | 最小 | 起動時 | **各フェーズで** |
|
|
151
|
+
| プロセス完全性 | 弱い | 中程度 | **完全なエンジニアリングワークフロー** |
|
|
152
|
+
| チームコラボレーション | 共有困難 | 個人効率 | **チーム知識共有** |
|
|
153
|
+
| コンテキスト管理 | 単一インスタンス | 単一インスタンスループ | **サブエージェント自動ディスパッチ** |
|
|
154
|
+
| 反復管理 | 混在 | タスクリスト | **要件をプロジェクトとして、独立した反復** |
|
|
155
|
+
| 決定性 | なし | 中程度 | **高い(段階的開示)** |
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
## クイックスタート
|
|
160
|
+
|
|
161
|
+
### 前提条件
|
|
162
|
+
|
|
163
|
+
- Node.js >= 16.0.0
|
|
164
|
+
- サポートされるIDE:Qoder(デフォルト)、Cursor、Claude Code
|
|
165
|
+
|
|
166
|
+
> **注意**: CursorとClaude Code用のアダプタは実際のIDE環境でテストされていません(コードレベルで実装されE2Eテストで検証済みですが、実際のCursor/Claude Codeではまだテストされていません)。
|
|
167
|
+
|
|
168
|
+
### 1. SpecCrewのインストール
|
|
169
|
+
|
|
170
|
+
```bash
|
|
171
|
+
npm install -g speccrew
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
### 2. プロジェクトの初期化
|
|
175
|
+
|
|
176
|
+
プロジェクトのルートディレクトリに移動し、初期化コマンドを実行:
|
|
177
|
+
|
|
178
|
+
```bash
|
|
179
|
+
cd /path/to/your-project
|
|
180
|
+
|
|
181
|
+
# デフォルトでQoderを使用
|
|
182
|
+
speccrew init
|
|
183
|
+
|
|
184
|
+
# またはIDEを指定
|
|
185
|
+
speccrew init --ide qoder
|
|
186
|
+
speccrew init --ide cursor
|
|
187
|
+
speccrew init --ide claude
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
初期化後、プロジェクトに以下が生成されます:
|
|
191
|
+
- `.qoder/agents/` / `.cursor/agents/` / `.claude/agents/` — 7つのエージェント役割定義
|
|
192
|
+
- `.qoder/skills/` / `.cursor/skills/` / `.claude/skills/` — 38のスキルワークフロー
|
|
193
|
+
- `speccrew-workspace/` — ワークスペース(反復ディレクトリ、ナレッジベース、ドキュメントテンプレート)
|
|
194
|
+
- `.speccrewrc` — SpecCrew設定ファイル
|
|
195
|
+
|
|
196
|
+
後で特定のIDEのエージェントとスキルを更新するには:
|
|
197
|
+
|
|
198
|
+
```bash
|
|
199
|
+
speccrew update --ide cursor
|
|
200
|
+
speccrew update --ide claude
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
### 3. 開発ワークフローの開始
|
|
204
|
+
|
|
205
|
+
標準的なエンジニアリングワークフローに従って段階的に進行:
|
|
206
|
+
|
|
207
|
+
1. **PRD**: プロダクトマネージャーエージェントが要件を分析し、製品要件ドキュメントを生成
|
|
208
|
+
2. **機能設計**: 機能デザイナーエージェントが機能設計ドキュメント + API契約を生成
|
|
209
|
+
3. **システム設計**: システムデザイナーエージェントがプラットフォーム別にシステム設計ドキュメントを生成(フロントエンド/バックエンド/モバイル/デスクトップ)
|
|
210
|
+
4. **開発**: システム開発者エージェントがプラットフォーム別に並行開発を実装
|
|
211
|
+
5. **システムテスト**: テストマネージャーエージェントが3フェーズのテストを調整(ケース設計 → コード生成 → 実行レポート)
|
|
212
|
+
6. **アーカイブ**: 反復をアーカイブ
|
|
213
|
+
|
|
214
|
+
> 各フェーズの成果物は次のフェーズに進む前に人間の確認が必要です。
|
|
215
|
+
|
|
216
|
+
### 4. その他のCLIコマンド
|
|
217
|
+
|
|
218
|
+
```bash
|
|
219
|
+
speccrew list # インストール済みのエージェントとスキルを一覧表示
|
|
220
|
+
speccrew doctor # 環境とインストール状態を診断
|
|
221
|
+
speccrew update # エージェントとスキルを最新版に更新
|
|
222
|
+
speccrew uninstall # SpecCrewをアンインストール(--allでワークスペースも削除)
|
|
223
|
+
```
|
|
224
|
+
|
|
225
|
+
📖 **詳細ガイド**: インストール後、[スタートガイド](docs/GETTING-STARTED.ja.md)で完全なワークフローとエージェント会話ガイドを確認してください。
|
|
226
|
+
|
|
227
|
+
---
|
|
228
|
+
|
|
229
|
+
## ディレクトリ構造
|
|
230
|
+
|
|
231
|
+
```
|
|
232
|
+
your-project/
|
|
233
|
+
├── .qoder/ # IDE設定ディレクトリ(Qoder例)
|
|
234
|
+
│ ├── agents/ # 7つのロールエージェント
|
|
235
|
+
│ │ ├── speccrew-team-leader.md # チームリーダー:全体スケジューリングと反復管理
|
|
236
|
+
│ │ ├── speccrew-product-manager.md # プロダクトマネージャー:要件分析とPRD
|
|
237
|
+
│ │ ├── speccrew-feature-designer.md # 機能デザイナー:機能設計 + API契約
|
|
238
|
+
│ │ ├── speccrew-system-designer.md # システムデザイナー:プラットフォーム別システム設計生成
|
|
239
|
+
│ │ ├── speccrew-system-developer.md # システム開発者:プラットフォーム別並行開発
|
|
240
|
+
│ │ ├── speccrew-test-manager.md # テストマネージャー:3フェーズテスト調整
|
|
241
|
+
│ │ └── speccrew-task-worker.md # タスクワーカー:並行サブタスク実行
|
|
242
|
+
│ └── skills/ # 38のスキル(機能別グループ化)
|
|
243
|
+
│ ├── speccrew-pm-*/ # プロダクト管理(要件分析、評価)
|
|
244
|
+
│ ├── speccrew-fd-*/ # 機能設計(機能設計、API契約)
|
|
245
|
+
│ ├── speccrew-sd-*/ # システム設計(フロントエンド/バックエンド/モバイル/デスクトップ)
|
|
246
|
+
│ ├── speccrew-dev-*/ # 開発(フロントエンド/バックエンド/モバイル/デスクトップ)
|
|
247
|
+
│ ├── speccrew-test-*/ # テスト(ケース設計/コード生成/実行レポート)
|
|
248
|
+
│ ├── speccrew-knowledge-bizs-*/ # ビジネス知識(API分析/UI分析/モジュール分類等)
|
|
249
|
+
│ ├── speccrew-knowledge-techs-*/ # 技術知識(テックスタック生成/規約/インデックス等)
|
|
250
|
+
│ ├── speccrew-knowledge-graph-*/ # ナレッジグラフ(読み取り/書き込み/クエリ)
|
|
251
|
+
│ └── speccrew-*/ # ユーティリティ(診断/タイムスタンプ/ワークフロー等)
|
|
252
|
+
│
|
|
253
|
+
└── speccrew-workspace/ # ワークスペース(初期化時に生成)
|
|
254
|
+
├── docs/ # 管理ドキュメント
|
|
255
|
+
│ ├── configs/ # 設定ファイル(プラットフォームマッピング、テックスタックマッピング等)
|
|
256
|
+
│ ├── rules/ # ルール設定
|
|
257
|
+
│ └── solutions/ # ソリューションドキュメント
|
|
258
|
+
│
|
|
259
|
+
├── iterations/ # 反復プロジェクト(動的生成)
|
|
260
|
+
│ └── {番号}-{タイプ}-{名前}/
|
|
261
|
+
│ ├── 00.docs/ # 元の要件
|
|
262
|
+
│ ├── 01.product-requirement/ # 製品要件
|
|
263
|
+
│ ├── 02.feature-design/ # 機能設計
|
|
264
|
+
│ ├── 03.system-design/ # システム設計
|
|
265
|
+
│ ├── 04.development/ # 開発フェーズ
|
|
266
|
+
│ ├── 05.system-test/ # システムテスト
|
|
267
|
+
│ └── 06.delivery/ # 納品フェーズ
|
|
268
|
+
│
|
|
269
|
+
├── iteration-archives/ # 反復アーカイブ
|
|
270
|
+
│
|
|
271
|
+
└── knowledges/ # ナレッジベース
|
|
272
|
+
├── base/ # ベース/メタデータ
|
|
273
|
+
│ ├── diagnosis-reports/ # 診断レポート
|
|
274
|
+
│ ├── sync-state/ # 同期状態
|
|
275
|
+
│ └── tech-debts/ # 技術的負債
|
|
276
|
+
├── bizs/ # ビジネス知識
|
|
277
|
+
│ └── {platform-type}/{module-name}/
|
|
278
|
+
└── techs/ # 技術知識
|
|
279
|
+
└── {platform-id}/
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
---
|
|
283
|
+
|
|
284
|
+
## コア設計原則
|
|
285
|
+
|
|
286
|
+
1. **仕様駆動**: 仕様を先に書き、そこからコードを「成長」させる
|
|
287
|
+
2. **段階的開示**: エージェントは最小のエントリーポイントから開始し、オンデマンドで情報をロード
|
|
288
|
+
3. **人間の確認**: 各フェーズの出力は人間の確認を必要とし、AIの逸脱を防ぐ
|
|
289
|
+
4. **コンテキスト分離**: 大きなタスクを小さく、コンテキスト分離されたサブタスクに分割
|
|
290
|
+
5. **サブエージェントコラボレーション**: 複雑なタスクは自動的にサブエージェントをディスパッチし、単一エージェントのコンテキスト拡張を回避
|
|
291
|
+
6. **迅速な反復**: 各要件を独立したプロジェクトとして迅速な納品と検証
|
|
292
|
+
7. **知識共有**: すべての設定をソースコードと共にバージョン管理
|
|
293
|
+
|
|
294
|
+
---
|
|
295
|
+
|
|
296
|
+
## 適用シナリオ
|
|
297
|
+
|
|
298
|
+
### ✅ 推奨
|
|
299
|
+
- 標準化されたワークフローが必要な中規模から大規模プロジェクト
|
|
300
|
+
- チームコラボレーションのソフトウェア開発
|
|
301
|
+
- レガシープロジェクトのエンジニアリング変換
|
|
302
|
+
- 長期メンテナンスが必要な製品
|
|
303
|
+
|
|
304
|
+
### ❌ 不向き
|
|
305
|
+
- 個人的な迅速なプロトタイプ検証
|
|
306
|
+
- 要件が極めて不確実な探索的プロジェクト
|
|
307
|
+
- 一回限りのスクリプトやツール
|
|
308
|
+
|
|
309
|
+
---
|
|
310
|
+
|
|
311
|
+
## 詳細情報
|
|
312
|
+
|
|
313
|
+
- **エージェント知識マップ**: [speccrew-workspace/docs/agent-knowledge-map.md](./speccrew-workspace/docs/agent-knowledge-map.md)
|
|
314
|
+
- **npm**: https://www.npmjs.com/package/speccrew
|
|
315
|
+
- **GitHub**: https://github.com/charlesmu99/speccrew
|
|
316
|
+
- **Gitee**: https://gitee.com/amutek/speccrew
|
|
317
|
+
- **Qoder IDE**: https://qoder.com/
|
|
318
|
+
|
|
319
|
+
---
|
|
320
|
+
|
|
321
|
+
> **SpecCrewは開発者を置き換えるものではなく、退屈な部分を自動化し、チームがより価値のある作業に集中できるようにします。**
|
package/README.ko.md
ADDED
|
@@ -0,0 +1,321 @@
|
|
|
1
|
+
# SpecCrew - AI 기반 소프트웨어 엔지니어링 프레임워크
|
|
2
|
+
|
|
3
|
+
<p align="center">
|
|
4
|
+
<a href="./README.md">简体中文</a> |
|
|
5
|
+
<a href="./README.zh-TW.md">繁體中文</a> |
|
|
6
|
+
<a href="./README.en.md">English</a> |
|
|
7
|
+
<a href="./README.ko.md">한국어</a> |
|
|
8
|
+
<a href="./README.de.md">Deutsch</a> |
|
|
9
|
+
<a href="./README.es.md">Español</a> |
|
|
10
|
+
<a href="./README.fr.md">Français</a> |
|
|
11
|
+
<a href="./README.it.md">Italiano</a> |
|
|
12
|
+
<a href="./README.da.md">Dansk</a> |
|
|
13
|
+
<a href="./README.ja.md">日本語</a> |
|
|
14
|
+
<a href="./README.pl.md">Polski</a> |
|
|
15
|
+
<a href="./README.ru.md">Русский</a> |
|
|
16
|
+
<a href="./README.bs.md">Bosanski</a> |
|
|
17
|
+
<a href="./README.ar.md">العربية</a> |
|
|
18
|
+
<a href="./README.no.md">Norsk</a> |
|
|
19
|
+
<a href="./README.pt-BR.md">Português (Brasil)</a> |
|
|
20
|
+
<a href="./README.th.md">ไทย</a> |
|
|
21
|
+
<a href="./README.tr.md">Türkçe</a> |
|
|
22
|
+
<a href="./README.uk.md">Українська</a> |
|
|
23
|
+
<a href="./README.bn.md">বাংলা</a> |
|
|
24
|
+
<a href="./README.el.md">Ελληνικά</a> |
|
|
25
|
+
<a href="./README.vi.md">Tiếng Việt</a>
|
|
26
|
+
</p>
|
|
27
|
+
|
|
28
|
+
<p align="center">
|
|
29
|
+
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/v/speccrew.svg" alt="npm version"></a>
|
|
30
|
+
<a href="https://www.npmjs.com/package/speccrew"><img src="https://img.shields.io/npm/dm/speccrew.svg" alt="npm downloads"></a>
|
|
31
|
+
<a href="https://github.com/charlesmu99/speccrew/blob/main/LICENSE"><img src="https://img.shields.io/npm/l/speccrew.svg" alt="license"></a>
|
|
32
|
+
</p>
|
|
33
|
+
|
|
34
|
+
> 모든 소프트웨어 프로젝트에 빠른 엔지니어링 구현을 가능하게 하는 가상 AI 개발 팀
|
|
35
|
+
|
|
36
|
+
## SpecCrew란 무엇인가요?
|
|
37
|
+
|
|
38
|
+
SpecCrew는 임베디드 가상 AI 개발 팀 프레임워크입니다. 전문 소프트웨어 엔지니어링 워크플로우(PRD → Feature Design → System Design → Dev → Test)를 재사용 가능한 Agent 워크플로우로 변환하여, 개발 팀이 명세 기반 개발(SDD)을 달성할 수 있도록 도와주며, 특히 기존 프로젝트에 적합합니다.
|
|
39
|
+
|
|
40
|
+
Agent와 Skill을 기존 프로젝트에 통합함으로써 프로젝트 문서 시스템과 가상 소프트웨어 팀을 빠르게 초기화하고, 표준 엔지니어링 프로세스에 따라 기능 추가 및 수정을 단계별로 구현할 수 있습니다.
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## 8가지 핵심 문제 해결
|
|
45
|
+
|
|
46
|
+
### 1. AI가 기존 프로젝트 문서를 무시함 (지식 단절)
|
|
47
|
+
**문제**: 기존 SDD 또는 Vibe Coding 방식은 AI가 실시간으로 프로젝트를 요약하는 데 의존하여, 중요한 컨텍스트를 쉽게 놓치고 개발 결과가 기대에서 벗어날 수 있습니다.
|
|
48
|
+
|
|
49
|
+
**해결**: `knowledge/` 저장소가 프로젝트의 "단일 진실 공급원" 역할을 하여, 아키텍처 설계, 기능 모듈, 비즈니스 프로세스를 축적하고 요구사항이 원천에서 벗어나지 않도록 보장합니다.
|
|
50
|
+
|
|
51
|
+
### 2. PRD에서 기술 문서로 직접 변환 (내용 누락)
|
|
52
|
+
**문제**: PRD에서 상세 설계로 바로 건너뛰면 요구사항 세부 사항을 쉽게 놓치게 되어, 구현된 기능이 요구사항에서 벗어날 수 있습니다.
|
|
53
|
+
|
|
54
|
+
**해결**: **Feature Design 문서** 단계를 도입하여 기술적 세부사항 없이 요구사항 골격에만 집중:
|
|
55
|
+
- 어떤 페이지와 컴포넌트가 포함되는가?
|
|
56
|
+
- 페이지 운영 흐름
|
|
57
|
+
- 백엔드 처리 로직
|
|
58
|
+
- 데이터 저장 구조
|
|
59
|
+
|
|
60
|
+
개발 단계에서는 특정 기술 스택을 기반으로 "내용을 채우기만" 하면 되어, 기능이 "뼈대(요구사항)에 밀착"하여 성장하도록 보장합니다.
|
|
61
|
+
|
|
62
|
+
### 3. 불확실한 Agent 검색 범위 (불확실성)
|
|
63
|
+
**문제**: 복잡한 프로젝트에서 AI의 광범위한 코드 및 문서 검색은 불확실한 결과를 초래하여 일관성을 보장하기 어렵습니다.
|
|
64
|
+
|
|
65
|
+
**해결**: 각 Agent의 필요에 따라 설계된 명확한 문서 디렉토리 구조와 템플릿으로, **점진적 공개와 주문형 로딩**을 구현하여 결정론을 보장합니다.
|
|
66
|
+
|
|
67
|
+
### 4. 단계 누락 및 작업 누락 (프로세스 붕괴)
|
|
68
|
+
**문제**: 완전한 엔지니어링 프로세스 커버리지가 부족하여 중요한 단계를 쉽게 놓치고 품질을 보장하기 어렵습니다.
|
|
69
|
+
|
|
70
|
+
**해결**: 전체 소프트웨어 엔지니어링 수명주기를 커버:
|
|
71
|
+
```
|
|
72
|
+
PRD (요구사항) → Feature Design (기능 설계) → API Contract (계약)
|
|
73
|
+
→ System Design (시스템 설계) → Dev (개발) → Test (테스트)
|
|
74
|
+
```
|
|
75
|
+
- 각 단계의 산출물은 다음 단계의 입력
|
|
76
|
+
- 각 단계는 진행 전 사용자 확인 필요
|
|
77
|
+
- 모든 Agent 실행에 todo 목록이 있으며 완료 후 자체 점검
|
|
78
|
+
|
|
79
|
+
### 5. 낮은 팀 협업 효율성 (지식 사일로)
|
|
80
|
+
**문제**: AI 프로그래밍 경험을 팀 간에 공유하기 어려워 반복된 실수가 발생합니다.
|
|
81
|
+
|
|
82
|
+
**해결**: 모든 Agent, Skill 및 관련 문서가 소스 코드와 함께 버전 관리됨:
|
|
83
|
+
- 한 사람의 최적화를 팀이 공유
|
|
84
|
+
- 지식이 코드베이스에 축적
|
|
85
|
+
- 팀 협업 효율성 향상
|
|
86
|
+
|
|
87
|
+
### 7. 단일 Agent 컨텍스트 과다 (성능 병목)
|
|
88
|
+
**문제**: 대규모 복잡한 작업은 단일 Agent 컨텍스트 윈도우를 초과하여 이해 편차와 출력 품질 저하를 초래합니다.
|
|
89
|
+
|
|
90
|
+
**해결**: **하위 Agent 자동 디스패치 메커니즘**:
|
|
91
|
+
- 복잡한 작업이 자동으로 식별되어 하위 작업으로 분할
|
|
92
|
+
- 각 하위 작업은 격리된 컨텍스트로 독립적인 하위 Agent가 실행
|
|
93
|
+
- 상위 Agent가 조정 및 집계하여 전체 일관성 보장
|
|
94
|
+
- 단일 Agent 컨텍스트 확장을 방지하여 출력 품질 보장
|
|
95
|
+
|
|
96
|
+
### 8. 요구사항 반복 혼란 (관리 어려움)
|
|
97
|
+
**문제**: 여러 요구사항이 동일한 브랜치에 섞여 서로 영향을 미치며 추적 및 롤백이 어렵습니다.
|
|
98
|
+
|
|
99
|
+
**해결**: **각 요구사항을 독립적인 프로젝트로**:
|
|
100
|
+
- 각 요구사항이 독립적인 반복 디렉토리 생성 `iterations/iXXX-[요구사항-이름]/`
|
|
101
|
+
- 완전한 격리: 문서, 설계, 코드, 테스트가 독립적으로 관리
|
|
102
|
+
- 빠른 반복: 작은 단위 전달, 빠른 검증, 빠른 배포
|
|
103
|
+
- 유연한 보관: 완료 후 `archive/`에 보관하며 명확한 이력 추적 가능
|
|
104
|
+
|
|
105
|
+
### 6. 문서 업데이트 지연 (지식 부패)
|
|
106
|
+
**문제**: 프로젝트가 발전함에 따라 문서가 구식이 되어 AI가 잘못된 정보로 작업합니다.
|
|
107
|
+
|
|
108
|
+
**해결**: Agent가 자동 문서 업데이트 기능을 갖추어 프로젝트 변경 사항을 실시간으로 동기화하고 지식 기반의 정확성을 유지합니다.
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## 핵심 워크플로우
|
|
113
|
+
|
|
114
|
+
```mermaid
|
|
115
|
+
graph LR
|
|
116
|
+
A[PRD<br/>요구사항 문서] --> B[Feature Design<br/>기능 설계]
|
|
117
|
+
B --> C[API Contract<br/>인터페이스 계약]
|
|
118
|
+
C --> D[System Design<br/>시스템 설계]
|
|
119
|
+
D --> E[Dev<br/>구현]
|
|
120
|
+
E --> F[System Test<br/>테스트]
|
|
121
|
+
F --> G[Archive<br/>보관]
|
|
122
|
+
|
|
123
|
+
H[Knowledge<br/>저장소] -.-> A
|
|
124
|
+
H -.-> B
|
|
125
|
+
H -.-> D
|
|
126
|
+
H -.-> E
|
|
127
|
+
|
|
128
|
+
E -.-> H
|
|
129
|
+
F -.-> H
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
### 각 단계 설명
|
|
133
|
+
|
|
134
|
+
| 단계 | Agent | 입력 | 출력 | 사용자 확인 |
|
|
135
|
+
|------|-------|------|------|-------------|
|
|
136
|
+
| PRD | PM | 사용자 요구사항 | 제품 요구사항 문서 | ✅ 필수 |
|
|
137
|
+
| Feature Design | Feature Designer | PRD | 기능 설계 문서 + API 계약 | ✅ 필수 |
|
|
138
|
+
| System Design | System Designer | Feature Spec | 프론트엔드/백엔드 설계 문서 | ✅ 필수 |
|
|
139
|
+
| Dev | Dev | Design | 코드 + 작업 기록 | ✅ 필수 |
|
|
140
|
+
| System Test | Test Manager | Dev 산출물 + Feature Spec | 테스트 케이스 + 테스트 코드 + 테스트 보고서 + 버그 보고서 | ✅ 필수 |
|
|
141
|
+
|
|
142
|
+
---
|
|
143
|
+
|
|
144
|
+
## 기존 솔루션과의 비교
|
|
145
|
+
|
|
146
|
+
| 차원 | Vibe Coding | Ralph Loop | **SpecCrew** |
|
|
147
|
+
|------|-------------|------------|-------------|
|
|
148
|
+
| 문서 의존성 | 기존 문서 무시 | AGENTS.md 의존 | **구조화된 지식 기반** |
|
|
149
|
+
| 요구사항 전달 | 직접 코딩 | PRD → 코드 | **PRD → Feature Design → System Design → 코드** |
|
|
150
|
+
| 사용자 개입 | 최소화 | 시작 시 | **모든 단계에서** |
|
|
151
|
+
| 프로세스 완전성 | 약함 | 중간 | **완전한 엔지니어링 워크플로우** |
|
|
152
|
+
| 팀 협업 | 공유 어려움 | 개인 효율성 | **팀 지식 공유** |
|
|
153
|
+
| 컨텍스트 관리 | 단일 인스턴스 | 단일 인스턴스 루프 | **하위 Agent 자동 디스패치** |
|
|
154
|
+
| 반복 관리 | 혼합 | 작업 목록 | **요구사항을 프로젝트로, 독립적인 반복** |
|
|
155
|
+
| 결정론 | 낮음 | 중간 | **높음 (점진적 공개)** |
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
## 빠른 시작
|
|
160
|
+
|
|
161
|
+
### 전제 조건
|
|
162
|
+
|
|
163
|
+
- Node.js >= 16.0.0
|
|
164
|
+
- 지원되는 IDE: Qoder (기본값), Cursor, Claude Code
|
|
165
|
+
|
|
166
|
+
> **참고**: Cursor와 Claude Code용 어댑터는 실제 IDE 환경에서 테스트되지 않았습니다 (코드 수준에서 구현되어 E2E 테스트를 통과했지만 실제 Cursor/Claude Code에서는 아직 테스트되지 않음).
|
|
167
|
+
|
|
168
|
+
### 1. SpecCrew 설치
|
|
169
|
+
|
|
170
|
+
```bash
|
|
171
|
+
npm install -g speccrew
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
### 2. 프로젝트 초기화
|
|
175
|
+
|
|
176
|
+
프로젝트 루트 디렉토리로 이동하여 초기화 명령을 실행:
|
|
177
|
+
|
|
178
|
+
```bash
|
|
179
|
+
cd /path/to/your-project
|
|
180
|
+
|
|
181
|
+
# 기본적으로 Qoder 사용
|
|
182
|
+
speccrew init
|
|
183
|
+
|
|
184
|
+
# 또는 IDE 지정
|
|
185
|
+
speccrew init --ide qoder
|
|
186
|
+
speccrew init --ide cursor
|
|
187
|
+
speccrew init --ide claude
|
|
188
|
+
```
|
|
189
|
+
|
|
190
|
+
초기화 후 프로젝트에 다음이 생성됩니다:
|
|
191
|
+
- `.qoder/agents/` / `.cursor/agents/` / `.claude/agents/` — 7개 Agent 역할 정의
|
|
192
|
+
- `.qoder/skills/` / `.cursor/skills/` / `.claude/skills/` — 38개 Skill 워크플로우
|
|
193
|
+
- `speccrew-workspace/` — 작업 공간 (반복 디렉토리, 지식 기반, 문서 템플릿)
|
|
194
|
+
- `.speccrewrc` — SpecCrew 구성 파일
|
|
195
|
+
|
|
196
|
+
나중에 특정 IDE의 Agent와 Skill을 업데이트하려면:
|
|
197
|
+
|
|
198
|
+
```bash
|
|
199
|
+
speccrew update --ide cursor
|
|
200
|
+
speccrew update --ide claude
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
### 3. 개발 워크플로우 시작
|
|
204
|
+
|
|
205
|
+
표준 엔지니어링 워크플로우에 따라 단계별로 진행:
|
|
206
|
+
|
|
207
|
+
1. **PRD**: 제품 관리자 Agent가 요구사항을 분석하고 제품 요구사항 문서 생성
|
|
208
|
+
2. **Feature Design**: 기능 설계자 Agent가 기능 설계 문서 + API 계약 생성
|
|
209
|
+
3. **System Design**: 시스템 설계자 Agent가 플랫폼별(프론트엔드/백엔드/모바일/데스크톱) 시스템 설계 문서 생성
|
|
210
|
+
4. **Dev**: 시스템 개발자 Agent가 플랫폼별 병렬 개발 구현
|
|
211
|
+
5. **System Test**: 테스트 관리자 Agent가 3단계 테스트 조정 (케이스 설계 → 코드 생성 → 실행 보고서)
|
|
212
|
+
6. **Archive**: 반복 보관
|
|
213
|
+
|
|
214
|
+
> 각 단계의 산출물은 다음 단계로 진행하기 전 사용자 확인이 필요합니다.
|
|
215
|
+
|
|
216
|
+
### 4. 기타 CLI 명령
|
|
217
|
+
|
|
218
|
+
```bash
|
|
219
|
+
speccrew list # 설치된 agent와 skill 나열
|
|
220
|
+
speccrew doctor # 환경 및 설치 상태 진단
|
|
221
|
+
speccrew update # agent와 skill을 최신 버전으로 업데이트
|
|
222
|
+
speccrew uninstall # SpecCrew 제거 (--all은 작업 공간도 삭제)
|
|
223
|
+
```
|
|
224
|
+
|
|
225
|
+
📖 **상세 가이드**: 설치 후 [시작 가이드](docs/GETTING-STARTED.ko.md)에서 전체 워크플로우와 Agent 대화 가이드를 확인하세요.
|
|
226
|
+
|
|
227
|
+
---
|
|
228
|
+
|
|
229
|
+
## 디렉토리 구조
|
|
230
|
+
|
|
231
|
+
```
|
|
232
|
+
your-project/
|
|
233
|
+
├── .qoder/ # IDE 구성 디렉토리 (Qoder 예시)
|
|
234
|
+
│ ├── agents/ # 7개 역할 Agent
|
|
235
|
+
│ │ ├── speccrew-team-leader.md # 팀 리더: 전역 스케줄링 및 반복 관리
|
|
236
|
+
│ │ ├── speccrew-product-manager.md # 제품 관리자: 요구사항 분석 및 PRD
|
|
237
|
+
│ │ ├── speccrew-feature-designer.md # 기능 설계자: Feature Design + API 계약
|
|
238
|
+
│ │ ├── speccrew-system-designer.md # 시스템 설계자: 플랫폼별 시스템 설계 생성
|
|
239
|
+
│ │ ├── speccrew-system-developer.md # 시스템 개발자: 플랫폼별 병렬 개발
|
|
240
|
+
│ │ ├── speccrew-test-manager.md # 테스트 관리자: 3단계 테스트 조정
|
|
241
|
+
│ │ └── speccrew-task-worker.md # 작업자: 병렬 하위 작업 실행
|
|
242
|
+
│ └── skills/ # 38개 Skill (기능별 그룹화)
|
|
243
|
+
│ ├── speccrew-pm-*/ # 제품 관리 (요구사항 분석, 평가)
|
|
244
|
+
│ ├── speccrew-fd-*/ # 기능 설계 (Feature Design, API 계약)
|
|
245
|
+
│ ├── speccrew-sd-*/ # 시스템 설계 (프론트엔드/백엔드/모바일/데스크톱)
|
|
246
|
+
│ ├── speccrew-dev-*/ # 개발 (프론트엔드/백엔드/모바일/데스크톱)
|
|
247
|
+
│ ├── speccrew-test-*/ # 테스트 (케이스 설계/코드 생성/실행 보고서)
|
|
248
|
+
│ ├── speccrew-knowledge-bizs-*/ # 비즈니스 지식 (API 분석/UI 분석/모듈 분류 등)
|
|
249
|
+
│ ├── speccrew-knowledge-techs-*/ # 기술 지식 (기술 스택 생성/규약/인덱스 등)
|
|
250
|
+
│ ├── speccrew-knowledge-graph-*/ # 지식 그래프 (읽기/쓰기/쿼리)
|
|
251
|
+
│ └── speccrew-*/ # 유틸리티 (진단/타임스탬프/워크플로우 등)
|
|
252
|
+
│
|
|
253
|
+
└── speccrew-workspace/ # 작업 공간 (초기화 시 생성)
|
|
254
|
+
├── docs/ # 관리 문서
|
|
255
|
+
│ ├── configs/ # 구성 파일 (플랫폼 매핑, 기술 스택 매핑 등)
|
|
256
|
+
│ ├── rules/ # 규칙 구성
|
|
257
|
+
│ └── solutions/ # 솔루션 문서
|
|
258
|
+
│
|
|
259
|
+
├── iterations/ # 반복 프로젝트 (동적 생성)
|
|
260
|
+
│ └── {번호}-{유형}-{이름}/
|
|
261
|
+
│ ├── 00.docs/ # 원본 요구사항
|
|
262
|
+
│ ├── 01.product-requirement/ # 제품 요구사항
|
|
263
|
+
│ ├── 02.feature-design/ # 기능 설계
|
|
264
|
+
│ ├── 03.system-design/ # 시스템 설계
|
|
265
|
+
│ ├── 04.development/ # 개발 단계
|
|
266
|
+
│ ├── 05.system-test/ # 시스템 테스트
|
|
267
|
+
│ └── 06.delivery/ # 전달 단계
|
|
268
|
+
│
|
|
269
|
+
├── iteration-archives/ # 반복 보관
|
|
270
|
+
│
|
|
271
|
+
└── knowledges/ # 지식 기반
|
|
272
|
+
├── base/ # 기본/메타데이터
|
|
273
|
+
│ ├── diagnosis-reports/ # 진단 보고서
|
|
274
|
+
│ ├── sync-state/ # 동기화 상태
|
|
275
|
+
│ └── tech-debts/ # 기술 부채
|
|
276
|
+
├── bizs/ # 비즈니스 지식
|
|
277
|
+
│ └── {platform-type}/{module-name}/
|
|
278
|
+
└── techs/ # 기술 지식
|
|
279
|
+
└── {platform-id}/
|
|
280
|
+
```
|
|
281
|
+
|
|
282
|
+
---
|
|
283
|
+
|
|
284
|
+
## 핵심 설계 원칙
|
|
285
|
+
|
|
286
|
+
1. **명세 기반**: 명세를 먼저 작성하고 코드가 그로부터 "성장"
|
|
287
|
+
2. **점진적 공개**: Agent가 최소 진입점에서 시작하여 주문형으로 정보 로딩
|
|
288
|
+
3. **사용자 확인**: 각 단계의 출력은 AI 이탈을 방지하기 위해 사용자 확인 필요
|
|
289
|
+
4. **컨텍스트 격리**: 큰 작업을 작고 컨텍스트 격리된 하위 작업으로 분할
|
|
290
|
+
5. **하위 Agent 협업**: 복잡한 작업이 자동으로 하위 Agent를 디스패치하여 단일 Agent 컨텍스트 확장 방지
|
|
291
|
+
6. **빠른 반복**: 각 요구사항을 독립적인 프로젝트로 빠른 전달 및 검증
|
|
292
|
+
7. **지식 공유**: 모든 구성이 소스 코드와 함께 버전 관리됨
|
|
293
|
+
|
|
294
|
+
---
|
|
295
|
+
|
|
296
|
+
## 사용 사례
|
|
297
|
+
|
|
298
|
+
### ✅ 권장 대상
|
|
299
|
+
- 표준화된 워크플로우가 필요한 중대형 프로젝트
|
|
300
|
+
- 팀 협업 소프트웨어 개발
|
|
301
|
+
- 레거시 프로젝트 엔지니어링 변환
|
|
302
|
+
- 장기 유지보수가 필요한 제품
|
|
303
|
+
|
|
304
|
+
### ❌ 적합하지 않은 대상
|
|
305
|
+
- 개인용 빠른 프로토타입 검증
|
|
306
|
+
- 요구사항이 매우 불확실한 탐색적 프로젝트
|
|
307
|
+
- 일회성 스크립트나 도구
|
|
308
|
+
|
|
309
|
+
---
|
|
310
|
+
|
|
311
|
+
## 추가 정보
|
|
312
|
+
|
|
313
|
+
- **Agent 지식 맵**: [speccrew-workspace/docs/agent-knowledge-map.md](./speccrew-workspace/docs/agent-knowledge-map.md)
|
|
314
|
+
- **npm**: https://www.npmjs.com/package/speccrew
|
|
315
|
+
- **GitHub**: https://github.com/charlesmu99/speccrew
|
|
316
|
+
- **Gitee**: https://gitee.com/amutek/speccrew
|
|
317
|
+
- **Qoder IDE**: https://qoder.com/
|
|
318
|
+
|
|
319
|
+
---
|
|
320
|
+
|
|
321
|
+
> **SpecCrew는 개발자를 대체하는 것이 아니라 지루한 부분을 자동화하여 팀이 더 가치 있는 작업에 집중할 수 있도록 합니다.**
|