ellmos-ai 日本語 —
dev-cycleの公式日本語版。
開発サイクル (Dev Cycle) (日本語)
目的: 機能リクエストから検証済みシステムに至る構造化プロセス。 すべての開発は以下の8つのフェーズを通過します。
概要と目的
+--------------------------------------------------------------+
| DEVELOPMENT CYCLE |
+--------------------------------------------------------------+
| |
| Phase 1 Feature Requests (functional requirements) |
| | |
| v |
| Phase 2 Check Current State (What already exists?) |
| | |
| v |
| Phase 3 Functional Planning |
| (Workflows, Agents, Experts, Skills, Services) |
| | |
| v |
| Phase 4 Implement Functional Frontend |
| (Skill files, workflow markdown, agent profiles) |
| | |
| v |
| Phase 5 Plan and Align Backend |
| (CLI handlers, DB schema, API endpoints) |
| | |
| v |
| Phase 6 Implement Backend Tasks |
| (Python code, tools, DB migrations) |
| | |
| v |
| Phase 7 Technical Tests and Bugfixes |
| (B/O/E tests, bugfix protocol) |
| | |
| v |
| Phase 8 Functional and Feature Test: USE CASES |
| (End-to-end validation from user perspective) |
| |
+--------------------------------------------------------------+
Core principles throughout:
- Functional description first (before code)
- CLI First (everything controllable via terminal)
- Clear separation of user data and system data
フェーズ 1: 機能リクエスト (機能要件)
内容: 機能要件の収集および策定。
入力:
- ユーザーの要望、アイデア、課題
- パートナーからの提案（LLMアシスタント）
- ユースケースからの知見（フィードバックループ！）
出力:
- タスク管理システム内のタスク（例：Issue、チケット、TODOリストとして）
- 要件は「何を行いたいか」(WHAT) を記述し、「どのように行うか」(HOW) は記述しない
ルール:
- 要件は常に機能的に記述する（「ユーザーがXを行える」）
- 技術的に記述しない（「XのためのRESTエンドポイントを実装する」など）
- ユースケースを要件のソースとして活用する（フェーズ 8 -> フェーズ 1）
フェーズ 2: 現状確認
内容: 既存機能のインベントリ調査。
チェックリスト:
[ ] Search existing tools/scripts
[ ] Check documentation/help on the topic
[ ] Check existing skills/agents/services
[ ] Check DB schema (if relevant)
[ ] Check use cases - has something similar been tested?
出力:
- 既存のもの、不足しているもの、拡張が必要なもののドキュメント化
- 重複作業の回避
フェーズ 3: 機能計画
内容: 機能レベルでの計画 — すぐにコードを書かないこと。
計画レベル:
| レベル | 問い | 成果物 |
|---|---|---|
| Workflow | いつ/どのように調整を行うか？ | workflows/*.md |
| Agent | 誰が実行するか？ | agents/*.txt |
| Expert | 誰がドメイン知識を持っているか？ | experts/*/ |
| Skill | 何を行うか？ | skills/*.md |
| Service | 技術的にどのように実現するか？ | services/*/ |
ルール:
- まず機能的に考え、次に技術的に考える
- ワークフローはプロセスを記述し、実装の詳細には触れない
- すべてのアジエントには明確なプロフィールが必要
- サービスはユーザーデータなしで機能しなければならない
フェーズ 4: 機能フロントエンドの実装
内容: スキルファイル、ワークフローのMarkdown、エージェントプロフィールの作成。
ここでの「フロントエンド」とは機能記述層を指します：
- ワークフローファイル (.md)
- エージェントプロフィール (.txt)
- 専門家知識 (Expert knowledge)
- サービス記述
- ヘルプファイル
出力:
- すべての機能記述が存在する
- LLMパートナーがワークフローを読み込み理解できる
- 機能層が完全にドキュメント化されている
フェーズ 5: バックエンドの計画と調整
内容: 技術アーキテクチャを機能フロントエンドに合わせる。
計画領域:
| 領域 | 問い | 配置場所 |
|---|---|---|
| CLI Handlers | どのコマンドか？ | handlers/*.py |
| DB Schema | どのテーブル/カラムか？ | schema/*.sql |
| API Endpoints | どのGUIエンドポイントか？ | server.py |
| Tools | どのPythonスクリプトか？ | tools/*.py |
出力:
- 機能フロントエンドに合わせた技術計画
- データベーススキーマ設計
- CLIコマンド構造
フェーズ 6: バックエンドタスクの実装
内容: Pythonコード、DBマイグレーション、CLIハンドラーの記述。
チェックリスト（タスクごと）:
[ ] Works without user data (empty DB)?
[ ] CLI command available?
[ ] Input can come from files/folders?
[ ] Output goes to structured DB?
[ ] Scan/import is repeatable (idempotent)?
[ ] No hardcoded path?
[ ] Tool registered and documented?
[ ] Help file created?
フェーズ 7: 技術テストとバグ修正
内容: 技術的な正確性の確保。
テスト種別 (B/O/E):
| 種別 | 視点 | 説明 |
|---|---|---|
| B-Tests | 外部/自動化 | 自動テスト、CI/CD |
| O-Tests | 機能的 (入力->出力) | 手動での機能検証 |
| E-Tests | 主観的/体験 | UX評価、エルゴノミクス |
バグ発生時:
- バグ修正プロトコル (bugfix protocol) を適用する
- 20分ルールを守る（20分経過しても解決しない場合はアプローチを変更）
- 学んだ教訓 (lessons learned) を記録する
フェーズ 8: 機能およびフィーチャーテスト — ユースケース
内容: ユーザー視点からのエンドツーエンド (End-to-end) 検証。
ユースケースは両方の目的を果たします:
- 機能の指標 — 何が求められているか？何が可能であるべきか？
- テストシナリオ — AからZまで実際に機能するか？
ユースケースフォーマット:
USECASE_NNN: Short Title
PRECONDITION: What must be in place?
INPUT: What does the user enter / what data?
EXPECTED: What should the result be?
TESTS: Which components are tested?
フィードバックループ:
- 失敗したユースケース -> フェーズ 1 の新しいタスクへ
- 成功したユースケース -> 検証済み機能へ
- 新しいユースケースのアイデア -> タスクとして記録
まとめ: サイクル
Phase 8 (Use Cases)
|
| New requirements / bugs
v
Phase 1 (Feature Requests) --> Phase 2 (Current State)
^ |
| v
Phase 7 (Tests/Bugs) Phase 3 (Functional Planning)
^ |
| v
Phase 6 (Backend Code) Phase 4 (Functional Frontend)
^ |
| v
+──────────────────── Phase 5 (Backend Planning)
サイクルはループです: ユースケースによって機能が検証されると同時に、新たな要件が生成されます。
フェーズ固有のスキル
| フェーズ | 専門スキル | トリガー |
|---|---|---|
| フェーズ 1-3 | Project bootstrapper (利用可能な場合) | 新規プロジェクトの作成 (新規開発 / greenfield) |
| フェーズ 2 | project-onboarding | 既存プロジェクトの引き継ぎ |
| フェーズ 2-3 | docs-analysis | 要件定義書とコードの照合 |
| フェーズ 5-6 | pipeline-optimizer | 既存構造の刷新・リファクタリング |
| フェーズ 7 | bugfix-protocol | 体系的な6段階デバッグ |
| フェーズ 7-8 | bugsweep | リリース前の収束型バグスイープ |
スキルコレクションにスキルインデックスがある場合は、より多くのフェーズ固有スキルを検索してください。
変更履歴
1.1.0 (2026-06-13)
- project-onboarding, docs-analysis, pipeline-optimizer, bugfix-protocol, bugsweep への参照を含む「フェーズ固有のスキル」テーブルを新規追加
1.0.0 (2026-03-12)
- BACH (dev-zyklus v1.0.0) より移植
作成日: 2026-01-28 | 移植日: 2026-03-12