菜单
プッシュ前に必ず実行。静的チェック・テスト・統合レビュー含む6ペルソナレビューを最低2サイクル実施し、自己改善確認後のみpush可能。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Git worktree を使った並列開発時に使用。配置・ポート割当・環境コピー・クリーンアップを標準化する。
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
作業完了前にセッション内の改善ポイントを抽出し、ユーザー承認後にルール・スキル・ドキュメントへ反映する。
開発サーバー・E2E・ブラウザ検証時に使用。既存プロセスを停止してからプロジェクト指定ポートで起動し、作業後に必ず停止する。
Use when creating new skills, editing existing skills, or verifying skills work before deployment
機能・サービス・要件・前提条件などプロジェクトの知識をドキュメント化する。新規機能/サービスを作るとき、または既存機能を変更するときに必ず実行。新規ならドキュメントを作成、既存があれば更新する。
| name | quality-check |
| description | プッシュ前に必ず実行。静的チェック・テスト・統合レビュー含む6ペルソナレビューを最低2サイクル実施し、自己改善確認後のみpush可能。 |
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可能
quality-check 本体に入る前に、機能ドキュメントが最新の変更を反映しているかを必ず確認する。
git diff --name-only origin/main...HEAD
得られた変更ファイル一覧から、以下の いずれか に該当するなら feature-documentation スキルが完了している必要がある：
| 状況 | アクション |
|---|---|
| 上記いずれにも該当しない（純粋な内部リファクタ・バグ修正など） | 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 ファイルへの変更を指す。判定に迷った場合はユーザーに確認する。
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）が実行される。
プロジェクトの CLAUDE.md または設定ファイルに定義された静的チェックコマンドを実行する。
プロジェクトの CLAUDE.md または設定ファイルに定義されたテストコマンドを実行する。
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 |
backend / frontend のコード変更を含まない場合、ペルソナセットとサイクル数を縮退してレビューコストを抑える。
| 変更領域 | 適用ペルソナ | 最低サイクル数 |
|---|---|---|
| docs のみ | 要件・仕様整合性レビュアー、ソフトウェアアーキテクト、セキュリティエンジニア | 1 |
| infra のみ | セキュリティエンジニア、統合アーキテクチャレビュー、パフォーマンスエンジニア | 1 |
| docs + infra | 上記2セットの和集合（5ペルソナ） | 1 |
| コード変更を含む（backend / frontend / 複合） | 6ペルソナ全て | 2 |
縮退時の注意：
.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、要件ドキュメント、設計ドキュメント、受け入れ条件、ドメイン用語、過剰実装・不足実装、ドキュメント乖離 | 実装が「正しいものを作っているか」を確認し、仕様の取りこぼしや余計な振る舞いを検出する |
Agentツールで6つのサブエージェントを同時に起動する。各サブエージェントには「使用モデル（必須）」のとおり最高精度モデルを明示指定する。
各ペルソナには以下を指示する：
あなたは[ペルソナ名]として、以下の変更差分をレビューしてください。
## あなたの専門性
[ペルソナの説明]
## レビュー対象
`git diff origin/main...HEAD` の変更差分
## レビューガイドライン
[該当するreview-*.mdの内容]
## あなたの重点観点
[ペルソナの重点観点]
上記の観点を中心に、review-*.mdのチェック項目も参照しつつレビューしてください。
## ペルソナ固有の補足
（以下から、起動するペルソナに該当する行のみを含めること。他ペルソナ向けの行は含めない）
- 統合アーキテクチャレビュー: 個別ファイルではなく、変更全体の整合性・依存方向・副作用を重視してください。
- パフォーマンスエンジニア: 計算量、クエリ、バンドル、キャッシュ、リソース効率の劣化を重視してください。
- 要件・仕様整合性レビュアー: Issue、要件、設計、ドキュメント、受け入れ条件と実装の一致を重視してください。
## 出力形式
以下の形式で指摘を出力してください：
- 必須修正事項（優先度: 高）: ファイルパス、行番号、問題の説明、修正コード例
- 推奨改善事項（優先度: 中）: ファイルパス、問題の説明、改善案
- 軽微な提案（優先度: 低）: 内容
- 良い点: 良い実装の評価
指摘がない場合は「✅ 指摘なし」と明記。
6つのサブエージェントの結果を統合する：
各サイクルの結果を .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）以上完了していること。
変更領域別ステップ適用テーブルでE2E欄が「-」の場合はこのステップをスキップし、Step 5.75に進む。
サーバーが起動していない場合は、server-startupスキルに従って自動的に起動すること。
E2Eテスト完了後、サーバーを必ず停止する。起動したまま放置するとプロセスが大量に残りリソースを消費する。
停止確認後、Step 5.75に進む。
.quality-check-passed を作成する前に、self-improvement スキルを実行する。
確認すること：
.cursorrules / documents/development/coding-rules/ / project スキルに反映すべき恒久改善があるか候補がない場合も、.quality-check-report.json に self_improvement.status = "not_required" を記録してから Step 6 に進む。
Step 4-4で作成済みの.quality-check-report.jsonに最終結果フィールドを追記する。
全チェック通過後、以下のコマンドでフラグファイルを作成する：
touch .quality-check-passed
feature-documentation スキルが完了している（または対象外と判定された）git diff に含まれている（対象の場合）.quality-check-passedフラグファイル作成済み