/post-start-validation

タスク完了後に実行します。変更内容を検出し、ガバナンスゲートを適用し、ナレッジを記録し、コミットして検証します。

---

0. シェルルール

OSを検出します。Windows上ではGit Bashの構文を使用します(フォワードスラッシュ、/dev/null)。

---

1. スコープの決定

git diff --name-only HEAD 2>/dev/null || git status --short

ファイルパターンを検出して変更を分類します:

• フロントエンド? — .ts、.tsx、.js、.jsx、.css、.vue、.svelte ファイル
• バックエンド? — .java、.kt、.py、.go、.rs、.rb ファイル
• インフラストラクチャ? — Dockerfile、docker-compose*、k8s/、.github/workflows/、*.tf
• ドキュメントのみ? — ソースディレクトリ外の .md ファイルのみ

スキップルール: ドキュメントのみ → コードチェックをスキップ。インフラのみ → ローカルチェックをスキップ。

---

2. ガバナンスゲートを読む

Read .claude/governance.md

ガバナンスファイルは、どのゲートを実行し、どの順序で実行するかを定義します。「biome → tsc → build」と指定されている場合は正確にそれを実行します。「pytest」と指定されている場合はそれを実行します。ゲートはプロジェクト固有です。このスキルは汎用的です。

---

3. ゲートの実行

3.0. ワークスペース対応のゲート実行

検出キャッシュがワークスペースを示している場合:

1. ルートガバナンスゲートを読む(ワークスペースルートの .claude/governance.md から)
2. どのメンバーが変更されたかを特定: git diff --name-only HEAD パスをチェック
3. 変更されたメンバーが独自のガバナンスを持つ場合: メンバーガバナンスを読み、ルートゲートとマージ
4. マージされたゲートを順番に実行: ルートクロススタックゲートを先に、その後メンバー固有のゲート

ゲートアノテーション(v2形式)

パススコープセクション: ### Frontend (path: frontend/) このセクションのコマンドを実行する前に、指定されたディレクトリに cd します。セクション完了後、プロジェクトルートに戻ります。例:

(cd frontend/ && npx biome check .) || exit 1

条件付きセクション: ### TypeScript (if: tsconfig.json) 参照されるファイルがプロジェクトルートに存在しない場合、セクション全体をスキップします。セクション内のゲートを実行する前にチェック:

[ -e tsconfig.json ] || echo "Skipping TypeScript gates (no tsconfig.json)"

ゲート分類(個別ゲート行のサフィックス):

• # [MANDATORY](デフォルト) — 失敗時に実行を停止
• # [OPTIONAL] — 失敗をログに記録し、警告を出力して次のゲートに続行
• # [ADVISORY] — 常に実行し、結果をログに記録し、停止しない

OPTIONALゲートが失敗した場合:

1. 出力: ⚠ [OPTIONAL] <ゲートコマンド> failed — continuing
2. gate_results.failedに記録するが、終了しない
3. 次のゲートに進む

ADVISORYゲートが失敗した場合:

1. 出力: ℹ [ADVISORY] <ゲートコマンド> failed (informational)
2. セッション状態のgate_results.failedに記録
3. 常に続行

継承マーカー: ## Gates (inherit: root) メンバーのgovernance.mdに見つかった場合、ルートゲートをマージして先に実行し、メンバーゲートを最後に追加します。順番に実行します。

標準実行(アノテーションなし)

governance.mdで定義されたゲートを順番に実行します。最初のMANDATORY失敗で停止します。

一般的なパターン(ガバナンスファイルがどれが適用されるかを指定します):

フロントエンドゲート:

# Lint (biome, eslint, など)
# Type check (tsc --noEmit, mypy, など)
# Build (npm run build, など)
# Test (vitest, jest, pytest, など)

バックエンドゲート:

# Compile (gradlew compileJava, cargo build, go build, など)
# Test (gradlew test, pytest, cargo test, go test, など)
# Check (gradlew check, clippy, など)

トークン圧縮のためすべてのコマンドに rtk プレフィックスを使用してください。

---

3.5. ゲート自動修正(制限付き再試行)

ゲートコマンドが失敗した場合、ユーザーにエスカレートする前に自動修正を試みます。

ステップ1 — 失敗を分類:

エラーパターン	分類	アクション
自動修正フラグ付きのlintエラー	自動修正可能	--fix / --write でlinterを実行
フォーマットエラー(prettier、rustfmt、ruff、biome)	自動修正可能	影響を受けたファイルでフォーマッターを実行
未使用のインポート/変数	自動修正可能	削除
セミコロン欠落、末尾のカンマ欠落	自動修正可能	インラインで修正
このセッションで変更したファイルの型エラー	修正可能かもしれない	修正を1回試み、再実行
テスト失敗	自動修正不可	エスカレート — テストは変更を検証している可能性
欠落依存関係からのビルドエラー	自動修正不可	エスカレート
変更しなかったファイル内のエラー	自動修正不可	エスカレート — 既存の問題

ステップ2 — 自動修正可能な場合、修正を適用:

# Lint自動修正(プロジェクトが持つものを使用)
npx eslint --fix <files>           # または: npx biome check --write <files>
npx prettier --write <files>       # フォーマット
cargo clippy --fix --allow-dirty   # Rust
ruff check --fix <files>           # Python
ruff format <files>                # Pythonフォーマット

その他の機械的なエラー(未使用のインポート、セミコロン欠落): ファイルを直接編集します。

