<img src="../banner.png" width="100%" alt="dev-cycle banner">

日本語 — 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) 検証。

ユースケースは両方の目的を果たします:

1. 機能の指標 — 何が求められているか？何が可能であるべきか？
2. テストシナリオ — 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