@k2works/claude-code-booster 4.7.0 → 4.9.0

package/lib/assets/.claude/skills/validating-iteration-plan/SKILL.md

@@ -1,238 +1,238 @@
----
-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 ステップを順に実行する。各ステップは並列実行も可能。不整合を発見した場合はイテレーション計画を修正し、変更点を注記する。
-
-### ステップ 1: テンプレートフォーマットとの整合性
-
-イテレーション計画全体が `docs/template/イテレーション計画.md` のフォーマットに従っているかを確認する。以降の内容整合性チェックに入る前に、見出し構成・必須セクション・表形式・コードブロック形式がテンプレートから逸脱していないことを検証する。
-
-**チェック項目**:
-
-- [ ] 文書タイトルが `# イテレーション X 計画` 形式になっている
-- [ ] テンプレートの主要セクション（概要、ゴール、ユーザーストーリー、スケジュール、設計、リスクと対策、完了条件、更新履歴、関連ドキュメント）が揃っている
-- [ ] 各セクションの見出しレベルがテンプレートと一致している
-- [ ] 概要、対象ストーリー、タスク、リスク、更新履歴などの表形式がテンプレートの列構成に従っている
-- [ ] `mermaid`、`plantuml`、`prisma` などのコードブロック種別がテンプレートと一致している
-- [ ] 完了条件に `Definition of Done` と `デモ項目` が含まれている
-- [ ] 関連ドキュメント節に最低限の参照先が記載されている
-
-**よくある不整合**:
-
-- テンプレート必須セクションの欠落（例: 「更新履歴」がない）
-- 見出し名や階層の変更（例: 「ユーザーストーリー」ではなく独自見出しを使用）
-- 表の列不足や列名変更
-- コードブロックの種別未指定、またはテンプレートと異なる記法
-
-### ステップ 2: ユーザーストーリーとの整合性
-
-イテレーション計画の「ストーリー詳細」セクションと `user_story.md` を比較する。
-
-**チェック項目**:
-
-- [ ] ストーリー ID（US番号）が一致している
-- [ ] ストーリータイトルが一致している
-- [ ] アクター（「として」の部分）が一致している
-- [ ] ストーリー文（「したい」「なぜなら」の部分）が一致している（省略なく全文一致）
-- [ ] 受入基準の項目数と内容が一致している
-- [ ] 対応 UC 番号が一致している
-
-**よくある不整合**:
-
-- ストーリー文の一部省略（例: 「予約情報」-> 元は「予約情報（出発地・目的地・期限・貨物仕様）」）
-- 受入基準の列挙が省略されている（例: 制約条件の具体名が省略）
-
-### ステップ 3: ドメインモデルとの整合性
-
-イテレーション計画の「設計 > ドメインモデル」セクションと `domain-model.md` を比較する。
-
-**チェック項目**:
-
-- [ ] 集約ルートの名称が一致している
-- [ ] 値オブジェクトの名称・フィールドが一致している（例: `Schedule` vs `VoyageSchedule`）
-- [ ] エンティティの名称・フィールドが一致している（例: `CarrierMovement` vs `VoyageSchedule`）
-- [ ] 共有カーネル参照が正しい（例: `Location` を使うべき箇所で `String` になっていないか）
-- [ ] 既存の集約構造を破壊する変更になっていないか
-- [ ] 新規追加の場合、既存構造との関連が明記されているか
-- [ ] domain-model.md への反映が必要な変更点が注記されているか
-
-**よくある不整合**:
-
-- 既存の値オブジェクト名と異なる名称を使用（例: `Schedule` -> `VoyageSchedule`）
-- 既存の集約構造（親子関係）を無視した新規モデル設計
-- 共有カーネル（`Location`）を参照せず、直接 `String` で locode を保持
-
-### ステップ 4: データモデルとの整合性
-
-イテレーション計画の「設計 > データモデル」セクションと `data-model.md` を比較する。
-
-**チェック項目**:
-
-- [ ] テーブル名の単数形/複数形が data-model.md の規約と一致している
-- [ ] PK 設計が一致している（サロゲートキー `BIGSERIAL` + 業務キー `UK` の規約）
-- [ ] FK の参照先がサロゲートキー（`id`）を参照している（業務キー直接参照になっていないか）
-- [ ] カラム名が一致している（例: `departure_location_unlocode` vs `departure_location`）
-- [ ] データ型が一致している（例: `TIMESTAMP` vs `DATE`）
-- [ ] 順序カラム名が一致している（例: `seq_number` vs `sequence_order`）
-- [ ] 監査カラム（`created_at`・`updated_at`）が含まれている
-- [ ] DB 構文が一致している（例: `BIGSERIAL` vs `AUTO_INCREMENT`）
-- [ ] 既存テーブルの拡張か新規テーブルかが明確に区別されている
-- [ ] 新規テーブルの場合、既存テーブルとの関係が既存の設計と整合しているか
-
-**よくある不整合**:
-
-- テーブル名が複数形（`voyages`）-> data-model.md は単数形（`voyage`）
-- PK が業務キー直接（`voyage_number PRIMARY KEY`）-> 規約はサロゲートキー + UK
-- FK が業務キー参照（`REFERENCES voyages(voyage_number)`）-> 規約は `voyage.id` 参照
-- PostgreSQL 構文（`BIGSERIAL`）と MySQL 構文（`AUTO_INCREMENT`）の混在
-
-### ステップ 5: UI 設計（ビュー）との整合性
-
-イテレーション計画の「設計 > ユーザーインターフェース > ビュー」セクションと `ui_design.md` を比較する。
-
-**チェック項目**:
-
-- [ ] ナビバー構造が `{/ <b>CargoTracker</b> | メニュー... | [ログアウト] }` 形式と一致している
-- [ ] テーブルヘッダー表記が `**太字**` 形式と一致している（`^カレット^` 形式になっていないか）
-- [ ] URL パスが画面一覧の規約と一致している
-- [ ] 新規画面の画面一覧エントリが定義されている
-- [ ] 既存画面の拡張の場合、拡張箇所が明確に区別されている
-- [ ] 検索フォームのレイアウトが既存画面と一致している
-- [ ] ボタン配置・ラベルが既存画面のパターンと一致している
-
-**よくある不整合**:
-
-- 独自のナビバー構造を使用
-- テーブルヘッダーの表記形式が異なる
-- URL パスが未定義
-- 既存画面との関係（拡張 vs 新規）が不明確
-
-### ステップ 6: UI 設計（インタラクション）との整合性
-
-イテレーション計画の「設計 > ユーザーインターフェース > インタラクション」セクションと `ui_design.md` の画面遷移図・htmx パターン・フィードバック規約を比較する。
-
-**チェック項目**:
-
-- [ ] 画面遷移図に全画面の state が定義されている（URL パス・説明テキスト付き）
-- [ ] バリデーションエラーの自己ループ遷移が全フォーム画面に定義されている
-- [ ] 遷移方式（GET / PRG）が各遷移に明記されている
-- [ ] 既存の state（航路一覧等）との遷移関係が定義されている
-- [ ] htmx パターン（`hx-get`/`hx-post`・`hx-target`・`hx-swap`）が定義されている
-- [ ] フィードバックメッセージ（成功・警告・エラー）とスタイル（`alert-*`）が定義されている
-- [ ] htmx エラーハンドリング（`htmx:responseError`）への対応が考慮されている
-
-**よくある不整合**:
-
-- バリデーションエラー自己ループ遷移の欠落
-- htmx パターンの記述がない（画面遷移図のみで動的更新方式が不明）
-- フィードバックメッセージの定義がない
-- 既存画面 state との遷移関係が切断されている
-
-### ステップ 7: ゴールの整合性（最終確認）
-
-イテレーション計画全体を俯瞰し、イテレーションのゴールと各ストーリー・設計・タスクが一貫しているかを確認する。ステップ 1-6 がフォーマットおよび個別ドキュメントとの突合であるのに対し、本ステップは計画内部の論理的整合性を検証する最終関門である。
-
-**チェック項目**:
-
-- [ ] イテレーションゴール（目的・達成条件）が明確に記述されている
-- [ ] 含まれる全ストーリーがゴールの達成に寄与している（ゴールと無関係なストーリーが混入していないか）
-- [ ] ゴールの達成に必要なストーリーが欠落していないか
-- [ ] ストーリー間の依存関係が識別され、実装順序に反映されている
-- [ ] 設計セクション（ドメインモデル・データモデル・UI）がストーリーの受入基準を満たすに十分な内容か
-- [ ] タスク分割がストーリーの受入基準をすべてカバーしている
-- [ ] 見積もり（ストーリーポイント）の合計がチームのベロシティと整合しているか
-- [ ] 前イテレーションからの持ち越し事項が反映されているか
-
-**よくある不整合**:
-
-- ゴールが抽象的すぎて達成条件が判断できない（例: 「航路管理機能を改善する」→ 具体的な完了基準がない）
-- ゴールに対して過剰なストーリーが含まれている（スコープクリープ）
-- 設計セクションの内容がストーリーの一部しかカバーしていない
-- タスク分割が設計セクションと対応していない（設計にあるがタスクにない、またはその逆）
-- ベロシティを超えるポイントが計画されている
-
-### ステップ 8: 過去レビュー指摘事項との整合性
-
-`docs/review/` 内の最新レビューファイルを確認し、前イテレーションで発見された指摘事項が今回の計画に適切に反映されているかを検証する。コードレビュー（`*_review_*.md`）・UI/UX レビュー（`*_uiux_review_*.md`）・分析レビュー（`*_review_*.md`）のいずれも対象とする。
-
-**チェック項目**:
-
-- [ ] `docs/review/index.md` で最新のレビューファイルを特定している
-- [ ] 高優先度（「高」）の指摘事項がストーリーまたはタスクとして計画に含まれているか、含まれない場合は対応方針（許容 / 保留）が計画に明記されているか
-- [ ] 中優先度（「中」）の指摘事項について、対応するストーリー / タスク / 対応方針が計画に記載されているか
-- [ ] 前イテレーションの「IT2 対応方針」「次のステップ」「持ち越し事項」として明記された指摘が計画に引き継がれているか
-- [ ] レビューで発見された受入基準の不整合（未実装フィールド等）が、当該ストーリーの受入基準の修正として反映されているか
-- [ ] 技術的負債（アクセシビリティ違反、バリデーション仕様乖離等）の解消が計画に含まれているか
-
-**確認対象レビューファイルの特定方法**:
-
-1. `docs/review/index.md` のレビュー一覧テーブルを確認する
-2. 今回計画するイテレーション番号の直前イテレーションに対応するレビューファイルを抽出する
-3. 複数のレビュー種別（コードレビュー + UI/UX レビュー）がある場合はすべて確認する
-
-**よくある不整合**:
-
-- 高優先度の指摘が計画に含まれておらず、対応方針の記載もない（暗黙の未対応）
-- 前イテレーションで「IT(N+1) 対応」と明記された指摘が、IT(N+1) の計画に含まれていない
-- 受入基準の修正が必要な指摘（例: 未実装フィールド、仕様乖離）が設計セクションに反映されていない
-- レビューで指摘された UI の日本語化・バリデーション修正がタスクとして計画されていない
-
-## 検証結果の報告
-
-検証完了後、以下の形式で報告する。
-
-```markdown
-## 整合性検証結果
-
-### 検証対象
-- イテレーション計画: `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 | ... | ... | ... | 要修正 |
-```
-
-## 注意事項
-
-- 検証は計画作成直後に実施する（開発着手前に不整合を解消する）
-- 既存ドキュメントへの反映が必要な変更点は、イテレーション計画内に「注」として明記する
-- イテレーション完了時に、注記された変更点を各設計ドキュメントに反映する
-- 不整合を発見した場合、イテレーション計画側を設計ドキュメントに合わせて修正する（設計ドキュメントが正）
+---
+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 ステップを順に実行する。各ステップは並列実行も可能。不整合を発見した場合はイテレーション計画を修正し、変更点を注記する。
+
+### ステップ 1: テンプレートフォーマットとの整合性
+
+イテレーション計画全体が `docs/template/イテレーション計画.md` のフォーマットに従っているかを確認する。以降の内容整合性チェックに入る前に、見出し構成・必須セクション・表形式・コードブロック形式がテンプレートから逸脱していないことを検証する。
+
+**チェック項目**:
+
+- [ ] 文書タイトルが `# イテレーション X 計画` 形式になっている
+- [ ] テンプレートの主要セクション（概要、ゴール、ユーザーストーリー、スケジュール、設計、リスクと対策、完了条件、更新履歴、関連ドキュメント）が揃っている
+- [ ] 各セクションの見出しレベルがテンプレートと一致している
+- [ ] 概要、対象ストーリー、タスク、リスク、更新履歴などの表形式がテンプレートの列構成に従っている
+- [ ] `mermaid`、`plantuml`、`prisma` などのコードブロック種別がテンプレートと一致している
+- [ ] 完了条件に `Definition of Done` と `デモ項目` が含まれている
+- [ ] 関連ドキュメント節に最低限の参照先が記載されている
+
+**よくある不整合**:
+
+- テンプレート必須セクションの欠落（例: 「更新履歴」がない）
+- 見出し名や階層の変更（例: 「ユーザーストーリー」ではなく独自見出しを使用）
+- 表の列不足や列名変更
+- コードブロックの種別未指定、またはテンプレートと異なる記法
+
+### ステップ 2: ユーザーストーリーとの整合性
+
+イテレーション計画の「ストーリー詳細」セクションと `user_story.md` を比較する。
+
+**チェック項目**:
+
+- [ ] ストーリー ID（US番号）が一致している
+- [ ] ストーリータイトルが一致している
+- [ ] アクター（「として」の部分）が一致している
+- [ ] ストーリー文（「したい」「なぜなら」の部分）が一致している（省略なく全文一致）
+- [ ] 受入基準の項目数と内容が一致している
+- [ ] 対応 UC 番号が一致している
+
+**よくある不整合**:
+
+- ストーリー文の一部省略（例: 「予約情報」-> 元は「予約情報（出発地・目的地・期限・貨物仕様）」）
+- 受入基準の列挙が省略されている（例: 制約条件の具体名が省略）
+
+### ステップ 3: ドメインモデルとの整合性
+
+イテレーション計画の「設計 > ドメインモデル」セクションと `domain-model.md` を比較する。
+
+**チェック項目**:
+
+- [ ] 集約ルートの名称が一致している
+- [ ] 値オブジェクトの名称・フィールドが一致している（例: `Schedule` vs `VoyageSchedule`）
+- [ ] エンティティの名称・フィールドが一致している（例: `CarrierMovement` vs `VoyageSchedule`）
+- [ ] 共有カーネル参照が正しい（例: `Location` を使うべき箇所で `String` になっていないか）
+- [ ] 既存の集約構造を破壊する変更になっていないか
+- [ ] 新規追加の場合、既存構造との関連が明記されているか
+- [ ] domain-model.md への反映が必要な変更点が注記されているか
+
+**よくある不整合**:
+
+- 既存の値オブジェクト名と異なる名称を使用（例: `Schedule` -> `VoyageSchedule`）
+- 既存の集約構造（親子関係）を無視した新規モデル設計
+- 共有カーネル（`Location`）を参照せず、直接 `String` で locode を保持
+
+### ステップ 4: データモデルとの整合性
+
+イテレーション計画の「設計 > データモデル」セクションと `data-model.md` を比較する。
+
+**チェック項目**:
+
+- [ ] テーブル名の単数形/複数形が data-model.md の規約と一致している
+- [ ] PK 設計が一致している（サロゲートキー `BIGSERIAL` + 業務キー `UK` の規約）
+- [ ] FK の参照先がサロゲートキー（`id`）を参照している（業務キー直接参照になっていないか）
+- [ ] カラム名が一致している（例: `departure_location_unlocode` vs `departure_location`）
+- [ ] データ型が一致している（例: `TIMESTAMP` vs `DATE`）
+- [ ] 順序カラム名が一致している（例: `seq_number` vs `sequence_order`）
+- [ ] 監査カラム（`created_at`・`updated_at`）が含まれている
+- [ ] DB 構文が一致している（例: `BIGSERIAL` vs `AUTO_INCREMENT`）
+- [ ] 既存テーブルの拡張か新規テーブルかが明確に区別されている
+- [ ] 新規テーブルの場合、既存テーブルとの関係が既存の設計と整合しているか
+
+**よくある不整合**:
+
+- テーブル名が複数形（`voyages`）-> data-model.md は単数形（`voyage`）
+- PK が業務キー直接（`voyage_number PRIMARY KEY`）-> 規約はサロゲートキー + UK
+- FK が業務キー参照（`REFERENCES voyages(voyage_number)`）-> 規約は `voyage.id` 参照
+- PostgreSQL 構文（`BIGSERIAL`）と MySQL 構文（`AUTO_INCREMENT`）の混在
+
+### ステップ 5: UI 設計（ビュー）との整合性
+
+イテレーション計画の「設計 > ユーザーインターフェース > ビュー」セクションと `ui_design.md` を比較する。
+
+**チェック項目**:
+
+- [ ] ナビバー構造が `{/ <b>CargoTracker</b> | メニュー... | [ログアウト] }` 形式と一致している
+- [ ] テーブルヘッダー表記が `**太字**` 形式と一致している（`^カレット^` 形式になっていないか）
+- [ ] URL パスが画面一覧の規約と一致している
+- [ ] 新規画面の画面一覧エントリが定義されている
+- [ ] 既存画面の拡張の場合、拡張箇所が明確に区別されている
+- [ ] 検索フォームのレイアウトが既存画面と一致している
+- [ ] ボタン配置・ラベルが既存画面のパターンと一致している
+
+**よくある不整合**:
+
+- 独自のナビバー構造を使用
+- テーブルヘッダーの表記形式が異なる
+- URL パスが未定義
+- 既存画面との関係（拡張 vs 新規）が不明確
+
+### ステップ 6: UI 設計（インタラクション）との整合性
+
+イテレーション計画の「設計 > ユーザーインターフェース > インタラクション」セクションと `ui_design.md` の画面遷移図・htmx パターン・フィードバック規約を比較する。
+
+**チェック項目**:
+
+- [ ] 画面遷移図に全画面の state が定義されている（URL パス・説明テキスト付き）
+- [ ] バリデーションエラーの自己ループ遷移が全フォーム画面に定義されている
+- [ ] 遷移方式（GET / PRG）が各遷移に明記されている
+- [ ] 既存の state（航路一覧等）との遷移関係が定義されている
+- [ ] htmx パターン（`hx-get`/`hx-post`・`hx-target`・`hx-swap`）が定義されている
+- [ ] フィードバックメッセージ（成功・警告・エラー）とスタイル（`alert-*`）が定義されている
+- [ ] htmx エラーハンドリング（`htmx:responseError`）への対応が考慮されている
+
+**よくある不整合**:
+
+- バリデーションエラー自己ループ遷移の欠落
+- htmx パターンの記述がない（画面遷移図のみで動的更新方式が不明）
+- フィードバックメッセージの定義がない
+- 既存画面 state との遷移関係が切断されている
+
+### ステップ 7: ゴールの整合性（最終確認）
+
+イテレーション計画全体を俯瞰し、イテレーションのゴールと各ストーリー・設計・タスクが一貫しているかを確認する。ステップ 1-6 がフォーマットおよび個別ドキュメントとの突合であるのに対し、本ステップは計画内部の論理的整合性を検証する最終関門である。
+
+**チェック項目**:
+
+- [ ] イテレーションゴール（目的・達成条件）が明確に記述されている
+- [ ] 含まれる全ストーリーがゴールの達成に寄与している（ゴールと無関係なストーリーが混入していないか）
+- [ ] ゴールの達成に必要なストーリーが欠落していないか
+- [ ] ストーリー間の依存関係が識別され、実装順序に反映されている
+- [ ] 設計セクション（ドメインモデル・データモデル・UI）がストーリーの受入基準を満たすに十分な内容か
+- [ ] タスク分割がストーリーの受入基準をすべてカバーしている
+- [ ] 見積もり（ストーリーポイント）の合計がチームのベロシティと整合しているか
+- [ ] 前イテレーションからの持ち越し事項が反映されているか
+
+**よくある不整合**:
+
+- ゴールが抽象的すぎて達成条件が判断できない（例: 「航路管理機能を改善する」→ 具体的な完了基準がない）
+- ゴールに対して過剰なストーリーが含まれている（スコープクリープ）
+- 設計セクションの内容がストーリーの一部しかカバーしていない
+- タスク分割が設計セクションと対応していない（設計にあるがタスクにない、またはその逆）
+- ベロシティを超えるポイントが計画されている
+
+### ステップ 8: 過去レビュー指摘事項との整合性
+
+`docs/review/` 内の最新レビューファイルを確認し、前イテレーションで発見された指摘事項が今回の計画に適切に反映されているかを検証する。コードレビュー（`*_review_*.md`）・UI/UX レビュー（`*_uiux_review_*.md`）・分析レビュー（`*_review_*.md`）のいずれも対象とする。
+
+**チェック項目**:
+
+- [ ] `docs/review/index.md` で最新のレビューファイルを特定している
+- [ ] 高優先度（「高」）の指摘事項がストーリーまたはタスクとして計画に含まれているか、含まれない場合は対応方針（許容 / 保留）が計画に明記されているか
+- [ ] 中優先度（「中」）の指摘事項について、対応するストーリー / タスク / 対応方針が計画に記載されているか
+- [ ] 前イテレーションの「IT2 対応方針」「次のステップ」「持ち越し事項」として明記された指摘が計画に引き継がれているか
+- [ ] レビューで発見された受入基準の不整合（未実装フィールド等）が、当該ストーリーの受入基準の修正として反映されているか
+- [ ] 技術的負債（アクセシビリティ違反、バリデーション仕様乖離等）の解消が計画に含まれているか
+
+**確認対象レビューファイルの特定方法**:
+
+1. `docs/review/index.md` のレビュー一覧テーブルを確認する
+2. 今回計画するイテレーション番号の直前イテレーションに対応するレビューファイルを抽出する
+3. 複数のレビュー種別（コードレビュー + UI/UX レビュー）がある場合はすべて確認する
+
+**よくある不整合**:
+
+- 高優先度の指摘が計画に含まれておらず、対応方針の記載もない（暗黙の未対応）
+- 前イテレーションで「IT(N+1) 対応」と明記された指摘が、IT(N+1) の計画に含まれていない
+- 受入基準の修正が必要な指摘（例: 未実装フィールド、仕様乖離）が設計セクションに反映されていない
+- レビューで指摘された UI の日本語化・バリデーション修正がタスクとして計画されていない
+
+## 検証結果の報告
+
+検証完了後、以下の形式で報告する。
+
+```markdown
+## 整合性検証結果
+
+### 検証対象
+- イテレーション計画: `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 | ... | ... | ... | 要修正 |
+```
+
+## 注意事項
+
+- 検証は計画作成直後に実施する（開発着手前に不整合を解消する）
+- 既存ドキュメントへの反映が必要な変更点は、イテレーション計画内に「注」として明記する
+- イテレーション完了時に、注記された変更点を各設計ドキュメントに反映する
+- 不整合を発見した場合、イテレーション計画側を設計ドキュメントに合わせて修正する（設計ドキュメントが正）

package/lib/assets/.claude/skills/validating-operating-setup/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: validating-operating-setup
+description: 環境セットアップ手順書 (docs/operation/*.md) に書かれた各ステップが現在のプロジェクトに反映されているかを監査し、未対応・部分対応の項目とその推奨対処を表形式で報告する。手順書を作っただけで実施が放置されがちな問題を防ぐためのスキル。「環境セットアップ確認」「手順書実施状況」「アプリケーション開発環境セットアップ手順書の内容を全て実施しているか確認」のような依頼や、operating-setup スキル実行後の完了確認、IT 着手前の前提条件チェックで自動的に発動する。手順書監査・進捗確認・ギャップ分析・着手前チェックリスト・準備状況レビューといった文脈で必ず使用する。
+---
+
+# 環境セットアップ手順書の実施状況監査
+
+`operating-setup` で生成された手順書 (`docs/operation/*.md`) の各ステップが、実際のプロジェクト状態に反映されているかを章ごとに監査する。
+
+手順書は「**書いた瞬間に古くなる**」性質を持つため、定期的に **手順書とプロジェクトの整合性** をチェックしないと、新メンバーが古い手順を信じてハマる、IT 着手時に前提条件が未整備で詰まる、CI で「設定したはず」が動いていない、といった問題が起こる。このスキルは「何が出来ていて、何が出来ていないか」を **客観的に証拠つきで** 突きつけることで、こうした腐敗を早期検知する。
+
+## 入力
+
+| 入力 | 例 |
+| :--- | :--- |
+| 監査対象の手順書 | `docs/operation/アプリケーション開発環境セットアップ手順書.md` |
+| (省略時) | プロジェクトの現フェーズに応じた最新手順書を推測。複数候補があるときはユーザーに確認 |
+
+## 出力
+
+以下を **必ずこの順序で** 出力する。
+
+1. **章ごとのチェックリスト表** — 手順書の全章 (1〜N) を網羅。判定列に `✅` / `⚠️` / `❌` を入れ、備考列に確認コマンドや検出結果を書く
+2. **サマリ表** — 状態別の件数
+3. **分類別の推奨対処** — ❌ と ⚠️ を以下のバケツに分類:
+   - **A. 今すぐ対応可能 (運用補強)** — シェル一発・設定ファイル追加で終わるもの
+   - **B. 実装フェーズ (IT1 等) で対応** — コード実装と一体で動くもの
+   - **C. 開発体験向上ツール (任意)** — あると良いが必須でないもの
+   - **D. 後フェーズで対応** — CI/CD・本番環境など、別スキル (`operating-cicd` 等) の領域
+4. **着手提案** — どこから手を付けるか 1〜2 行で提案し、ユーザーの GO サインを待つ
+
+## 監査の進め方
+
+### 1. 手順書を全文読む
+
+省略せず最初から最後まで読む。章番号と項目名を全て把握する。
+
+### 2. 章ごとに「何を見れば真偽が判定できるか」を考える
+
+手順書の記述は **意図の宣言** にすぎないので、コードベース上の **証拠** を探す。証拠の取り方は以下のパターンに分類できる:
+
+| 章の種類 | 確認方法 | 例 |
+| :--- | :--- | :--- |
+| ツールのインストール要件 | `command --version` を順に実行 | `ghc --version`, `dbmate --version` |
+| 設定ファイルの存在 | `ls path/to/file` | `.husky/pre-commit`, `weeder.toml` |
+| package.json scripts | `grep \"name\":` で網羅 | `lint`, `test:tdd` |
+| Docker サービス定義 | `docker-compose.yml` を読み内容を照合 | postgres / adminer / mailhog |
+| ディレクトリ構造 | `ls` / `find -maxdepth N` | `src/Cargotracker/Booking/Domain/...` |
+| CI/CD ワークフロー | `ls .github/workflows/` | `ci.yml`, `cd-staging.yml` |
+| ドキュメント記載のみの規約 | 内容を読み「ドキュメントに記載済」を ✅ とする | 命名規則、Git 規約 |
+
+並列で確認できるものは 1 つの Bash 呼び出しに詰めると速い。
+
+### 3. 判定基準
+
+| 記号 | 判定基準 |
+| :--- | :--- |
+| ✅ 完了 | 手順書の記述どおりに揃っている。コマンド成功 / ファイル存在 / scripts に記載あり |
+| ⚠️ 部分対応 / IT で補完 | 「スタブはあるが本実装はこれから」「コマンドは動くがテスト本体は IT1 で追加」など、骨格はあるが中身は実装フェーズで足す類 |
+| ❌ 未対応 | 手順書に書いてあるが存在しない / 動かない |
+
+迷ったら **「新メンバーがこの手順書だけ見て進めた時に詰まるか?」** を基準にする。詰まるなら ❌、詰まらないなら ✅/⚠️。
+
+### 4. 表の書式
+
+章番号と章タイトルを左 2 列に保持し、内訳項目を行に展開する。
+
+```markdown
+| 章 | 内容 | 状態 | 備考 |
+| :--- | :--- | :--- | :--- |
+| **1. 前提条件** | GHC 9.10.x | ❌ | `ghc` コマンド未配置 |
+| | Stack 3.x | ✅ | 3.11.1 |
+| | Cabal 3.12.x | ❌ | 未インストール |
+| **2. プロジェクト取得** | `npm install` 実施 | ✅ | node_modules 存在 |
+```
+
+備考列には **証拠** (バージョン番号、ファイルパス、検出結果) を入れる。「OK」だけだと後から見て情報がなくなる。
+
+### 5. サマリ表
+
+```markdown
+| ステータス | 件数 |
+| :--- | ---: |
+| ✅ 完了 | N |
+| ⚠️ 部分対応 / IT で補完 | N |
+| ❌ 未対応 | N |
+```
+
+### 6. 分類別の推奨対処
+
+A〜D の各バケツに、ID 付き (A1, A2, ...) で項目を並べる。各項目には **アクション** (具体的なコマンドや作業内容) を書く。
+
+```markdown
+### A. 今すぐ対応可能 (運用補強)
+
+| # | 項目 | 推奨アクション |
+| :--- | :--- | :--- |
+| A1 | `dbmate` インストール | `brew install dbmate` |
+| A2 | husky + lint-staged | `npm i -D husky lint-staged && npx husky init` |
+```
+
+### 7. 着手提案
+
+最後に 1〜2 行で「A 全部やる」「A1〜A3 だけ先に着手」のような選択肢を提示する。**ユーザーが `y` や 「A 全部やって」 のような短い返答で動けるようにする**。
+
+## 注意事項
+
+- **手順書を改変しない** — このスキルは「現状を手順書に合わせる」のが仕事。手順書の方を現状に合わせて編集するのは別タスク (operating-docs)
+- **「手順書に書かれていないこと」は対象外** — スコープを広げると報告がボヤけるため、章番号にない項目は無視する。ただし手順書に欠落がある場合は最後に「手順書側の改善提案」として 1 セクション設けて構わない
+- **証拠の収集は並列化** — Bash 呼び出しは並列実行できる。複数の `command --version` は 1 つのコマンドにまとめて出力する
+- **手順書のバージョンアップ時に再実行する想定** — 章番号や項目が変わっても、このスキルの進め方は変わらない
+
+## 関連スキル
+
+- `operating-setup` — 監査対象の手順書を生成する側のスキル
+- `operating-docs` — 手順書側の改善が必要になった場合
+- `operating-script` — 手順書で参照される Gulp タスクの実装
+- `tracking-progress` — プロジェクト全体の進捗確認 (より広い視点)