arch-security-review

Codex 互換性に関する注意：

• Codex では $skill-name を使ってリポジトリのスキルを呼び出します。このミラー版では、従来の Claude の /skill-name への参照を書き換えています。
• タスクトラッカーの必須要件：ワークフローまたはスキルの手順を実行する前に、すべての手順のタスク追跡を作成または更新し、進捗に応じて同期を維持してください。
• ユーザーへの質問を促す指示は、Codex でユーザーに直接質問するという意味です。
• Claude 固有のモード切り替え指示がある場合は無視してください。
• 厳格な実行契約：ユーザーがスキルを明示的に呼び出した場合、そのスキルのプロトコルを記載どおりに実行してください。
• サブエージェントの使用許可：スキルがユーザーによって呼び出された場合、または AI によって検出され、そのプロトコルでサブエージェントが必要な場合、そのスキルの有効化によって、当該タスクに必要な spawn_agent サブエージェントの使用が許可されます。
• ユーザーが事前に逸脱を明示的に承認しない限り、プロトコルの手順を省略、並べ替え、統合しないでください。
• ワークフロースキルでは、記載された各子スキルの手順を明示的に実行し、手順ごとの証拠を報告してください。
• 必須の手順またはツールをこの環境で実行できない場合は、適応する前に停止してユーザーに確認してください。

Codex のプロジェクト参照ドキュメントの読み込み（フックなし）

Codex では、Claude のフックによるドキュメントの自動注入は行われません。 コーディング、計画、デバッグ、テスト、レビューを行う際は、このルーティングに従ってプロジェクトのドキュメントを明示的に開いてください。

