菜单
開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | orchestrating-development |
| description | 開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。 |
開発フェーズ全体のワークフローを案内する。TDD サイクルに従い、バックエンド→フロントエンドの順序で品質を担保しながら開発を進める。
| オプション | 説明 |
|---|---|
| なし | 開発フェーズ全体のワークフローを表示 |
--codex | Claude（計画・設計・受入）と Codex（実装）の分業体制で開発 |
developing-backend) — インサイドアウトアプローチ推奨developing-frontend) — アウトサイドインアプローチ推奨各開発で Red-Green-Refactor サイクルを厳密に実行する。テストなしでプロダクションコードを書かない。
コーディングとテストガイドのイテレーション開発フローに準拠し、以下のタイミングでレビュースキルを発動する。
| タイミング | スキル | 説明 |
|---|---|---|
| TODO 完了時（コードレビュー） | developing-review | TDD サイクルで TODO を完了するたびにコード品質・テスト品質・設計整合性をレビュー |
| 受け入れ前（品質チェック） | operating-qt | SonarQube によるコード品質分析・Quality Gate 確認を実施し、品質基準を満たしていることを検証 |
| イテレーション完了時（ユーザーレビュー） | analyzing-review | 受け入れフェーズでユーザー視点・プロダクト視点からの成果物レビュー |
TDD は「テストを書いてからコードを書く」手順ではなく、「設計を小さなフィードバックループで検証する」手法。10-15 分で 1 サイクルを完了させる。
Claude と Codex の役割を分離し、計画・設計・受入を Claude が担い、実装を Codex に委譲する。
前提条件: Codex MCP サーバーが設定済みであること（@docs/reference/CodexCLIMCPサーバー設定手順.md 参照）
| フェーズ | 担当 | 責務 |
|---|---|---|
| 計画 | Claude | 要件分析、タスク分解、優先度決定 |
| 設計 | Claude | API 設計、UI 設計、データモデル設計 |
| 実装 | Codex | コード実装、ユニットテスト作成 |
| 受入 | Claude | 設計レビュー、E2E テスト作成・実行、品質確認 |
graph LR
A[計画] --> B[設計]
B --> C[実装指示]
C --> D[受入]
subgraph Claude
A
B
D
end
subgraph Codex
C
end
| 粒度 | 推奨度 | 説明 |
|---|---|---|
| タスク単位（1-3 ファイル） | 推奨 | 1 つのコンポーネントや機能単位 |
| 機能単位（3-5 ファイル） | 注意 | 進捗確認を頻繁に行う |
| ユーザーストーリー単位 | 非推奨 | タスクに分割して実行する |
mcp__codex__codex
prompt: |
お知らせ管理機能を実装してください。
## 開発ガイド
docs/reference/コーディングとテストガイド.md に従って実装すること。
特に TDD サイクル（Red-Green-Refactor）を厳守すること。
## タスク
1. AuthContext に role と canManageAnnouncements を追加
2. API クライアントに create/update/delete 関数を追加
## 完了条件
- ESLint エラーなし
- 既存テストがパス
- TDD サイクルに従って実装
sandbox: danger-full-access
approval-policy: never
cwd: プロジェクトルート
開発セッションの途中から再開する場合は、まず現在の実装状況を確認する。
Example:
ユーザー: 「バックエンドの認証機能は実装済み。次の機能に進みたい」
回答: イテレーション計画を確認し、次のユーザーストーリーを特定する。
既存コードのテスト結果を確認し、Green 状態であることを検証してから
次のタスクの Red フェーズに進む。
タスクの区切りごとに /compact を実施して Context limit reached エラーを回避する。
/compact 前に現在の作業状態と次のタスクをメモとして出力するdeveloping-backend — バックエンド TDD 開発developing-frontend — フロントエンド TDD 開発developing-review — 開発成果物のマルチパースペクティブレビュー（TODO 完了時のコードレビュー）analyzing-review — 分析成果物のマルチパースペクティブレビュー（イテレーション完了時のユーザーレビュー）operating-qt — コード品質管理（受け入れ前の SonarQube 品質チェック）developing-release — リリースワークフロー（品質ゲート・バージョン管理・CHANGELOG）ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
DDD の戦術的設計パターンに基づくドメインモデル設計を支援。エンティティ、値オブジェクト、集約、ドメインサービスの設計。「ドメインモデルを設計したい」「DDD で設計したい」「集約を定義したい」「エンティティと値オブジェクトを識別したい」「ユビキタス言語を整理したい」といった場面で発動する。ドメインモデルを先に設計することで、業務ロジックが実装コードに正しく反映される。
インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
RDRA 2.0 に基づく体系的な要件定義を支援。システム価値→外部環境→境界→内部構造の 4 層で要件を整理。「要件定義を始めたい」「システムの要求を整理したい」「RDRA で分析したい」「業務フローを整理したい」「システムコンテキストを作りたい」といった場面で発動する。要件を体系的に整理することで、開発フェーズでの「何を作ればいいかわからない」問題を防ぐ。
インセプションデッキの Markdown から PowerPoint スライド（.pptx）を自動生成。pptxgenjs を使用し、テンプレート準拠の 12 枚構成プレゼンテーションを出力する。「スライドを生成したい」「インセプションデッキの pptx を作りたい」「プレゼン資料を出力したい」「スライドを更新したい」といった場面で発動する。Markdown から自動生成することで、内容更新のたびに手動でスライドを作り直す手間を排除する。
設計ドキュメントの一覧表示、進捗確認、内容参照、インデックス更新、Markdown Lint を実行。ドキュメント管理や整備時に使用。