メニュー
開発フェーズ全体の TDD ワークフローをオーケストレーション。バックエンド・フロントエンドの開発順序と TDD サイクルの実践方法を案内し、Codex 分業体制もサポートする。「開発を始めたい」「TDD の進め方を知りたい」「Codex と分業で開発したい」「開発フェーズの全体像を把握したい」といった場面で発動する。開発フローを標準化することで、品質のブレを防ぎチーム全体の生産性を底上げする。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Marp Markdown スライドデッキの作成・拡張・再生成を支援。PlantUML 図表、AI 画像バリアント、漫画画像バリアント、PPTX/HTML 出力に対応。`tmp/k2works-wiki/スライド/YYYYMMDD` などの日本語技術スライドフォルダの構築・更新、コードサンプル追加、ビジュアル要約スライド追加、`スライド.images.md` / `スライド.images.ai.md` / `スライド.images.ai.manga.md` の生成、Marp HTML/PPTX デッキの再生成時に使用。
テスト駆動開発から始めるプログラミング入門」の対話式チュートリアル。FizzBuzz を題材に TDD の Red-Green-Refactor サイクルを 14 言語で体験する。「TDD を練習したい」「FizzBuzz で TDD を学びたい」「テスト駆動開発の入門をしたい」「Java で TDD を体験したい」「Python で TDD を始めたい」「プログラミング入門チュートリアルをやりたい」「getting-start-tdd をやりたい」「TDD のハンズオンがしたい」「Red-Green-Refactor を体験したい」といった場面で発動する。TDD チュートリアルやプログラミング入門の要望があれば積極的に使用すること。
ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」「ビジネスアーキテクチャを分析したい」「BA 分析をしたい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
企業事例（ケーススタディ）の与件文作成を支援。経営戦略・マーケティング・生産管理・財務会計の 4 パターンから選択し、テンプレートのプレースホルダに対応する質問に回答することで与件文を生成する。「企業事例を作りたい」「ケーススタディを書きたい」「与件文を作成したい」「診断士試験の事例問題を作りたい」「仮想企業の事例を整理したい」といった場面で発動する。事例テンプレートに沿って体系的にヒアリングすることで、論理的整合性のある与件文を効率的に作成できる。
企業事例（与件文）を基に企業戦略・事業戦略・機能戦略の 3 階層を体系的に立案。環境分析（SWOT・VRIO・BMC）から始めて、ドメイン定義・成長戦略・競争戦略・価値連鎖・ケイパビリティマップまで、PlantUML を活用した可視化ドキュメントを作成する。「戦略を立案したい」「企業戦略を作りたい」「事業戦略を策定したい」「SWOT 分析をしたい」「VRIO 分析をしたい」「成長戦略を考えたい」「競争戦略を立てたい」「価値連鎖を分析したい」「ケイパビリティマップを作りたい」「診断士試験の戦略分析をしたい」「企業事例から戦略を導出したい」といった場面で発動する。事例と戦略をセットで扱うことで、経営コンサルティングの提案書や中小企業診断士の答案に相当する体系的な戦略ドキュメントを作成できる。
インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
| 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 ファイル単位 | 推奨 | コード全文を含めた具体的な指示。最も確実 |
| タスク単位（2-3 ファイル） | 注意 | タイムアウトリスクあり。順次実行を推奨 |
| 機能・ストーリー単位 | 非推奨 | タイムアウトする。必ず分割して実行する |
--write フラグを含める: 書き込みが必要な場合は prompt 冒頭に --write を付けるcodex:codex-rescue に以下を委譲:
--write apps/sms/backend/src/main/java/.../HomeSummaryResponse.java に以下の record を作成してください。
（ファイルの完全なコードをここに記載）
git diff で意図しない変更がないことを確認（Codex は指示外のコードを書き換えることがある）localStorage → sessionStorage 等の無断変更がないか）| 問題 | 事例 | 対策 |
|---|---|---|
| タイムアウト | 6 ファイル同時指示で応答なし | 1 ファイルずつ順次指示 |
| 既存コードの無断変更 | localStorage → sessionStorage に書き換え | 「既存コードは変更しない」を明記 + git diff で検証 |
| API パターンの変更 | headers マージ方式をスプレッドから Object.assign に変更 | コード全文を渡して曖昧さを排除 |
| Spring Boot 4.0 パッケージ名の誤り | @WebMvcTest の import パスが旧バージョン | 既存テストの import パターンをコード全文に含める |
開発セッションの途中から再開する場合は、まず現在の実装状況を確認する。
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）