メニュー
キャッシュ・状態遷移の整合性を検証する。キャッシュ（localStorage/ghosts.db）・fingerprint・request_key・DB スキーマ・状態管理に触れる変更をしたとき、または「/cache-check」と言われたときに使う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | cache-check |
| description | キャッシュ・状態遷移の整合性を検証する。キャッシュ（localStorage/ghosts.db）・fingerprint・request_key・DB スキーマ・状態管理に触れる変更をしたとき、または「/cache-check」と言われたときに使う。 |
多層キャッシュと永続データの整合性が変更後も保たれているか検証する。
CACHE_SCHEMA のハッシュを user_version に刻み、不一致なら起動時に全 DROP+CREATE で自動リビルド（フルスキャンで再投入）ghost_launches の唯一の住処。JS からアクセスしないsrc-tauri/CLAUDE.md「SQLite」節と SPEC.md §4.5/§6.6 を参照localStorage と SQLite は独立にリセットされうる。変更後も以下が成り立つか確認する:
DELETE FROM が混入していないかghosts.id（再投入で変わる）でなく ghost_identity_key を使っているかlast_launched / launch_count は user-data.db から再導出可能な導出キャッシュ。更新経路が両方揃っているか確認する:
record_launch が INSERT と同時に ghosts 側を UPDATE しているかscan_and_store のキャッシュ再構築後に集計を書き戻しているか片方だけ変更すると、スキャンのたびに集計がずれる。
ghosts.db はマイグレーションを持たない（CACHE_SCHEMA が単一権威・ハッシュ user_version 不一致で全リビルド）。スキーマに触れる変更で確認する:
cache_schema.rs の CACHE_SCHEMA の直接編集で行われているか（アクター外・別経路の DDL を足していないか）launch_history::ensure_schema の追加式のみ。検査 2 も参照）委譲: DB スキーマ変更を含む場合、インデックス設計・クエリ効率の詳細検査は
sqlite-tuningサブエージェントが一次担当。このスキルは 2 層キャッシュ整合の観点に絞り、重複検査を避ける。
新しい状態・フラグ・キャッシュキーを追加した場合:
検査 1〜5 それぞれについて ✅ / ⚠️（根拠 file:line 付き）を報告する。
ドキュメントと実装の整合性を定期検査する。ユーザーが「ヘルスチェック」「整合性チェック」「/health-check」と言ったとき、またはサイクル完了後の点検を頼まれたときに使う。検出のみで修正はしない（報告のみ）。
コード変更（機能追加・バグ修正・リファクタリング）のフルサイクルを実行する。ユーザーが「実装して」「直して」「対応して」等のコード変更を依頼したとき、または「/implement」と言ったときに使う。
ユーザーが「PR 作って」「PR お願い」「/pr」と言ったとき、または作業完了後に PR 作成を依頼されたときに使う。コミット済みの作業ブランチ（main 以外）で使うことを想定している。
サイクル終了後の振り返りを定型化する。ユーザーが「振り返りして」「レトロスペクティブ」「/retrospective」と言ったときに使う。
cargo/npm の依存を一括更新し検証する。ユーザーが「依存更新して」「deps 更新」「/deps-update」と言ったときに使う。
PR マージ後に main をローカル同期し、作業ブランチを後始末する。ユーザーが「マージ後の同期」「post-merge-sync」「ブランチ片付けて」と言ったとき、または PR のマージ後に使う。