quality-check

name	quality-check
description	プッシュ前に必ず実行。静的チェック・テスト・統合レビュー含む6ペルソナレビューを最低2サイクル実施し、自己改善確認後のみpush可能。

Quality Check Skill - プッシュ前品質チェック

最重要ルール

git pushの前に必ずこのスキルを実行すること。全チェック通過後のみpush可能。

CIはビルド確認のみ。静的チェック・テスト・レビューは全てローカルで実施する。

---

実行フロー

Step 0: ドキュメント更新の確認（feature-documentation）
  ↓
Step 1: 変更領域の判定
  ↓
Step 2: 静的チェック（該当領域）
  ↓
Step 3: ユニットテスト（該当領域）
  ↓
Step 4: レビューサイクル（コード変更: 6ペルソナ×最低2回 / docs・infraのみ: 縮退ペルソナ×最低1回）
  ├── 4a: マルチペルソナ・レビュー（ペルソナ並列）
  ├── 指摘あり → 修正 → Step 2に戻る
  └── 指摘なし & 必要サイクル数完了 → Step 5へ
  ↓
Step 5: E2Eテスト（最終確認）
  ├── 問題あり → 修正 → Step 2に戻る（サイクルカウント継続）
  └── 問題なし → Step 5.5へ
  ↓
Step 5.5: サーバー停止（E2Eテスト後に必須）
  ↓
Step 5.75: 自己改善候補の確認（self-improvement）
  ↓
Step 6: レポートデータ保存 + フラグファイル作成 → push可能

---

Step 0: ドキュメント更新の確認（feature-documentation）

quality-check 本体に入る前に、機能ドキュメントが最新の変更を反映しているかを必ず確認する。

判定ロジック

git diff --name-only origin/main...HEAD

得られた変更ファイル一覧から、以下の いずれか に該当するなら feature-documentation スキルが完了している必要がある：

• 新規ファイルの追加（リネーム/移動を除く）が含まれる
• 公開 API / 公開インターフェースのシグネチャ変更が含まれる
• 設定ファイル / インフラ定義 / 依存関係の意味のある変更が含まれる
• 振る舞い（仕様）の変更が含まれる

アクション

状況	アクション
上記いずれにも該当しない（純粋な内部リファクタ・バグ修正など）	documentation.status = "not_required" を .quality-check-report.json に記録して Step 1 へ進む
該当するが、関連ドキュメントの更新差分が git diff に含まれている	documentation.status = "updated" を記録して Step 1 へ進む
該当するが、ドキュメント更新差分が git diff に含まれていない	エラー: feature-documentation スキルを先に実行するようユーザーに促し、Step 1 に進まない

「ドキュメント更新差分」とは、documents/ docs/ 配下、または README 等のプロジェクトドキュメント .md ファイルへの変更を指す。判定に迷った場合はユーザーに確認する。

---

Step 1: 変更領域の判定

git diff --name-only origin/main...HEAD

変更ファイルのパスから以下の領域を判定する：