自動修正の境界:

• このリポジトリ内のファイルのみ編集
• 修正として新しいグローバルパッケージをインストール しない
• リポジトリ外またはシステム設定のファイルを変更しない
• このセッションで作成されなかったファイルを削除しない
• 修正が範囲外の変更を必要とする場合 → ユーザーにエスカレート

ステップ3 — 失敗したゲートのみを再実行。 既に成功したゲートは再実行しません。

ステップ4 — 制限付き再試行:

• ゲートごとに最大 2回の自動修正試行
• 2回の試行後同じゲートが失敗する場合 → 停止してユーザーにエスカレート
• 機能しなかった同じ修正を再試行しない
• サーキットブレーカーフック(PostToolUseFailure)は追加の安全ネットを提供

ステップ5 — すべてのゲートが成功した後、センチネルを書く:

touch .claude/.gates-passed

このセンチネルは:

• 自動ポストスタートフックがコミット前に チェック
• 各セッションの開始時にpre-start-contextで クリア
• ゲートがコミット前にセッションごとに少なくとも1回検証されることを保証

---

4. クロススタック一貫性

フロントエンドとバックエンド両方が変更された場合、アライメントを確認:

• APIコントラクトが一致(ルート、型、スキーマ)
• 新しい環境変数が .env.example に追加
• サービスが変更された場合、Docker/K8sコンフィグを更新
• マイグレーションファイルが競合しない

プロジェクト固有のアライメントポイントについてgovernance.mdを参照してください。

---

5. セキュリティレビュー

Grep -rn "sk_live\|sk_test\|AKIA\|password.*=.*['\"]" . --type ts --type java --type py 2>/dev/null | grep -v node_modules | grep -v test | grep -v example | head -20

追加されたすべての新しいエンドポイント/ルートについて:

• 認証が必要?(明示的に公開でない限り)
• 入力検証が存在?
• マスアサインメントなし(生のエンティティバインディングではなく、明示的なDTO)?

プロジェクト固有のセキュリティ要件(レート制限、ファイルアップロードルール、認証パターン)についてgovernance.mdを参照してください。

---

6. ドキュメント

新しいエンドポイント、サービス、環境変数、またはアーキテクチャ変更が導入された場合 — READMEを更新します。

変更がバグ修正、リファクタリング、テスト、CSS の場合 — スキップします。

---

7. ナレッジキャプチャ

MemStackルールが存在する場合(.claude/rules/diary.md)、それに従う — add-insight、add-session、set-context。

存在しない場合、最低限報告:

• 実施内容
• 主要な決定とその理由
• 発見した落とし穴
• 次のセッションでやること

---

8. 自己更新

確認: このセッション中にガバナンスルールに違反しましたか? 検出命令が予期しないものを見つけましたか?

ガバナンスが違反された場合: ユーザーにフラグを立てる。governance.mdを変更しない。

pre-startまたはpost-startスキル自体にギャップがあった場合(チェック欠落、誤った仮定): スキルファイルを更新します。変更をログに記録します。

検出命令は更新が必要なことはめったにありません — ファイルシステムを読みます。ガバナンスルールはユーザーが決定したときのみ変更します。

---

9. コミットとデプロイ

ガバナンスを読む.md:

• ブランチ戦略(フィーチャーブランチまたはトランク型ベース?)
• コミット規約(conventional commitsまたは自由形式?)
• 自律性レベル(ゲート後に自動コミットまたは最初に確認?)

それに応じて実行:

git add <files>
git commit -m "<type>: <description>

Co-Authored-By: Claude <noreply@anthropic.com>"

その後:

• リモートにプッシュ
• CI監視(設定されている場合): gh run list --limit 3
• デプロイメントを検証(ガバナンスで指定されている場合)

ブランチクリーンアップ(フィーチャーブランチワークフロー使用時)

マージ後:

git branch -d <branch-name>

---

スキップルール

変更タイプ	スキップ
ドキュメントのみ	S3-S5
インフラのみ	S3(ローカルゲート)、S6
バックエンドのみ(API変更なし)	フロントエンドゲート
フロントエンドのみ(API変更なし)	バックエンドゲート
CSS/スタイリングのみ	バックエンドゲート、S4、S5

---

10. セッション状態を書く

次のセッションのウォームスタートのために .claude/.session-state.json を書きます:

{
  "version": 1,
  "timestamp": "<ISO 8601 — 使用: date -u +%Y-%m-%dT%H:%M:%SZ>",
  "branch": "<現在のブランチ>",
  "commit": "<HEADショートハッシュ>",
  "task_summary": "<達成された内容の1行要約>",
  "gate_results": {
    "passed": ["<成功したゲートコマンド>"],
    "failed": ["<失敗したゲートコマンド — すべて成功した場合は空>"],
    "auto_fixed": ["<成功する前に自動修正が必要だったゲート>"]
  },
  "files_changed": ["<このセッションで変更されたファイル>"],
  "open_questions": ["<未解決の決定または曖昧さ>"],
  "next_steps": ["<次のセッションで推奨されるアクション>"]
}

このファイルはpre-startのセクション0.1によってウォームスタート用に使用されます。次のセッションを有効にします:

• ユーザーが同じ作業を続けている場合、コンテキストを再説明をスキップ
• オープンクエスチョンと次のステップを即座に表示
• 検出キャッシュと組み合わせて、ほぼゼロレイテンシーのスタートアップを実現