By name: orchestrating-development description: 開発フェーズ全体の TDD ワークフローをオーケストレーション。記事執筆と TDD 実装を章ごとに同期しながら進める。開発フェーズの開始や開発手法の確認時に使用。
開発フェーズオーケストレーション
記事執筆と TDD 実装を同期しながら進める開発フェーズ全体の作業を支援します。
Instructions
1. オプション
- なし : 開発フェーズ全体のワークフローを表示
--codex: Claude（計画・設計・受入）と Codex（実装）の分業体制で開発--chapter <言語> <章番号>: 指定した言語・章の執筆と実装を開始--sync: 執筆内容と実装コードの同期確認
2. 基本例
# 開発フェーズ全体のワークフロー表示
# 「開発フェーズの全体的な進め方を説明して」
# Java の第 1 章を執筆・実装
# --chapter java 1
# 「Java の第 1 章 TODO リストと最初のテストを開始」
# Claude と Codex の分業体制で開発
# --codex
# 「Java の実装を Codex に委託して進める」
# 執筆と実装の同期確認
# --sync
# 「記事内のコード例と apps/ の実装が一致しているか確認」
3. 開発フェーズの全体像
本プロジェクトの開発は「記事執筆」と「TDD 実装」を章ごとに同期しながら進めます:
graph TD
A[章の選択] --> B[参照記事の確認]
B --> C[執筆]
C --> D[TDD 実装]
D --> E[同期確認]
E --> F{不整合?}
F -->|あり| C
F -->|なし| G[MkDocs 更新]
G --> H{次の章?}
H -->|あり| A
H -->|なし| I[言語完了]
構成要素:
- 記事執筆 —
docs/article/{lang}/に章ごとの Markdown を作成 - TDD 実装 —
apps/{lang}/で TDD サイクル（Red-Green-Refactor）を実行 - 同期確認 — 記事内コード例と
apps/{lang}/の実コードの整合性を確認
4. 章ごとの執筆・実装サイクル
@docs/article/workflow.md のワークフローに従い、以下のサイクルを繰り返します:
Step 1: 章の選択
- @docs/article/outline.md から次の章を選択
- 推奨: 1 言語ずつ第 1〜12 章を通しで進める
Step 2: 参照記事の確認
Wiki 記事から該当内容を読み込みます:
| 部 | 参照先（Wiki） |
|---|---|
| 第 1 部: TDD の基本サイクル | tmp/k2works-wiki/記事/開発/テスト駆動開発から始めるXX入門/ エピソード 1 |
| 第 2 部: 開発環境と自動化 | 同上 エピソード 2 |
| 第 3 部: オブジェクト指向設計 | 同上 エピソード 3 |
| 第 4 部: 関数型プログラミングへの展開 | 同上 エピソード 4（該当言語のみ） |
Step 3: 執筆
docs/article/{lang}/NN-chapter-name.md にマークダウンで記事を作成します。
執筆フォーマット:
# 第N章: 章タイトル
## N.1 セクションタイトル
本文...
### コード例
\```java
// テストコード
@Test
void テスト名() {
// Arrange
// Act
// Assert
}
\```
### 実装
<details>
<summary>実装コード</summary>
\```java
public class FizzBuzz {
// ...
}
\```
</details>
Step 4: TDD 実装
Nix 環境で apps/{lang}/ にて TDD サイクルを実行します:
# 1. Nix 環境に入る
nix develop .#{lang}
# 2. apps/{lang}/ に移動（初回はプロジェクト初期化）
cd apps/{lang}
# 3. TDD サイクル
# Red → Green → Refactor
- @docs/reference/コーディングとテストガイド.md のワークフローに従う
- テストファースト（Red）→ 最小実装（Green）→ リファクタリング
Step 5: 同期確認
- 記事内のコード例が
apps/{lang}/の実コードと一致しているか確認 - テスト実行結果が記事の記述と一致しているか確認
- 不整合があれば記事・実装の両方を修正
Step 6: MkDocs 更新
mkdocs.ymlの nav に章を追加docs/article/{lang}/index.mdのリンクを有効化npm run docs:serveでローカルプレビュー確認
5. 対象言語と開発環境
各言語の開発環境は Nix で管理します:
| 環境名 | 言語 | Nix コマンド |
|---|---|---|
| java | Java | nix develop .#java |
| node | JavaScript / TypeScript | nix develop .#node |
| python | Python | nix develop .#python |
| ruby | Ruby | nix develop .#ruby |
| php | PHP | nix develop .#php |
| go | Go | nix develop .#go |
| rust | Rust | nix develop .#rust |
| dotnet | C# / F# | nix develop .#dotnet |
| clojure | Clojure | nix develop .#clojure |
| scala | Scala | nix develop .#scala |
| elixir | Elixir | nix develop .#elixir |
| haskell | Haskell | nix develop .#haskell |
6. ファイル構成
記事: docs/article/{lang}/NN-chapter-name.md
実装: apps/{lang}/（言語固有のプロジェクト構成）
docs/article/{lang}/NN-chapter-name.md ←→ apps/{lang}/
（記事・解説） （実装コード）
記事内のコード例は apps/{lang}/ の実際のコードと一致させます。実装を先に TDD で進め、動作確認済みのコードを記事に転記します。
7. TDD サイクルの実践
Red-Green-Refactor サイクルを厳密に実行:
- Red フェーズ: 失敗するテストを最初に書く
- Green フェーズ: テストを通す最小限のコードを実装
- Refactor フェーズ: 重複を除去し設計を改善
- @docs/reference/コーディングとテストガイド.md のワークフローに従う
8. Codex を活用した開発モード（--codex）
--codex オプションを指定すると、Claude と Codex の分業体制で開発を進めます。
前提条件:
- Codex MCP サーバーが設定済みであること
- @docs/reference/CodexCLIMCPサーバー設定手順.md を参照
- @docs/reference/CodexCLIMCPアプリケーション開発フロー.md を参照
役割分担:
| フェーズ | 担当 | 責務 |
|---|---|---|
| 計画 | Claude | 章の選択、参照記事の確認、タスク分解 |
| 執筆 | Claude | 記事の構成・執筆、コード例の作成 |
| 実装 | Codex | apps/{lang}/ での TDD 実装 |
| 受入 | Claude | 同期確認、MkDocs 更新、品質チェック |
開発フロー:
graph LR
A[章の計画] --> B[記事執筆]
B --> C[実装指示]
C --> D[同期・受入]
subgraph Claude
A
B
D
end
subgraph Codex
C
end
Codex への指示例:
mcp__codex__codex
prompt: |
apps/java/ で FizzBuzz の TDD 実装を行ってください。
## 開発ガイド
docs/reference/コーディングとテストガイド.md に従って実装すること。
TDD サイクル（Red-Green-Refactor）を厳守すること。
## タスク
1. FizzBuzz クラスのユニットテストを作成
2. テストを通す最小限の実装
3. リファクタリング
## 完了条件
- 全テストがパス
- 静的解析エラーなし
- TDD サイクルに従って実装
sandbox: danger-full-access
approval-policy: never
cwd: プロジェクトルート
Codex MCP ツールのパラメータ:
| パラメータ | 説明 | 推奨値 |
|---|---|---|
prompt |
実装指示（詳細な要件を含む） | タスク単位で明確に記述 |
sandbox |
実行環境の権限レベル | danger-full-access（推奨） |
approval-policy |
コマンド実行時の承認ポリシー | never |
cwd |
作業ディレクトリ | プロジェクトルート |
指示サイズに関する注意:
| 粒度 | 推奨度 | 説明 |
|---|---|---|
| 章単位（1 章分の実装） | 推奨 | 1 つの章に対応する TDD 実装 |
| 部単位（3 章分の実装） | 注意 | 進捗確認を頻繁に行う |
| 言語全体（12 章分） | 非推奨 | 章ごとに分割して実行 |
Codex が書き込みできない場合の対処:
- Claude が勝手に直接編集を進めてはいけない
- ユーザーに状況を報告し、確認を待つ
- ユーザーの許可を得てから代替手段を実行
9. 実装同期チェックリスト
-
apps/{lang}/にプロジェクトが作成されている - テストコードが執筆内容と一致
- プロダクションコードが一致
- テスト実行結果が記事の記述と一致
- リファクタリング後のコードが反映済み
- 記事内のコード例が
apps/{lang}/の実コードと同期している
10. MkDocs チェックリスト
- 章ファイルが正しいパスに配置されている
-
mkdocs.ymlの nav に章が追加されている -
index.mdのリンクが正しい - ローカルプレビューで表示確認済み
- PlantUML ダイアグラムが正しくレンダリングされる
- 内部リンクが正常に動作する
11. 参照ドキュメント
- @docs/article/outline.md : 執筆計画アウトライン（章構成・対象言語）
- @docs/article/workflow.md : 執筆ワークフロー（詳細フロー・ルール）
- @docs/reference/コーディングとテストガイド.md : TDD サイクルの実践ガイド
- @docs/reference/CodexCLIMCPアプリケーション開発フロー.md : Codex 活用フロー
- @docs/reference/CodexCLIMCPサーバー設定手順.md : Codex MCP サーバー設定手順
- 作業完了後に @docs/development/iteration_plan-N.md の進捗を更新する
- 作業完了後に @docs/article/workflow.md の進捗管理テーブルを更新する
12. コンテキスト管理
長時間の開発セッションでは Context limit reached エラーを回避するため、タスクの区切りごとに /compact を実施してコンテキストを圧縮する。
/compact を実施するタイミング:
- 1 章の執筆・実装が完了したとき
- TDD サイクル（Red-Green-Refactor）を数回繰り返した後
- Codex への実装指示と受入フェーズの間
- コミット完了後、次の章に着手する前
運用ルール:
/compact実施前に、現在の作業状態と次のタスクをメモとして出力する/compact実施後、次のタスクの作業を継続する- 1 言語 12 章を通す場合、3〜4 章ごとに
/compactを検討する
13. 注意事項
- 前提条件: Nix 開発環境が利用可能であること。
ops/nix/environments/に言語環境が定義されていること - 制限事項: TDD の三原則を厳密に守る（テストなしでプロダクションコードを書かない）
- 推奨事項: 実装を先に TDD で完成させ、動作確認済みのコードを記事に転記する
14. ベストプラクティス
- 1 言語通し執筆: 1 言語ずつ第 1〜12 章を通しで執筆・実装する
- TDD ファースト: 記事の前に
apps/{lang}/で TDD 実装を完成させる - 小さなサイクル: Red-Green-Refactor を 10-15 分で完了させる
- 継続的コミット: 各章完了時に動作する状態でコミット
- 同期チェック: 章完了時に記事とコードの整合性を必ず確認
関連スキル / ドキュメント
- Skill:
developing-backend: バックエンド開発ガイド（TDD インサイドアウト） - Skill:
developing-frontend: フロントエンド開発ガイド（TDD アウトサイドイン） - Skill:
developing-release: リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG） - Skill:
managing-docs: ドキュメント管理（MkDocs 更新・Lint）