パスパターン	領域
backend/**	backend
frontend/**	frontend
documents/**, *.md	docs
.github/workflows/**, Dockerfile, docker-compose.yml	infra

複数領域に変更がある場合は、全ての該当領域のチェックを実施する。

変更領域別ステップ適用テーブル

変更領域	Step 2（静的チェック）	Step 3（テスト）	Step 4（レビュー）	Step 5（E2E）
backend	バックエンド静的チェックコマンド	バックエンドテストコマンド	review-backend.md + 統合レビュー	E2Eテストコマンド
frontend	フロントエンド静的チェックコマンド	フロントエンドテストコマンド	review-frontend.md + 統合レビュー	E2Eテストコマンド
docs	-	-	review-docs.md + 統合レビュー	-
infra	該当ビルドコマンド	-	review-infra.md + 統合レビュー	-
複合	各領域の静的チェックを全て実行	各領域のテストを全て実行	各領域のレビューガイド + 統合レビュー	E2Eテストコマンド

docs/infraのみの変更ではStep 2, 3, 5がスキップされ、縮退レビュー（Step 4「レビュー縮退ルール」参照）とStep 5.75（self-improvement）が実行される。

---

Step 2: 静的チェック（全て必須）

プロジェクトの CLAUDE.md または設定ファイルに定義された静的チェックコマンドを実行する。

---

Step 3: ユニットテスト（全て必須）

プロジェクトの CLAUDE.md または設定ファイルに定義されたテストコマンドを実行する。

---

Step 4: マルチペルソナ・レビュー（全て必須）

概要

6つの異なる専門家ペルソナによるレビューを実施し、各ペルソナの指摘を統合する。 各ペルソナは並列のサブエージェントとして実行する。

使用モデル（必須）

レビューはpush/merge可否を直接左右するため、必ず利用可能な最高精度モデルを明示指定して実行する。デフォルト（メイン会話のモデル継承）に任せないこと。

ハーネス	モデル指定方法
Claude Code	Taskツールの model パラメータに claude-opus-4-8 を明示指定
Codex	サブエージェントに model = "gpt-5.5" / model_reasoning_effort = "high" を明示指定
Cursor	サブエージェント起動時に Claude Opus 4.8 を優先指定。次点で Claude Sonnet 5、Codex GPT-5.5 high はベンダー多様性のための代替肢（Fableはレビューでは使わない）

レビュー対象ガイドライン

変更領域に応じて、以下のレビューガイドラインを参照する：

領域	参照ファイル
backend	.github/review-backend.md
frontend	.github/review-frontend.md
docs	.github/review-docs.md
infra	.github/review-infra.md

加えて、以下のペルソナは変更領域に関わらず専用ガイドを併用する：

ペルソナ	参照ファイル
パフォーマンスエンジニア	.github/review-performance.md
要件・仕様整合性レビュアー	.github/review-requirements.md

レビュー縮退ルール（docs/infraのみの変更）

backend / frontend のコード変更を含まない場合、ペルソナセットとサイクル数を縮退してレビューコストを抑える。

変更領域	適用ペルソナ	最低サイクル数
docs のみ	要件・仕様整合性レビュアー、ソフトウェアアーキテクト、セキュリティエンジニア	1
infra のみ	セキュリティエンジニア、統合アーキテクチャレビュー、パフォーマンスエンジニア	1
docs + infra	上記2セットの和集合（5ペルソナ）	1
コード変更を含む（backend / frontend / 複合）	6ペルソナ全て	2

縮退時の注意：

• 縮退時もペルソナは並列サブエージェントとして実行し、指示テンプレート・出力形式・統合手順は通常時と同じ
• 必須修正（優先度: 高）が残る限り、縮退時でもサイクルを繰り返す
• docs のみの変更でのセキュリティ観点は、機密情報の混入（資格情報、内部URL、個人情報）の検出に絞る
• 縮退の適用有無と適用ペルソナを .quality-check-report.json の各サイクルに記録する

ペルソナ定義

Pass	ペルソナ	重点観点	説明
1	セキュリティエンジニア	脆弱性、認証・認可、データ漏洩、インジェクション、機密情報管理、依存パッケージの既知脆弱性、CSP/CORS設定、サプライチェーン攻撃（依存パッケージ整合性・lockfile一貫性・typosquatting）	攻撃者視点でコードを精査する。OWASP Top 10 (2021)の観点を網羅的にチェックする
2	ソフトウェアアーキテクト	設計原則（SOLID/DRY）、レイヤー責務、依存関係、拡張性、API設計の後方互換性、レスポンスペイロード設計	長期的な保守性・拡張性の観点で評価する。API設計ルール（api-design-rules.md）への準拠もチェックする
3	QAエンジニア	エッジケース、テスト網羅性、バグの可能性、エラーハンドリング、データ整合性、アクセシビリティ基本要件	壊れるシナリオを徹底的に探す。フロントエンド変更時はキーボード操作可能性・セマンティックHTML・基本的なARIA属性もチェックする
4	統合アーキテクチャレビュー	変更全体の整合性、レイヤー依存方向、既存パターン一貫性、副作用、クエリパフォーマンス	個別ファイルではなく変更全体を俯瞰してレビューする。N+1問題やインデックス未設定など、統合的に発生するパフォーマンス問題もチェックする
5	パフォーマンスエンジニア	アルゴリズム計算量、メモリ・リソース効率、クエリ実行計画、バンドルサイズ、キャッシュ戦略、スケーラビリティ	性能劣化・過剰な再計算・不要な通信・将来的な負荷増加を専門的にレビューする
6	要件・仕様整合性レビュアー	Issue、要件ドキュメント、設計ドキュメント、受け入れ条件、ドメイン用語、過剰実装・不足実装、ドキュメント乖離	実装が「正しいものを作っているか」を確認し、仕様の取りこぼしや余計な振る舞いを検出する

実行手順

4-1. 6ペルソナを並列でサブエージェント実行

Agentツールで6つのサブエージェントを同時に起動する。各サブエージェントには「使用モデル（必須）」のとおり最高精度モデルを明示指定する。

各ペルソナには以下を指示する：

あなたは[ペルソナ名]として、以下の変更差分をレビューしてください。

## あなたの専門性
[ペルソナの説明]

## レビュー対象
`git diff origin/main...HEAD` の変更差分

## レビューガイドライン
[該当するreview-*.mdの内容]

## あなたの重点観点
[ペルソナの重点観点]
上記の観点を中心に、review-*.mdのチェック項目も参照しつつレビューしてください。

## ペルソナ固有の補足
（以下から、起動するペルソナに該当する行のみを含めること。他ペルソナ向けの行は含めない）
- 統合アーキテクチャレビュー: 個別ファイルではなく、変更全体の整合性・依存方向・副作用を重視してください。
- パフォーマンスエンジニア: 計算量、クエリ、バンドル、キャッシュ、リソース効率の劣化を重視してください。
- 要件・仕様整合性レビュアー: Issue、要件、設計、ドキュメント、受け入れ条件と実装の一致を重視してください。

## 出力形式
以下の形式で指摘を出力してください：
- 必須修正事項（優先度: 高）: ファイルパス、行番号、問題の説明、修正コード例
- 推奨改善事項（優先度: 中）: ファイルパス、問題の説明、改善案
- 軽微な提案（優先度: 低）: 内容
- 良い点: 良い実装の評価

指摘がない場合は「✅ 指摘なし」と明記。

4-2. 指摘の統合

6つのサブエージェントの結果を統合する：

1. 全ペルソナの指摘を集約
2. 重複する指摘をマージ（同一箇所・同一内容の指摘を統合）
3. 統合レビュー結果を出力

4-3. サイクルルール

• コード変更を含む場合は最低2サイクル実行（指摘ゼロでも2回完走。拡充した6ペルソナで検出漏れを防ぐ）
• docs/infraのみの変更は最低1サイクル（「レビュー縮退ルール」参照。指摘があれば必須修正0件まで継続）
• 必須修正（優先度: 高）が0件になるまで何度でも繰り返す
• 優先度に関わらず、対応できるものは全て対応すること
• 修正後はStep 2（静的チェック）から再実行
• 10サイクル到達時はユーザーに判断を仰ぐ

4-4. レポートデータ蓄積

各サイクルの結果を .quality-check-report.json に保存する。

完全なスキーマ定義は _schemas/quality-check-report.schema.md を参照。

JSONフォーマット例：

{
  "cycles": [
    {
      "cycle_number": 1,
      "findings": [
        {
          "source": "セキュリティエンジニア",
          "severity": "高",
          "description": "SQLインジェクション対策確認",
          "action": "対応済",
          "detail": "バインドパラメータ使用を確認"
        }
      ]
    }
  ],
  "total_cycles": 2,
  "e2e_result": "pass",
  "e2e_issues": [],
  "documentation": {
    "status": "updated",
    "files": ["documents/features/user-authentication.md"]
  },
  "self_improvement": {
    "status": "not_required",
    "candidates": []
  }
}

完了条件

適用した全ペルソナから「必須修正事項（優先度: 高）」が0件であり、かつ必要サイクル数（コード変更: 2 / 縮退時: 1）以上完了していること。

---

Step 5: E2Eテスト（最終確認）

変更領域別ステップ適用テーブルでE2E欄が「-」の場合はこのステップをスキップし、Step 5.75に進む。

サーバーが起動していない場合は、server-startupスキルに従って自動的に起動すること。

• 問題あり: 修正してStep 2に戻る（サイクルカウントは継続し、リセットしない）
• 問題なし: Step 5.5へ進む

---

Step 5.5: サーバー停止（E2Eテスト後に必須）

E2Eテスト完了後、サーバーを必ず停止する。起動したまま放置するとプロセスが大量に残りリソースを消費する。

停止確認後、Step 5.75に進む。

---

Step 5.75: 自己改善候補の確認（self-improvement）

.quality-check-passed を作成する前に、self-improvement スキルを実行する。

確認すること：

• セッション中に同じエラー、手戻り、確認不足が繰り返されていないか
• CLAUDE.md / AGENTS.md / .cursorrules / documents/development/coding-rules/ / project スキルに反映すべき恒久改善があるか
• 改善候補がある場合、ユーザーへ適用可否を確認したか
• 承認された改善を同じブランチ内で反映し、必要な検証を再実行したか

候補がない場合も、.quality-check-report.json に self_improvement.status = "not_required" を記録してから Step 6 に進む。

---

Step 6: レポートデータ保存 + フラグファイル作成

レポートデータ保存

Step 4-4で作成済みの.quality-check-report.jsonに最終結果フィールドを追記する。

フラグファイル作成

全チェック通過後、以下のコマンドでフラグファイルを作成する：

touch .quality-check-passed

---

チェックリスト

ドキュメント更新（Step 0）

• feature-documentation スキルが完了している（または対象外と判定された）
• 機能ドキュメントの更新差分が git diff に含まれている（対象の場合）

静的チェック + ユニットテスト

• バックエンド: 静的チェック + テスト成功
• フロントエンド: Lint + フォーマット + ビルド成功
• フロントエンド: テスト成功

マルチペルソナ・レビュー（縮退時は適用ペルソナのみ）

• セキュリティエンジニア視点レビュー完了
• ソフトウェアアーキテクト視点レビュー完了
• QAエンジニア視点レビュー完了
• 統合アーキテクチャレビュー完了
• パフォーマンスエンジニア視点レビュー完了
• 要件・仕様整合性レビュー完了
• 統合レビュー結果で必須修正事項0件（必要サイクル数以上完了）
• レポートデータ保存完了

E2Eテスト

• E2Eテスト成功

最終確認

• self-improvementスキルで自己改善候補を確認済み
• .quality-check-passedフラグファイル作成済み