必ず読むもの：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー／テストの設定）
• docs/project-reference/docs-index-reference.md（docs/project-reference/* カタログ全体へのルート）
• docs/project-reference/lessons.md（常時適用するガードレールとアンチパターン）

状況に応じたドキュメント：

• バックエンド／CQRS／API／ドメイン／エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド／UI／スタイル／デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様／テストケースの計画、または TC のマッピング：feature-docs-reference.md
• 統合テストの実装／レビュー：integration-test-reference.md
• E2E テストの実装／レビュー：e2e-test-reference.md
• コードレビュー／監査作業：変更対象のファイルに応じて、上記のドメインドキュメントに加えて code-review-rules.md

ドキュメントを一律にすべて読むのではなく、docs-index-reference.md から始め、タスクに関連するファイルのみを開いてください。

クイックサマリー

目標： OWASP Top 10 に照らしてコードのセキュリティ脆弱性をレビューし、認可、データ保護、安全なコーディングパターンを徹底します。

ワークフロー：

1. 事前確認 — セキュリティ上重要な領域を特定し、OWASP との関連性を確認して、既存のパターンをレビューします
2. OWASP 監査 — 10 のカテゴリすべて（アクセス制御、インジェクション、認証など）に照らしてコードを評価します
3. プロジェクトの確認 — 認可属性、エンティティアクセス式、入力検証を確認します
4. レポート — 重大度、脆弱なコードと安全なコードの例を含めて、指摘事項を記録します

主なルール：

• バックエンドとフロントエンドの両方の攻撃対象領域を必ず確認してください
• プロジェクトの認可属性とエンティティレベルのアクセス式を使用し、UI のみのガードに依存しないでください（docs/project-reference/backend-patterns-reference.md を参照）
• すべての外部データをプロジェクトの検証 API で検証し、クライアントの入力を決して信頼しないでください（docs/project-reference/backend-patterns-reference.md を参照）

懐疑的に検討してください。批判的思考と順を追った思考を適用してください。すべての主張に、追跡可能な証拠と信頼度（Idea は 80% を超える必要があります）が必要です。

セキュリティレビューワークフロー

このスキルを使用する場面

• コード変更のセキュリティ監査
• 認証／認可の実装
• データ保護のレビュー
• 脆弱性の評価

事前確認チェックリスト

• セキュリティ上重要な領域を特定する
• OWASP Top 10 との関連性を確認する
• 既存のセキュリティパターンを確認する
• 修正アプローチを計画する

OWASP Top 10 チェックリスト

1. アクセス制御の不備

// :x: VULNERABLE - No authorization check
[HttpGet("{id}")]
public async Task<Employee> Get(string id)
    => await repo.GetByIdAsync(id);

// :white_check_mark: SECURE - Authorization enforced
[HttpGet("{id}")]
[Authorize(Roles.Manager, Roles.Admin)] // project authorization attribute (see docs/project-reference/backend-patterns-reference.md)
public async Task<Employee> Get(string id)
{
    var employee = await repo.GetByIdAsync(id);

    // Verify access to this specific resource
    if (employee.CompanyId != RequestContext.CurrentCompanyId())
        throw new UnauthorizedAccessException();

    return employee;
}

2. 暗号化の失敗

// :x: VULNERABLE - Storing plain text secrets
var apiKey = config["ApiKey"];
await SaveToDatabase(apiKey);

// :white_check_mark: SECURE - Encrypt sensitive data
var encryptedKey = encryptionService.Encrypt(apiKey);
await SaveToDatabase(encryptedKey);

// Use secure configuration
var apiKey = config.GetValue<string>("ApiKey");  // From Azure Key Vault

3. インジェクション

// :x: VULNERABLE - SQL Injection
var sql = $"SELECT * FROM Users WHERE Name = '{name}'";
await context.Database.ExecuteSqlRawAsync(sql);

// :white_check_mark: SECURE - Parameterized query
await context.Users.Where(u => u.Name == name).ToListAsync();

// Or if raw SQL needed:
await context.Database.ExecuteSqlRawAsync(
    "SELECT * FROM Users WHERE Name = @p0", name);

4. 安全でない設計

// :x: VULNERABLE - No rate limiting
[HttpPost("login")]
public async Task<IActionResult> Login(LoginRequest request)
    => await authService.Login(request);

// :white_check_mark: SECURE - Rate limiting applied
[HttpPost("login")]
[RateLimit(MaxRequests = 5, WindowSeconds = 60)]
public async Task<IActionResult> Login(LoginRequest request)
    => await authService.Login(request);

5. セキュリティ設定の不備

// :x: VULNERABLE - Detailed errors in production
app.UseDeveloperExceptionPage();  // Exposes stack traces

// :white_check_mark: SECURE - Generic errors in production
if (env.IsDevelopment())
    app.UseDeveloperExceptionPage();
else
    app.UseExceptionHandler("/Error");

6. 脆弱なコンポーネント

# Check for vulnerable packages
dotnet list package --vulnerable

# Update vulnerable packages
dotnet outdated

7. 認証の不備

// :x: VULNERABLE - Weak password policy
if (password.Length >= 4) { }

// :white_check_mark: SECURE - Strong password policy
public class PasswordPolicy
{
    public bool Validate(string password)
    {
        return password.Length >= 12
            && password.Any(char.IsUpper)
            && password.Any(char.IsLower)
            && password.Any(char.IsDigit)
            && password.Any(c => !char.IsLetterOrDigit(c));
    }
}

8. データ完全性の不備

// :x: VULNERABLE - No validation of external data
var userData = await externalApi.GetUserAsync(id);
await SaveToDatabase(userData);

// :white_check_mark: SECURE - Validate external data
var userData = await externalApi.GetUserAsync(id);
var validation = userData.Validate();
if (!validation.IsValid)
    throw new ValidationException(validation.Errors);
await SaveToDatabase(userData);

9. ログ記録の不備

// :x: VULNERABLE - Logging sensitive data
Logger.LogInformation("User login: {Email} {Password}", email, password);

// :white_check_mark: SECURE - Redact sensitive data
Logger.LogInformation("User login: {Email}", email);
// Never log passwords, tokens, or PII

10. SSRF（サーバーサイドリクエストフォージェリ）

// :x: VULNERABLE - User-controlled URL
var url = request.WebhookUrl;
await httpClient.GetAsync(url);  // Could access internal services

// :white_check_mark: SECURE - Validate and restrict URLs
if (!IsAllowedUrl(request.WebhookUrl))
    throw new SecurityException("Invalid webhook URL");

private bool IsAllowedUrl(string url)
{
    var uri = new Uri(url);
    return AllowedDomains.Contains(uri.Host)
        && uri.Scheme == "https";
}

認可パターン

⚠️ 必ず確認してください： 認可コントローラー／ハンドラーパターン、RequestContext の使用方法、エンティティレベルのアクセスフィルターについては、CLAUDE.md を参照してください（docs/project-reference/backend-patterns-reference.md を参照）。

データ保護

機密データの取り扱い

public class SensitiveDataHandler
{
    // Encrypt at rest
    public string EncryptForStorage(string plainText)
        => encryptionService.Encrypt(plainText);

    // Mask for display
    public string MaskEmail(string email)
    {
        var parts = email.Split('@');
        return $"{parts[0][0]}***@{parts[1]}";
    }

    // Never log sensitive data
    public void LogUserAction(User user)
    {
        Logger.LogInformation("User action: {UserId}", user.Id);
        // NOT: Logger.Log("User: {Email} {Phone}", user.Email, user.Phone);
    }
}

ファイルアップロードのセキュリティ

public async Task<IActionResult> Upload(IFormFile file)
{
    // Validate file type
    var allowedTypes = new[] { ".pdf", ".docx", ".xlsx" };
    var extension = Path.GetExtension(file.FileName).ToLowerInvariant();
    if (!allowedTypes.Contains(extension))
        return BadRequest("Invalid file type");

    // Validate file size
    if (file.Length > 10 * 1024 * 1024)  // 10MB
        return BadRequest("File too large");

    // Scan for malware (if available)
    if (!await antivirusService.ScanAsync(file))
        return BadRequest("File rejected by security scan");

    // Generate safe filename
    var safeFileName = $"{Guid.NewGuid()}{extension}";

    // Save to isolated storage
    await fileService.SaveAsync(file, safeFileName);

    return Ok();
}

セキュリティスキャンコマンド

# .NET vulnerability scan
dotnet list package --vulnerable

# Outdated packages
dotnet outdated

# Secret scanning
grep -r "password\|secret\|apikey" --include="*.cs" --include="*.json"

# Hardcoded credentials
grep -r "Password=\"" --include="*.cs"
grep -r "connectionString.*password" --include="*.json"

セキュリティレビューのチェックリスト

認証

• 強力なパスワードポリシーが適用されている
• ログイン失敗後にアカウントがロックされる
• セッションが安全に管理されている
• JWT トークンが適切に検証されている
• リフレッシュトークンがローテーションされる

認可

• すべてのエンドポイントで認証が必要
• ロールベースのアクセス制御が実装されている
• リソースレベルの権限が確認されている
• 権限昇格が不可能

入力検証

• すべての入力が検証されている
• SQL インジェクションが防止されている（パラメーター化クエリ）
• XSS が防止されている（出力エンコーディング）
• ファイルアップロードが検証されている
• リダイレクト先の URL が検証されている

データ保護

• 機密データが保存時に暗号化されている
• HTTPS が強制されている
• ログに機密データが含まれていない
• 適切なエラー処理が行われている（スタックトレースを表示しない）

依存関係

• 既知の脆弱性があるパッケージがない
• 依存関係が定期的に更新されている
• サードパーティーコードがレビューされている

避けるべきアンチパターン

:x: クライアントの入力を信頼する

var isAdmin = request.IsAdmin;  // User-supplied!

:x: 内部エラーを公開する

catch (Exception ex) { return BadRequest(ex.ToString()); }

:x: シークレットをハードコードする

var apiKey = "sk_live_xxxxx";

:x: ログ記録が不十分

// No audit trail for sensitive operations
await DeleteAllUsers();

検証チェックリスト

• OWASP Top 10 を確認した
• 認証／認可を検証した
• 入力検証が完了している
• 機密データが保護されている
• シークレットがハードコードされていない
• 適切にログが記録されている（PII を含まない）
• 依存関係をスキャンした

関連項目

• arch-performance-optimization
• arch-cross-service-integration
• code-review

---

[IMPORTANT] 作業を始める前に、タスク管理を使ってすべての作業を小さなタスクに分割してください。各ファイルを読むタスクも含めてください。長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合、AI はスキップするかどうかを必ずユーザーに尋ねてください。

• docs/project-reference/domain-entities-reference.md — ドメインエンティティのカタログ、関連、サービス間同期（ビジネスエンティティ／モデルが関係するタスクで読む）（該当する場合は直接読むこと。フックによって会話に挿入されたテキストに依存しないこと）

重要な目的： 品質を確保すること — 欠陥、バグ、更新漏れ、古い内容がないようにしてください。コードとドキュメントの両方を検証してください。 AI のミス防止 — すべてのタスクで避けるべき失敗パターン：

削除する前に、依存先の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードに古さが波及します。削除する前に、参照しているファイルをすべて洗い出してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドのシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後は依存関係の全体をたどってください。 定義を変更しても、そこから派生する下流の変数や利用箇所が見落とされることがあります。必ず依存関係を最後までたどってください。 正しさを検証するときは、すべてのコードパスをたどってください。 コードが存在することを確認しても、実行されることを確認したことにはなりません。正常系だけでなく、早期終了、エラー分岐、条件によるスキップも必ずたどってください。 デバッグ時は、修正する前に「どちらの責任か」を確認してください。 バグの原因が呼び出し元（誤ったデータ）なのか、呼び出し先（不適切な処理）なのかをたどってください。責任のある層を修正し、症状が現れている箇所だけにパッチを当てないでください。 既存の値には意図があると考え、変更前に理由を確認してください。 定数、上限値、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受ける出力をすべて検証してください。 複数のスタックに関わる変更では、すべての出力を検証する必要があります。チェックが 1 つ成功しても、すべてのチェックが成功したことにはなりません。 全体を先に見るデバッグ — 目の前の問題に飛びつかないでください。 失敗を調査するときは、まず前提条件をすべて列挙してください（設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件）。その後、コード層の仮説を立てる前に、それぞれを証拠と照合してください。 変更は最小限に — 差分テストを適用してください。 バグ修正では、変更する各行がバグに直接結び付いている必要があります。隣接するコードのスタイル変更や改善はしないでください。機能改善タスクでは、改善を実装し、その内容を明確に伝えてください。 実装前に曖昧さを明らかにし、黙って決めないでください。 依頼に複数の解釈がある場合は、それぞれの工数見積もりを示して確認してください。全レコード対象、ファイルベース、またはより複雑な方法だと決めつけないでください。

ネストされたタスクの展開ルール — ワークフローのステップを呼び出す場合、[Workflow] ... の行は親コンテナにすぎません。子スキルによって、フェーズタスクも引き続き表示されます。

1. まず現在のタスクリストを取得してください。一致するアクティブな親ワークフローの行がある場合は nested=true を設定し、parentTaskId を記録してください。それ以外の場合は単独で実行します。
2. フェーズ作業を始める前に、宣言された各フェーズにつきタスクを 1 つ作成してください。ネストされている場合は、件名の先頭に [N.M] $skill-name — phase を付けてください。
3. ネストされている場合は、TaskUpdate(parentTaskId, addBlockedBy: [childIds]) で親タスクにリンクしてください。
4. オーケストレーターは、子スキルまたはサブエージェントを呼び出す前に、子スキルのフェーズ一覧を展開し、ワークフローの行をリンクする必要があります。
5. 作業前に子タスクをちょうど 1 つ in_progress にし、証拠を記録した直後に completed にしてください。
6. すべての子タスクが完了するか、理由を明記して明示的にキャンセルされた後にのみ、親タスクを完了してください。

以下が完了するまでブロック： 現在のタスクリストの取得、子フェーズの作成、ネストされている場合の親タスクへのリンク、最初の子タスクの in_progress 設定。 プロジェクト参照ドキュメントのゲート — タスク追跡の初期設定後、対象ファイルやソースファイルの読み込み、grep、編集、分析を始める前に実行します。プロジェクトのドキュメントは、一般的なフレームワークの前提より優先されます。

1. 対象範囲を特定します。ファイルの種類、ドメイン領域、操作内容を確認します。
2. 条件に応じた必須ドキュメント：常に docs/project-reference/lessons.md、ドキュメント検索時は docs-index-reference.md、レビュー時は code-review-rules.md、バックエンド／CQRS／API は backend-patterns-reference.md、ドメイン／エンティティは domain-entities-reference.md、フロントエンド／UI は frontend-patterns-reference.md、スタイル／デザインは scss-styling-guide.md + design-system/design-system-canonical.md、統合テストは integration-test-reference.md、E2E は e2e-test-reference.md、機能ドキュメント／仕様は feature-docs-reference.md、アーキテクチャ／新しい領域は project-structure-reference.md。
3. 存在する必須ドキュメントをすべて読みます。存在しないドキュメントは該当なしとしてスキップします。[Injected: <path>] のような会話内のテキストを、現在のコンテキストにドキュメントが含まれている証拠として信用しないでください。
4. 対象作業に入る前に、次の形式で明示します：参照ドキュメントを読了：... | 不足／該当なし：...。

次の条件を満たすまで作業不可： 対象範囲の評価、必須ドキュメントの確認と読了、lessons.md の確認、参照情報の明示が完了していること。

タスク追跡と外部レポートの保存 — 実行前にこれを初期設定し、その後、対象／ソースの作業に入る前にプロジェクト参照ドキュメントの事前取得を行います。

1. 対象ファイルの読み込み、grep、編集、分析を始める前に、小規模なタスク分解を作成します。コンテキストが失われた場合は、まず現在のタスクリストを確認します。
2. 作業開始前にタスクを1つ in_progress にし、根拠を得た直後に completed にします。状態の変更をまとめて行わないでください。
3. 計画／レビュー作業では、最初の所見を得る前に plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md を作成します。
4. 各ファイル／セクション／判断の後に所見を追記し、最後にレポートファイルをもとに内容をまとめます。
5. 最終出力で Full report: plans/reports/{filename} を示します。

次の条件を満たすまで作業不可： タスク分解が作成されていること、計画／レビュー作業ではレポートパスが宣言されていること、次の所見に進む前に最初の所見が保存されていること。

批判的思考の姿勢 — 批判的思考と段階的な思考を適用します。行動を起こすには、すべての主張に追跡可能な根拠があり、確信度が80％を超えている必要があります。 ハルシネーション防止： 推測を事実として示してはいけません。すべての主張に出典を示し、不確実な場合は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信は、あらゆるハルシネーションの根源です。

根拠に基づく推論 — 推測は禁止です。すべての主張に根拠が必要です。

1. すべての主張について、file:line、grep の結果、またはフレームワークのドキュメントを引用します。
2. 確信度を明示します：80％超ならそのまま進め、60～80％なら先に検証し、60％未満なら推奨してはいけません。
3. アーキテクチャの変更には、サービス間の検証が必要です。
4. 「根拠が十分ではありません」は妥当であり、期待される出力です。

次の条件を満たすまで作業不可： - [ ] 根拠となるファイルパス（file:line） - [ ] grep 検索の実施 - [ ] 類似パターンを3つ以上確認 - [ ] 確信度の明示

根拠なしでの使用禁止： 「明らかに」「私はこう思います」「～のはずです」「おそらく」「これは～が原因です」 未完了の場合は次を出力： "根拠が不十分です。確認済み：[...]。未確認：[...]。" 修正を契機とする再レビューのループ — 再レビューはラウンド番号ではなく、修正サイクルを契機に実行します。レビューの目的は、問題が見つからなくなるまで「レビュー → 問題があれば修正 → 再レビュー」を繰り返すことです。問題のないレビューでループは終了します。それ以上のラウンドは不要です。

ラウンド 1： メインセッションでレビューします。対象ファイルを読み、内容を把握し、問題点を記録します。指摘事項と判定（PASS / FAIL）を出力します。

ラウンド 1 の後の判断：

• 問題が見つからない（PASS、指摘事項ゼロ） → レビューを終了します。確認のために新しいサブエージェントを起動してはいけません。
• 問題が見つかった（FAIL、または指摘事項が 1 件以上） → 問題を修正してから、新しいサブエージェントを起動し、ラウンド 2 の再レビューを行います。

新しいサブエージェントによる再レビュー（修正サイクルのたびに実施）： spawn_agent ツールを新たに呼び出してください。以前のエージェントを再利用してはいけません。サブエージェントは、以前のラウンドの記憶を一切持たずに、すべてのファイルを最初から読み直します。起動方法については SYNC:fresh-context-review を、標準のエージェントプロンプトテンプレートについては SYNC:review-protocol-injection を参照してください。新しいラウンドでは、次の点を必ず確認します。

• 前のラウンドで見落とされた、複数の箇所にまたがる懸念事項
• 変更されたファイル間の相互作用によるバグ
• 既存のパターンに対する規約の乖離（新しいコードと既存のパターンとの不一致）
• 存在すべきなのに欠けている要素
• 前のラウンドで正当化され、見過ごされた微妙なエッジケース
• 修正自体によって生じたリグレッション

ループの終了条件： 新しいラウンドのたびに、同じ判断を繰り返します。問題がなければ終了し、問題があれば修正して次の新しいラウンドに進みます。問題が 0 件になるまで、または 新しいサブエージェントによるラウンドを最大 3 回実施するまで続けます。上限に達したら、ユーザーに直接質問してエスカレーションします。

ルール：

• 問題のないラウンド 1 でレビューは終了します。ラウンド 2 は必須ではありません。
• 修正サイクルの後に、新しいサブエージェントによる再レビューを絶対に省略してはいけません（修正のたびに、以前の判定は無効になります）。
• ラウンドをまたいでサブエージェントを絶対に再利用してはいけません。反復のたびに、新しい Agent 呼び出しを実行します。
• メインエージェントはサブエージェントの報告を読みますが、指摘事項を選別、再解釈、または覆してはいけません。
• レビューあたり、新しいサブエージェントによるラウンドは最大 3 回です。それでも FAIL の場合は、ユーザーに直接質問してエスカレーションします（黙ってループを続けてはいけません）。
• 会話コンテキストでラウンド数を管理します（セッション単位）。
• 最終判定には、実施したすべてのラウンドを反映させます。

実施したラウンド N（N≥2）ごとに、レポートに ## Round N Findings (Fresh Sub-Agent) を含める必要があります。 新規サブエージェントによるレビュー — 独立したサブエージェントを利用して、オーケストレーターの確証バイアスを排除します。

理由： メインエージェントは、自分自身（または $cook）が直前に修正した内容を把握しているため、それに合わせて指摘を合理化してしまいます。新規サブエージェントには記憶がまったくなく、最初から読み直すことで、メインエージェントが退けた問題を見つけられます。サブエージェントのバイアスは、（1）新しいコンテキスト、（2）プロトコルの逐語的な埋め込み、（3）メインエージェントがレポートをフィルタリングしないことによって軽減されます。

タイミング： 修正サイクルの後にのみ実施します。問題がゼロのレビューラウンドではループを終了します。確認のためのサブエージェントを起動してはいけません。問題が見つかったレビューラウンドでは、修正後に新規サブエージェントで再レビューします。

方法：

1. 新しい spawn_agent ツール呼び出しを作成します。コードレビューには code-reviewer の agent_type を、計画／ドキュメント／成果物のレビューには general-purpose を使用します。
2. 必要なレビュー用プロトコルをすべて、プロンプトに逐語的に埋め込みます。完全なリストとテンプレートについては SYNC:review-protocol-injection を参照してください。ファイルパスでプロトコルを参照してはいけません。ファイル読み込みの間接参照を介すると、AI の遵守率が低下します（SYNC:shared-protocol-duplication-policy を参照）。
3. サブエージェントは、独自のツール呼び出しを使って、対象ファイルをすべて最初から読み直します。ファイルの内容をプロンプトに直接渡してはいけません。
4. サブエージェントは、構造化されたレポートを plans/reports/{review-type}-round{N}-{date}.md に書き込みます。
5. メインエージェントはレポートを読み、自身のレポートに指摘を反映します。指摘を上書きしたり、フィルタリングしたりしてはいけません。

ルール：

• 直前のラウンドで問題がゼロだった場合は、新規サブエージェントを起動しません（修正がなければ、新たに検証するものはありません）。
• 修正サイクル後に新規サブエージェントを起動しないことは禁止です。修正のたびに、それまでの判定は無効になります。
• ラウンドをまたいで同じサブエージェントを再利用してはいけません。新しいラウンドごとに、新しい spawn_agent 呼び出しを作成します。
• レビューごとに新規サブエージェントのラウンドは最大 3 回です。それでも問題が解決しない場合は、ユーザーに直接質問してエスカレーションします。ループを黙って続けたり、以前のプロトコルに戻したりしてはいけません。
• 会話コンテキスト内で反復回数を追跡します（セッション内のみ。永続ファイルは使用しません）。

レビュープロトコルの埋め込み — 新規サブエージェントのレビュー用プロンプトには、10 個のプロトコルブロックをすべて逐語的に埋め込む必要があります。以下のテンプレートには、10 個すべての本文がインラインで展開済みです。実行時にテンプレート全体を Agent 呼び出しの prompt フィールドにコピーし、Task ／ Round ／ Reference Docs ／ Target Files ／ Output セクションの {placeholders} のみ、コンテキストに応じた値に置き換えてください。埋め込み済みのプロトコルセクションには手を加えてはいけません。

インライン展開の理由： プレースホルダーマーカーを使うと、実行時にファイル読み込みの間接参照が必要になります。間接参照を介すると AI の遵守率が大幅に低下します（SYNC:shared-protocol-duplication-policy を参照）。そのため、このテンプレートには 10 個すべてのプロトコル本文があらかじめ埋め込まれています。

サブエージェントの種類の選択

• code-reviewer — コードレビュー（ソースファイル、git 差分、実装のレビュー）
• general-purpose — 計画／ドキュメント／成果物のレビュー（Markdown の計画、ドキュメント、仕様のレビュー）

標準 Agent 呼び出しテンプレート（逐語的にコピー）

spawn_agent({
  description: "Fresh Round {N} review",
  agent_type: "code-reviewer",
  prompt: `
## Task
{review-specific task — e.g., "Review all uncommitted changes for code quality" | "Review plan files under {plan-dir}" | "Review integration tests in {path}"}

## Round
Round {N}. You have ZERO memory of prior rounds. Re-read all target files from scratch via your own tool calls. Do NOT trust anything from the main agent beyond this prompt.

## Protocols (follow VERBATIM — these are non-negotiable)

### Evidence-Based Reasoning
Speculation is FORBIDDEN. Every claim needs proof.
1. Cite file:line, grep results, or framework docs for EVERY claim
2. Declare confidence: >80% act freely, 60-80% verify first, <60% DO NOT recommend
3. Cross-service validation required for architectural changes
4. "I don't have enough evidence" is valid and expected output
BLOCKED until: Evidence file path (file:line) provided; Grep search performed; 3+ similar patterns found; Confidence level stated.
Forbidden without proof: "obviously", "I think", "should be", "probably", "this is because".
If incomplete → output: "Insufficient evidence. Verified: [...]. Not verified: [...]."

### Bug Detection
MUST check categories 1-4 for EVERY review. Never skip.
1. Null Safety: Can params/returns be null? Are they guarded? Optional chaining gaps? .find() returns checked?
2. Boundary Conditions: Off-by-one (< vs <=)? Empty collections handled? Zero/negative values? Max limits?
3. Error Handling: Try-catch scope correct? Silent swallowed exceptions? Error types specific? Cleanup in finally?
4. Resource Management: Connections/streams closed? Subscriptions unsubscribed on destroy? Timers cleared? Memory bounded?
5. Concurrency (if async): Missing await? Race conditions on shared state? Stale closures? Retry storms?
6. Stack-Specific: JS: === vs ==, typeof null. C#: async void, missing using, LINQ deferred execution.
Classify: CRITICAL (crash/corrupt) → FAIL | HIGH (incorrect behavior) → FAIL | MEDIUM (edge case) → WARN | LOW (defensive) → INFO.

### Design Patterns Quality
Priority checks for every code change:
1. DRY via OOP: Same-suffix classes (*Entity, *Dto, *Service) MUST share base class. 3+ similar patterns → extract to shared abstraction.
2. Right Responsibility: Logic in LOWEST layer (Entity > Domain Service > Application Service > Controller). Never business logic in controllers.
3. SOLID: Single responsibility (one reason to change). Open-closed (extend, don't modify). Liskov (subtypes substitutable). Interface segregation (small interfaces). Dependency inversion (depend on abstractions).
4. After extraction/move/rename: Grep ENTIRE scope for dangling references. Zero tolerance.
5. YAGNI gate: NEVER recommend patterns unless 3+ occurrences exist. Don't extract for hypothetical future use.
Anti-patterns to flag: God Object, Copy-Paste inheritance, Circular Dependency, Leaky Abstraction.

### Logic & Intention Review
Verify WHAT code does matches WHY it was changed.
1. Change Intention Check: Every changed file MUST serve the stated purpose. Flag unrelated changes as scope creep.
2. Happy Path Trace: Walk through one complete success scenario through changed code.
3. Error Path Trace: Walk through one failure/edge case scenario through changed code.
4. Acceptance Mapping: If plan context available, map every acceptance criterion to a code change.
5. Tests Verify Intent: For test/spec changes, verify tests name the protected business rule or invariant and would fail if that intent breaks.
6. Migration Test Exclusion: Do not write tests for migration code. Schema/data migrations are one-time execution paths, not core application logic.
NEVER mark review PASS without completing both traces (happy + error path).

### Test Spec Verification
Map changed code to test specifications.
1. Identify the project's test/spec format from existing docs, test-case files, BDD feature files, or spec folders.
2. Every changed code path MUST map to a corresponding test case/spec (or flag as "needs test case").
3. New functions/endpoints/handlers → flag for test spec creation.
4. Migration files are excluded from test/spec creation; schema/data migrations are one-time execution paths, not core application logic.
5. If spec evidence fields exist, verify they point to actual code (file:line, not stale references).
6. Verify each meaningful test case names the business intent/invariant; flag behavior-only cases that only mirror implementation details.
7. Auth/data changes → verify corresponding authorization and data-state test cases exist.
8. If no specs exist for a changed path → log the gap and recommend the project's test-spec workflow.
NEVER skip test mapping. Untested code paths are the #1 source of production bugs.

### Behavioral Delta Matrix
MANDATORY for any bugfix review. Produce input-state × pre-fix × post-fix × delta table BEFORE writing verdict.
- Minimum 3 rows; include at least one row OUTSIDE the original bug report.
- Any "REGRESSION" delta → review returns FAIL until a preservation test is added.
- Narrative descriptions do NOT substitute for the matrix.
Example rows (external-record sync fix):
| Input                 | Pre-fix | Post-fix                  | Delta      |
| --------------------- | ------- | ------------------------- | ---------- |
| Record exists (valid) | Reused  | Always recreated → orphan | REGRESSION |
| Record missing (404)  | Error   | Recreated                 | Fixed      |

### Fix-Layer Accountability
NEVER fix at the crash site. Trace the full flow, fix at the owning layer. The crash site is a SYMPTOM, not the cause.
MANDATORY before ANY fix:
1. Trace full data flow — Map the complete path from data origin to crash site across ALL layers (storage → backend → API → frontend → UI). Identify where bad state ENTERS, not where it CRASHES.
2. Identify the invariant owner — Which layer's contract guarantees this value is valid? Fix at the LOWEST layer that owns the invariant, not the highest layer that consumes it.
3. One fix, maximum protection — If fix requires touching 3+ files with defensive checks, you are at the wrong layer — go lower.
4. Verify no bypass paths — Confirm all data flows through the fix point. Check for direct construction skipping factories, clone/spread without re-validation, raw data not wrapped in domain models, mutations outside the model layer.
BLOCKED until: Full data flow traced (origin → crash); Invariant owner identified with file:line evidence; All access sites audited (grep count); Fix layer justified (lowest layer that protects most consumers).
Anti-patterns (REJECT): "Fix it where it crashes" (crash site ≠ cause site, trace upstream); "Add defensive checks at every consumer" (scattered defense = wrong layer); "Both fix is safer" (pick ONE authoritative layer).

### Rationalization Prevention
AI skips steps via these evasions. Recognize and reject:
- "Too simple for a plan" → Simple + wrong assumptions = wasted time. Plan anyway.
- "I'll test after" → RED before GREEN. Write/verify test first.
- "Already searched" → Show grep evidence with file:line. No proof = no search.
- "Just do it" → Still need task tracking. Skip depth, never skip tracking.
- "Just a small fix" → Small fix in wrong location cascades. Verify file:line first.
- "Code is self-explanatory" → Future readers need evidence trail. Document anyway.
- "Combine steps to save time" → Combined steps dilute focus. Each step has distinct purpose.

### Graph-Assisted Investigation
MANDATORY when .code-graph/graph.db exists.
HARD-GATE: MUST run at least ONE graph command on key files before concluding any investigation.
Pattern: Grep finds files → trace --direction both reveals full system flow → Grep verifies details.
- Investigation/Scout: trace --direction both on 2-3 entry files
- Fix/Debug: callers_of on buggy function + tests_for
- Feature/Enhancement: connections on files to be modified
- Code Review: tests_for on changed functions
- Blast Radius: trace --direction downstream
CLI: python .claude/scripts/code_graph {command} --json. Use --node-mode file first (10-30x less noise), then --node-mode function for detail.

### Understand Code First
HARD-GATE: Do NOT write, plan, or fix until you READ existing code.
1. Search 3+ similar patterns (grep/glob) — cite file:line evidence.
2. Read existing files in target area — understand structure, base classes, conventions.
3. Run python .claude/scripts/code_graph trace <file> --direction both --json when .code-graph/graph.db exists.
4. Map dependencies via connections or callers_of — know what depends on your target.
5. Write investigation to .ai/workspace/analysis/ for non-trivial tasks (3+ files).
6. Re-read analysis file before implementing — never work from memory alone.
7. NEVER invent new patterns when existing ones work — match exactly or document deviation.
BLOCKED until: Read target files; Grep 3+ patterns; Graph trace (if graph.db exists); Assumptions verified with evidence.

## Reference Docs (READ before reviewing)
- docs/project-reference/code-review-rules.md
- {skill-specific reference docs — e.g., integration-test-reference.md for integration-test-review; backend-patterns-reference.md for backend reviews; frontend-patterns-reference.md for frontend reviews}

## Target Files
{explicit file list OR "run git diff to see uncommitted changes" OR "read all files under {plan-dir}"}

## Output
Write a structured report to plans/reports/{review-type}-round{N}-{date}.md with sections:
- Status: PASS | FAIL
- Issue Count: {number}
- Critical Issues (with file:line evidence)
- High Priority Issues (with file:line evidence)
- Medium / Low Issues
- Cross-cutting findings

Return the report path and status to the main agent.
Every finding MUST have file:line evidence. Speculation is forbidden.
`
})

ルール

• テンプレート全体をそのままコピーしてください。埋め込み済みのプロトコルセクション10個もすべて含めてください。

• Task / Round / Reference Docs / Target Files / Output セクション内の {placeholders} だけを、状況に応じた内容に置き換えてください。

• コードレビューには code-reviewer の agent_type を、計画／ドキュメント／成果物のレビューには general-purpose を選んでください。

• プロトコルセクションを言い換えたり、要約したり、省略したりしないでください。

• ファイルの内容をインラインで渡さないでください。サブエージェントは自身のツール呼び出しで読み取るため、新鮮なコンテキストを得られます。

• ファイルパスやタグ名でプロトコルを参照しないでください。本文はすでに上記に埋め込まれています。

• プロトコル用のプレースホルダーマーカーを追加しないでください。展開済みの状態をそのまま保ってください。

• 必須・重要・必ず注意 すべての主張に file:line の根拠を示してください。行動する場合は確信度80％超、60％未満の場合は推奨しないでください。

必ず注意 批判的思考を適用してください。すべての主張に追跡可能な証拠が必要です。行動する場合は確信度80％超としてください。ハルシネーション防止のため、推測を事実として提示しないでください。

必ず注意 AI の誤りを防止してください。全体を優先してデバッグし、責任のあるレイヤーで修正し、コーディング前に曖昧さを明らかにし、コンパクション後にファイルを読み直してください。

• 必須 対象作業に着手する前にタスク追跡を開始してください。タスクは一度に1つずつ移行してください。

• 必須 計画／レビューの所見は plans/reports/ に段階的に保存し、ディスクから内容を統合してください。

• 必須 タスク追跡の開始後、対象／ソースの作業に着手する前に、必須のプロジェクト参照ドキュメントを読み、「Reference docs read: ...」と記載してください。

• 必須 常に lessons.md を含めてください。プロジェクトの規約は一般的な既定値より優先されます。

• 必須 親ワークフローの行で子フェーズの追跡を代用しないでください。ネストする場合はフェーズを展開し、親を紐付けてください。

• 必須 オーケストレーターは実行前に子スキルのフェーズを展開してください。[N.M] $skill-name — phase のプレフィックスを使用し、同時に in_progress にできるタスクは1つだけです。

最後の確認事項

• 必須・重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな ToDo タスクに分割してください。
• 必須・重要・必ず注意 新しいコードを作成する前に、コードベース内で類似パターンを3つ以上検索してください。
• 必須・重要・必ず注意 すべての主張に file:line の根拠を示してください（行動する場合は確信度80％超）。
• 必須・重要・必ず注意 作業の品質を確認するため、最終レビューの ToDo タスクを追加してください。
• 必須・重要・必ず注意 SYNC:double-round-trip-review に従って複数ラウンドのレビューを実施してください。ラウンド1はメインセッションで、ラウンド2以降は SYNC:fresh-context-review と SYNC:review-protocol-injection に従って、都度、新しい code-reviewer サブエージェントを起動して実施してください。 必須・重要・必ず注意 作業を始める前に、以下のファイルを必ず読んでください。

[TASK-PLANNING] 行動を開始する前に、タスクの範囲を分析し、タスク追跡を使って小さな ToDo タスクとサブタスクに体系的に分割してください。

Hookless Prompt Protocol Mirror（自動同期）

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・厳守。いかなる理由があっても省略しないでください。

汎用的な移植性の境界： 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は、docs/project-config.json と docs/project-reference/ から確認してください。shared/sdd-artifact-contract.md の共通 AI-SDD を適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクト参照ドキュメントを開いてください。この共通コンテキストとローカルドキュメントを利用できる場合は、サポートされている任意の AI ツールで実行できます。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： 最適なワークフローを見つけ、カスタムのステップ構成のほうが適しているかどうかも評価します
3. 確認（必須形式）： ユーザーが明示的にワークフロー／スキルを呼び出し、かつローカルプロトコルで明示的な呼び出しを確認とみなす場合を除き、次の構成でユーザーに直接質問します
   • 質問："どのワークフローを有効にしますか？"
   • 選択肢 1："[最適なワークフロー] を有効にする（推奨）"
   • 選択肢 2："カスタムワークフローを有効にする：[step1 → step2 → ...]"（1 行で理由を記載）
4. 有効化（確認後）： 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップの場合は手動で順に実行します
5. タスクを作成： ワークフローのすべてのステップについてタスク追跡を行います
6. 実行： 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。すべての主張には追跡可能な根拠が必要であり、確信度が 80% を超える場合にのみ行動します。 ハルシネーション防止の原則： 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそが、あらゆるハルシネーションの根本原因です。 AI の注意力に関する原則（初頭効果・新近効果）： 長いプロンプト／プロトコルでは、指示の順守が長いコンテキストウィンドウでも保たれるよう、最も重要な 3 つのルールを冒頭と末尾の両方に配置します。 目標主導の実行： まず成功基準を定義し、検証が完了するまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストで意図を検証： テストでは、現在の挙動をなぞるだけでなく、ビジネスルール／不変条件を保護し、保護対象の意図が損なわれた場合に失敗するようにします。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分割し、タスク追跡を行います。最後のタスクとして「AI のミスと教訓を分析する」を追加します。

教訓の抽出 — 症状への対処ではなく、根本原因のみ：

1. 症状ではなく、失敗モード（推論／前提の誤り）を特定します。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
2. 一般性を検証します。この失敗モードは 3 つ以上のコンテキスト／コードベースに当てはまりますか？ 当てはまらない場合は、抽象度を 1 段階上げます。
3. 普遍的なルールとして記述します。プロジェクト固有の名前／パス／クラスを除き、どのコードベースでも役立つ内容にします。
4. 統合します。同じ失敗モードを共有する複数のミスは、1 つの教訓にまとめます。
5. 再発判定：「この注意書きがなければ、今後のセッションで再発するか？」いいえの場合は $learn を省略します。
6. 自動修正判定：「$code-review／$code-simplifier／$security／$lint で検出できるか？」はいの場合は、代わりにレビュー用スキルを改善します。
7. 両方の判定を通過した場合： $learn を実行するようユーザーに依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、予定されているすべてのステップのタスク追跡を作成／更新し、各ステップの開始時と完了時に内容を同期してください。