---
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` — プロジェクト全体の進捗確認 (より広い視点)