メニュー
イテレーション計画と上流設計ドキュメント群（ユーザーストーリー、ドメインモデル、データモデル、UI 設計）との整合性を検証する。「イテレーション計画を検証したい」「計画の整合性をチェックして」「イテレーション計画を作成した」「計画と設計ドキュメントの不整合を確認したい」といった場面で発動する。planning-releases でイテレーション計画を作成した直後にも積極的に使用すること。計画作成後に必ず本検証を実施することで、開発着手前にドキュメント間の不整合を検知・修正できる。
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 | validating-iteration-plan |
| description | イテレーション計画と上流設計ドキュメント群（ユーザーストーリー、ドメインモデル、データモデル、UI 設計）との整合性を検証する。「イテレーション計画を検証したい」「計画の整合性をチェックして」「イテレーション計画を作成した」「計画と設計ドキュメントの不整合を確認したい」といった場面で発動する。planning-releases でイテレーション計画を作成した直後にも積極的に使用すること。計画作成後に必ず本検証を実施することで、開発着手前にドキュメント間の不整合を検知・修正できる。 |
イテレーション計画は複数の設計ドキュメントから情報を引用・参照するため、ドキュメント間の不整合がそのまま実装の不整合に直結する。計画作成後に本検証を実施し、開発着手前に不整合を検知・修正する。
| # | 検証対象 | パス | 検証内容 |
|---|---|---|---|
| 1 | テンプレートフォーマット | docs/template/イテレーション計画.md | 見出し構成・必須セクション・表形式・コードブロック形式の一致 |
| 2 | ユーザーストーリー | docs/requirements/user_story.md | ストーリー ID・タイトル・アクター・受入基準の一致 |
| 3 | ドメインモデル | docs/design/domain-model.md | 集約・エンティティ・値オブジェクトの名称・構造・関連の一致 |
| 4 | データモデル | docs/design/data-model.md | テーブル名・カラム名・型・制約・命名規約の一致 |
| 5 | UI 設計（ビュー） | docs/design/ui_design.md | ワイヤーフレーム構造・ナビバー形式・テーブル表記・URL パスの一致 |
| 6 | UI 設計（インタラクション） | docs/design/ui_design.md | 画面遷移・htmx パターン・PRG パターン・エラー処理・フィードバックメッセージの一致 |
| 7 | ゴールの整合性 | イテレーション計画全体 | ゴール・ストーリー・設計・タスク・見積もりの内部整合性 |
| 8 | 過去レビュー指摘事項 | docs/review/ 内の最新レビューファイル | 高・中優先度の指摘がストーリーまたはタスクとして計画に反映されているか |
8 ステップを順に実行する。各ステップは並列実行も可能。不整合を発見した場合はイテレーション計画を修正し、変更点を注記する。
イテレーション計画全体が docs/template/イテレーション計画.md のフォーマットに従っているかを確認する。以降の内容整合性チェックに入る前に、見出し構成・必須セクション・表形式・コードブロック形式がテンプレートから逸脱していないことを検証する。
チェック項目:
# イテレーション X 計画 形式になっているmermaid、plantuml、prisma などのコードブロック種別がテンプレートと一致しているDefinition of Done と デモ項目 が含まれているよくある不整合:
イテレーション計画の「ストーリー詳細」セクションと user_story.md を比較する。
チェック項目:
よくある不整合:
イテレーション計画の「設計 > ドメインモデル」セクションと domain-model.md を比較する。
チェック項目:
Schedule vs VoyageSchedule）CarrierMovement vs VoyageSchedule）Location を使うべき箇所で String になっていないか）よくある不整合:
Schedule -> VoyageSchedule）Location）を参照せず、直接 String で locode を保持イテレーション計画の「設計 > データモデル」セクションと data-model.md を比較する。
チェック項目:
BIGSERIAL + 業務キー UK の規約）id）を参照している（業務キー直接参照になっていないか）departure_location_unlocode vs departure_location）TIMESTAMP vs DATE）seq_number vs sequence_order）created_at・updated_at）が含まれているBIGSERIAL vs AUTO_INCREMENT）よくある不整合:
voyages）-> data-model.md は単数形（voyage）voyage_number PRIMARY KEY）-> 規約はサロゲートキー + UKREFERENCES voyages(voyage_number)）-> 規約は voyage.id 参照BIGSERIAL）と MySQL 構文（AUTO_INCREMENT）の混在イテレーション計画の「設計 > ユーザーインターフェース > ビュー」セクションと ui_design.md を比較する。
チェック項目:
{/ <b>CargoTracker</b> | メニュー... | [ログアウト] } 形式と一致している**太字** 形式と一致している（^カレット^ 形式になっていないか）よくある不整合:
イテレーション計画の「設計 > ユーザーインターフェース > インタラクション」セクションと ui_design.md の画面遷移図・htmx パターン・フィードバック規約を比較する。
チェック項目:
hx-get/hx-post・hx-target・hx-swap）が定義されているalert-*）が定義されているhtmx:responseError）への対応が考慮されているよくある不整合:
イテレーション計画全体を俯瞰し、イテレーションのゴールと各ストーリー・設計・タスクが一貫しているかを確認する。ステップ 1-6 がフォーマットおよび個別ドキュメントとの突合であるのに対し、本ステップは計画内部の論理的整合性を検証する最終関門である。
チェック項目:
よくある不整合:
docs/review/ 内の最新レビューファイルを確認し、前イテレーションで発見された指摘事項が今回の計画に適切に反映されているかを検証する。コードレビュー（*_review_*.md）・UI/UX レビュー（*_uiux_review_*.md）・分析レビュー（*_review_*.md）のいずれも対象とする。
チェック項目:
docs/review/index.md で最新のレビューファイルを特定している確認対象レビューファイルの特定方法:
docs/review/index.md のレビュー一覧テーブルを確認するよくある不整合:
検証完了後、以下の形式で報告する。
## 整合性検証結果
### 検証対象
- イテレーション計画: `docs/development/iteration_plan-N.md`
### 検証結果サマリー
| ステップ | 検証対象 | 結果 | 不整合件数 |
|---------|---------|------|-----------|
| 1 | テンプレートフォーマット | OK / NG | N 件 |
| 2 | ユーザーストーリー | OK / NG | N 件 |
| 3 | ドメインモデル | OK / NG | N 件 |
| 4 | データモデル | OK / NG | N 件 |
| 5 | UI 設計（ビュー） | OK / NG | N 件 |
| 6 | UI 設計（インタラクション） | OK / NG | N 件 |
| 7 | ゴールの整合性 | OK / NG | N 件 |
| 8 | 過去レビュー指摘事項 | OK / NG | N 件 |
### 不整合一覧（NG の場合のみ）
#### ステップ N: 〇〇との不整合
| # | 不整合内容 | 計画の記述 | 正しい記述（ドキュメント準拠） | 修正要否 |
|---|----------|-----------|---------------------------|---------|
| 1 | ... | ... | ... | 要修正 |