aif-verify

Verify — 実装後の品質チェック

実装が完了し、計画どおりに実装されていること、抜け漏れがないこと、本番環境で使用できる状態であることを確認します。

このスキルは任意です。/aif-implement がすべてのタスクを完了した後に呼び出すか、いつでも手動で実行できます。

---

Step 0: コンテキストを読み込む

0.0 config.yaml を読み込む

最初に： .ai-factory/config.yaml が存在する場合は読み込み、以下を解決します。

• パス： paths.description、paths.architecture、paths.rules_file、paths.roadmap、paths.research、paths.plan、paths.plans、paths.fix_plan、paths.specs、paths.rules、paths.archive。また、research_bundles_dir = <parent directory of paths.research>/research/ を導出します。
• verify_mode： デフォルトの検証厳格度（strict | normal | lenient）
• Git： git.enabled、git.base_branch、git.create_branches
• ルール階層： 解決された RULES.md のパス + rules.base + 名前付きの rules.<area> エントリ
• 言語： プロンプト、ユーザー向けの説明、検証レポート、コンテキストゲートの要約、問題の修正プロンプト、次のステップのガイダンスに使用する language.ui
• ワークフロー： workflow.plan_id_format（デフォルト：slug）。Step 0.2 のブランチベースの計画検出に使用します。 有効な値：slug と sequential。検出では、解決済みの fast/fix パスを除くルートの *.md ファイルを完全な計画として扱い、直接の子にある */index.md ファイルは、`` が正確に1つ含まれる場合にのみ、ultra エントリーポイントとして扱います。 sequential の場合は、番号付きの両方の形式を検索し、最も大きいプレフィックスを選択します。 timestamp と uuid は予約済みの値で、現在は slug と同様に動作します。 不明な値は slug として扱います。

verify_mode の優先順位：

1. --strict CLI フラグ → 常に strict を使用します。
2. config.yaml の workflow.verify_mode → 設定された値を使用します。
3. デフォルト → normal

config.yaml が存在しない場合は、デフォルトを使用します。

• パス：すべての成果物に .ai-factory/
• research：.ai-factory/RESEARCH.md
• verify_mode：normal
• ルール：RULES.md のみ
• ui_language：en
• workflow.plan_id_format：slug

解決された言語値：

• ui_language = language.ui || "en"

すべての AskUserQuestion プロンプト、ユーザー向けの説明、検証レポート、コンテキストゲートの要約、問題の修正プロンプト、次のステップのガイダンスは、ui_language で記述する必要があります。

機械可読な aif-gate-result JSON スキーマのフィールドと列挙値（pass、warn、fail）は変更せずに保持します。WARN／ERROR ゲートラベル、コマンド、パス、設定キー、コード識別子、パッケージ名、API 名、生のコマンド出力も変更せずに保持します。

0.1 所有権とゲートの契約を読み込む

• 最初に references/CONTEXT-GATES-AND-OWNERSHIP.md を読みます。
• 機械可読な品質ゲートの概要については、references/GATE-RESULT-CONTRACT.md を読みます。
• 以下の規範的な情報源として扱います。
  • コマンドと成果物の所有権
  • aif-commit／aif-review／aif-verify の読み取り専用動作
  • normal と strict のコンテキストゲートしきい値
• この契約がこのファイル内の古い例と矛盾する場合は、契約に従います。

0.2 計画成果物を探す

/aif-implement と同じロジックを使用します。作成側と利用側が確実に一致するよう、plans ディレクトリの glob を実行する前に正規のブランチ stemを生成します。

1. Check current git branch:
   git branch --show-current
2. Convert branch to filename stem (git mode only):
   branch_stem = current branch with every "/" replaced by "-"
   Example: feature/user-auth → feature-user-auth
3. Resolve the plan artifact using <branch_stem>:
   → When `workflow.plan_id_format = sequential`, glob both
       <configured plans dir>/[0-9][0-9][0-9][0-9]_<branch_stem>.md
       <configured plans dir>/[0-9][0-9][0-9][0-9]_<branch_stem>/index.md
     Read every directory candidate and retain it only when `index.md` contains
     exactly one . Choose the highest prefix across
     valid artifacts and warn when multiple valid candidates exist; prefer ultra
     if both shapes share the highest prefix.
   → Otherwise/fallback check the ultra entrypoint and full file:
       <configured plans dir>/<branch_stem>/index.md
       <configured plans dir>/<branch_stem>.md
     Read the directory entrypoint before selection and ignore it unless it
     contains exactly one . If both valid shapes
     exist, warn and prefer ultra.
4. If the branch-based plan is missing or git mode is off:
   → Count root `*.md` full plans and declared-ultra direct child `*/index.md`
     entrypoints as artifacts; exclude resolved fast/fix paths and do not count
     phase files
   → If exactly one exists, use it
   → If multiple exist, ask the user to choose or use `@<path>` via `/aif-implement`
5. No named full/ultra plan → Check the resolved fast plan path
6. No regular plan and no resolved fast plan → fall back to standalone verification choices

注： 計画の検出では paths.plans/ のみをスキャンします。/aif-archive によって paths.archive/plans/ にアーカイブされた計画は検出対象外です。アーカイブ内でのみ計画が見つかった場合は、WARN [aif-verify] plan <name> is archived; verifying archived plan を出力します。

計画成果物が見つからない場合：

AskUserQuestion: No plan artifact found. What should I verify?

Options:
1. Verify last commit — Check the most recent commit for completeness
2. Verify branch diff — Compare current branch against the configured base branch
3. Cancel

0.3 計画とタスクを読む

• 選択された計画のエントリーポイントを読み、実装予定の内容を把握します。
• 自動検出されたディレクトリのエントリーポイントは、`` を含む場合にのみ計画として扱います。無関係な */index.md ファイルは無視します。
• ultra では、検証の前に Phase Index のすべてのリンクを検証し、リンク先のすべてのフェーズファイルを読みます。index.md の短いチェックボックスの文言だけでなく、タスクごとの詳細なインターフェース、エッジケース、ログ記録、受け入れ基準、コマンドに照らして実装を検証します。フェーズリンクの欠落、破損、または許可された範囲からの逸脱は、コミット済みの仕様が不完全であることを示すため、計画の整合性に関するブロッキング障害となります。
• index.md の各 Task N が、リンク先のフェーズファイル内の一致する ## Task N セクションと1対1で対応していることを照合します。対応付けのないタスク、重複したタスクセクション、リンクされていない phase-*.md ファイルは、計画の整合性に関するブロッキング障害となります。
• TaskList → すべてのタスクとそのステータスを取得します。
• プロジェクトのコンテキスト（技術スタック、規約）を把握するため、.ai-factory/DESCRIPTION.md（設定で指定されたパスを使用）を読みます。
• 依存関係と境界のルールを把握するため、.ai-factory/ARCHITECTURE.md（設定で指定されたパスを使用）を読みます（存在する場合）。
• ルール階層を読みます（設定で指定されたパスを使用）。
  1. RULES.md — 公理（プロジェクト共通のルール）
  2. rules/base.md — プロジェクト固有の基本規約
  3. rules. — 設定から解決される領域固有のルール項目（例：rules.api、rules.frontend）
• マイルストーンとの整合性を確認するため、.ai-factory/ROADMAP.md（設定で指定されたパスを使用）を読みます（存在する場合）。
• 計画のエントリーポイントに ## Original Request が含まれている場合は、元のスコープに関する有用なコンテキストとして扱います。ユーザーが当初意図していた内容の把握に利用します。一方、実行可能な検証の入力には、タスクリスト、コミット済みの ## Research Context、および ultra のフェーズ仕様を使用します。
• 計画のエントリーポイントに ## Research Context が含まれている場合は、その埋め込みコピーをコミット済みの要件スナップショットとして扱います。最初の Source: / Reference: 行を、標準の ^(?:Source|Reference):\s+\x60([^\x60]+)\x60\s+\( 構文で解析します。旧形式のパスのみの行では、^(?:Source|Reference):\s+(.+?)\s+\( を代わりに使用します。どちらの形式でも使用可能なパスを特定できない場合に限り、設定された paths.research を使用します。
• 解析されたソースが research_bundles_dir 内にある場合、同階層の INDEX.md に `` がちょうど1回含まれ、## Artifact Index からその RESEARCH.md にリンクされていることを確認します。そうでない場合は WARN [research-drift] を出力します。同階層にあるC4／ADR／依存関係ファイルは、根拠としてのみ扱います。
• SHA256: が存在する場合、ソースの現在のテキストから と の間だけを厳密に抽出し、HTMLコメントブロックを削除し、行順と先頭の空白を保持し、各行の末尾の空白を削除して、LF改行を使用し、末尾に改行を1つ付けます。shasum -a 256 または sha256sum に標準入力で渡してハッシュを計算します。ダイジェストを正とします。SHA256: が存在しない場合に限り、旧形式の代替として Updated: を使用します。ソースが存在しない、無効である、またはリビジョンが一致しない場合は WARN [research-drift] を出力します。埋め込みの Research Context に照らして検証し、ユーザーが明示的にリベース／改良を求めていない限り、スコープを広げないでください。このドリフトチェックを省略すると、検証上の不具合になります。
• 同じルールの互換性に関する記述：WARN [research-drift] を出力し、計画に埋め込まれた Research Context に照らして検証します。

.ai-factory/skill-context/aif-verify/SKILL.md を読みます — ファイルが存在する場合は必須です。

このファイルには、パッチ、コードベースの規約、技術スタックの分析に基づいて /aif-evolve が蓄積した、プロジェクト固有のルールが記載されています。これらのルールは、現在のプロジェクトに合わせて調整されています。 スキルコンテキストルールの適用方法：

• スキルの一般的な指示に対するプロジェクトレベルのオーバーライドとして扱います
• スキルコンテキストルールと、この SKILL.md に記載された一般ルールが競合する場合は、スキルコンテキストルールを優先します（より具体的なコンテキストを優先します。ネストされた CLAUDE.md ファイルと同じ原則です）
• 競合しない場合は、両方を適用します。SKILL.md の一般ルールとスキルコンテキストのプロジェクトルールを適用してください
• スキルコンテキストルールがこのスキルの既定のルールと矛盾しているように見えても、無視してはいけません — プロジェクトでの経験から、既定のルールでは不十分だと判明したために設定されています
• 重要： スキルコンテキストルールは、検証レポートのテンプレートを含め、このスキルのすべての出力に適用されます。スキルコンテキストルールに「検証では X を必ず確認する」または「レポートにはセクション Y を必ず含める」とある場合は、レポートに必ず反映してください。スキルコンテキストルールを無視した検証を生成することはバグです。

徹底事項： 出力成果物を生成した後は、すべてのスキルコンテキストルールに照らして検証してください。 ルールに違反している場合は、ユーザーに提示する前に出力を修正してください。

0.3 変更ファイルの収集

# All files changed during this feature/plan
git diff --name-only <configured-base-branch>...HEAD
# Or if on the base branch / in no-git mode, check recent commits
git diff --name-only HEAD~$(number_of_tasks)..HEAD

git.enabled = false の場合は、ブランチの差分確認を完全にスキップし、次のいずれかから変更ファイルを収集します。

• 作業ツリー（未コミットの変更がある場合）、または
• 実装されたタスクに該当する最近のコミット範囲

CHANGED_FILES として保存します。

---

Step 1: タスク完了の監査

計画に含まれるすべてのタスクを確認し、実際に実装されたか検証してください。

タスクごとに、次の手順を実施します。

1.1 タスクの説明を読む

TaskGet(taskId) → Get full description, requirements, acceptance criteria

1.2 実装の有無を検証する

タスクの説明にある要件ごとに、次の手順を実施します。

• Glob と Grep を使って、要件を実装するコードを探します
• 関連ファイルを読み、実装が完了していることを確認します
• 「何かが書かれている」だけでなく、説明どおりに実装されていることを確認します

1.3 チェックリストを作成する

タスクごとに、次の形式で検証結果を出します。

✅ Task #1: Create user model — COMPLETE
   - User model created at src/models/user.ts
   - All fields present (id, email, name, createdAt, updatedAt)
   - Validation decorators added

⚠️ Task #3: Add password reset endpoint — PARTIAL
   - Endpoint created at src/api/auth/reset.ts
   - MISSING: Email sending logic (task mentioned SendGrid integration)
   - MISSING: Token expiration check

❌ Task #5: Add rate limiting — NOT FOUND
   - No rate limiting middleware detected
   - No rate-limit related packages in dependencies

ステータス：

• ✅ COMPLETE — すべての要件がコードで確認済みです
• ⚠️ PARTIAL — 一部の要件は実装済みですが、一部は未実装です
• ❌ NOT FOUND — 実装を確認できません
• ⏭️ SKIPPED — 実装中にユーザーが意図的にスキップしたタスクです

---

Step 2: コード品質の検証

2.1 ビルドとコンパイルの確認

ビルドシステムを検出し、プロジェクトがコンパイルできることを確認します。

検出対象	コマンド
go.mod	go build ./...
tsconfig.json	npx tsc --noEmit
build スクリプトを含む package.json	npm run build（または pnpm/yarn/bun）
pyproject.toml	変更ファイルに対して python -m py_compile
Cargo.toml	cargo check
composer.json	composer validate

ビルドに失敗した場合は、ファイル名と行番号を添えてエラーを報告してください。

2.2 テストの確認

プロジェクトにテストがあり、計画にテストが含まれていた場合は、次の手順を実施します。

検出対象	コマンド
jest.config.* または vitest	npm test
pytest	pytest
go test	go test ./...
phpunit.xml*	./vendor/bin/phpunit
Cargo.toml	cargo test

テストに失敗した場合は、失敗したテストと、それが実装したタスクに関係するかどうかを報告してください。

テストが存在しない場合、または計画でテストが明示的にスキップされている場合は、その旨を記録しますが、失敗とはしません。

2.3 リントの確認

リンターが設定されている場合は、次の手順を実施します。

検出対象	コマンド
eslint.config.* / .eslintrc*	npx eslint [変更ファイル]
.golangci.yml	golangci-lint run ./...
pyproject.toml の ruff	ruff check [変更ファイル]
.php-cs-fixer*	./vendor/bin/php-cs-fixer fix --dry-run --diff

出力を絞り込むため、変更ファイルのみをリントします。

2.4 インポートと依存関係の確認

• 使用されていないインポートが残っていないことを確認します
• タスクで言及された新しい依存関係が実際に追加されていることを確認します（package.json、go.mod、requirements.txt、composer.json）
• 依存関係の不足がないことを確認します（依存関係ファイルに記載されていないパッケージを参照するインポート）

---

Step 3: 整合性の確認

3.0 要件の出典とセマンティックの一貫性

計画とコードの整合性だけでなく、authoritative requirements → plan → implementation → verification evidence の完全な連鎖を検証します。

1. 計画に ## Requirements Reconciliation が含まれている場合は、選択された調査ソースへの引用を、埋め込まれた ## Research Context と照合します。ユーザーが明示的に計画をリベースしない限り、最新の調査ファイルはドリフトの確認にのみ使用します。他に引用されているソースの該当箇所も再読します。それ以外の場合は、Original Request、コミット済みの Research Context、プロジェクトのルール、およびそれらが明示的に参照する権威あるソースを使用します。
2. ソースの優先順位は、ユーザーまたはプロジェクトが宣言している場合にのみ適用します。ロードマップのテキストは、明示的に詳細な動作仕様として宣言されていない限り、詳細な動作契約ではなくスコープとして扱います。宣言された権限がないままソース間に矛盾がある場合は、推測せず、通常モードまたは緩和モードでは WARN [requirement-ambiguity]、厳格モードでは ERROR [requirement-ambiguity] を出力します。
3. 実装と、より優先度の高い要件との明確な矛盾は ERROR [requirement-conflict] とし、計画、コード、テストが相互に一致していても検証をブロックします。
4. 動作が独立したセレクター、状態、モード、または入力形式に依存する場合は、サポート対象の組み合わせのみを列挙し、重要な組み合わせごとに検証、永続化、出力／遷移、副作用を確認します。各次元を個別にテストしても、それらの相互作用を証明したことにはなりません。
5. リポジトリのデータ、設定、フィクスチャ、スキーマ、またはコンテンツが契約を定義する場合、そのような成果物が利用可能で関連性があるときは、代表的な既存成果物を少なくとも1つ、主要な統合パスを通じて検証します。

計画のテスト設定に従います。テストが意図的にスキップされていた場合は、静的検査に加えて、計画に記載された実行可能な検証証拠または手動検証証拠を使用します。証拠が不足している場合は、通常モードでは警告、厳格モードでは失敗として報告します。

3.1 計画とコードのドリフト

計画の内容と実装された内容の不一致を確認します。

• 命名：変数名／関数名／エンドポイント名は、計画で指定されたものと一致していますか？
• ファイルの場所：ファイルは計画で指定された場所にありますか？
• API 契約：エンドポイントのパスやリクエスト／レスポンスの形式は、計画と一致していますか？

3.2 残存アーティファクト

クリーンアップされているべきものが残っていないか検索します。

Grep in CHANGED_FILES: [T][O][D][O]|[F][I][X][M][E]|HACK|[X][X][X]|TEMP|PLACEHOLDER|console\.log\(.*debug|print\(.*debug

見つかったものはすべて報告してください。意図的なものかもしれませんが、フラグを付けてください。

3.3 設定と環境

実装によって新たな設定要件が導入されていないか確認します。

• 新しい環境変数が参照されているが、ドキュメントに記載されていない
• コード内で言及されている新しい設定ファイルが作成されていない
• データベースのマイグレーションが作成されているが、README／ドキュメントに記載されていない

Grep in CHANGED_FILES: process\.env\.|os\.Getenv\(|os\.environ|env\(|getenv\(|config\(

.env.example、.env.local、README、またはドキュメントと照合し、設定が記載されていることを確認します。

3.4 DESCRIPTION.md の同期

.ai-factory/DESCRIPTION.md が現在の状態を反映しているか確認します。

• 実装中に追加された新しい依存関係／ライブラリ → 記載されている必要があります
• アーキテクチャの変更 → 反映されている必要があります
• 新しい統合 → ドキュメントに記載されている必要があります

3.5 コンテキストゲート（アーキテクチャ／ロードマップ／ルール）

references/CONTEXT-GATES-AND-OWNERSHIP.md の標準契約を適用します。

各ゲートを明示的に評価し、報告してください。

• アーキテクチャゲート

  • Pass：実装が文書化された境界と依存関係のルールに従っています
  • Warn：アーキテクチャの対応関係が曖昧、または古くなっています
  • Fail：明示的なアーキテクチャ上の制約に明らかに違反しています

• ルールゲート

  • Pass：実装がプロジェクトの明示的なルールに従っています
  • Warn：関連性または検証の要否が曖昧です
  • Fail：明示されたルールの文言に明らかに違反しています

• ロードマップゲート

  • Pass：作業が既存のマイルストーンの方針に沿っています（プランに ## Roadmap Linkage がある場合は、そちらを優先します）
  • Warn：.ai-factory/ROADMAP.md が存在しない、対応関係が曖昧、または feat／fix／perf のスコープにマイルストーンとの関連付けがありません
  • Fail（厳格モード）：利用可能なロードマップのコンテキストをすべて考慮した後でも、ロードマップとの明らかな矛盾があります

通常モードの動作：

• アーキテクチャ／ルールへの明らかな違反は検証失敗とします。
• ロードマップとの不一致やマイルストーンとの関連付けの欠如は、矛盾が明示的かつ重大でない限り、警告とします。

厳格モードの動作：

• アーキテクチャとルールへの明らかな違反は検証失敗とします。
• ロードマップとの明らかな不一致は検証失敗とします。
• feat／fix／perf でマイルストーンとの関連付けがない場合は、.ai-factory/ROADMAP.md が存在していても警告のままです。

人間向けのログ／報告形式：

• ブロックされない指摘事項：WARN [gate-name] ...
• ブロックする指摘事項：ERROR [gate-name] ...

ユーザーがルールのみの単独チェックを希望する場合は、/aif-rules-check を提案してください。人間向けのコンテキストゲートのラベルは WARN／ERROR のままにし、完全な検証レポートに基づいて最終的な機械可読ゲート結果を導出してください。

機械可読ゲート結果：

• 人間向けの検証レポートの後に、最終のフェンス付き aif-gate-result JSON ブロックを 1 つ追加します。
• "gate": "verify" を使用します。
• "status": "pass|warn|fail" を使用します。定義は次のとおりです。
  • fail ＝ 必須タスクが未完了、ブロック対象の品質チェックに失敗、厳格モードのコンテキストゲートで失敗、または修正が必要なその他のブロッカーがある
  • warn ＝ ブロックされない警告のみが残っている、任意のチェックがスキップされた、ドキュメント／テストの不足が警告として許容された、またはコンテキストのずれが曖昧である
  • pass ＝ ブロック対象の指摘事項も警告も残っていない
• "blocking": true|false を使用します。コミットまたはマージのフローを停止すべき場合に限り、true に設定します。
• "blockers": [ にはブロックする指摘事項のみを含めます。ブロックされない注記は人間向けの要約に記載します。
• 変更または関連するパスを "affected_files": [ に含めます。
• references/GATE-RESULT-CONTRACT.md に従い、"suggested_next": { を /aif-fix、/aif-rules、/aif-architecture、/aif-roadmap、/aif-commit、または null に設定します。

3.6 コンテキストのずれ（任意の修正）

/aif-verify はコンテキスト成果物に対して読み取り専用です。ここでは .ai-factory/* ファイルを編集または再生成しないでください。

コンテキスト成果物が古い、存在しない、または曖昧であることを検出した場合は、ずれの指摘事項として報告し、担当コマンドによる修正方法を提示してください。

• DESCRIPTION.md のずれ → /aif を提案します（または、実装中に /aif-implement が更新すべきだったと注記します）
• ARCHITECTURE.md のずれ → /aif-architecture を提案します
• ROADMAP.md のずれ → /aif-roadmap check を提案します（または /aif-roadmap <update request> を提案します）
• RULES.md のずれ → /aif-rules <rule text> を提案します

ずれが検出され、今修正することで正確性が実質的に向上する場合に限り、ユーザーに任意の質問を 1 つだけしてください。

AskUserQuestion: Context drift detected. Capture updates now?

Options:
1. Yes — show the exact commands to run (recommended)
2. No — proceed without updating context

---

ステップ 4：検証レポート

4.1 結果の表示

人間向けの検証レポートを ui_language で作成します。以下のテンプレートは構造のみを定義しています。安定した技術トークンと最終的な aif-gate-result JSON スキーマは変更しないでください。

## Verification Report

### Task Completion: 7/8 (87%)
| # | Task | Status | Notes |
|---|------|--------|-------|
| 1 | Create user model | ✅ Complete | |
| 2 | Add registration endpoint | ✅ Complete | |
| 3 | Add password reset | ⚠️ Partial | Missing: email sending |
| 4 | Add JWT auth middleware | ✅ Complete | |
| 5 | Add rate limiting | ✅ Complete | |
| 6 | Add input validation | ✅ Complete | |
| 7 | Add error handling | ✅ Complete | |
| 8 | Update API docs | ❌ Not found | No changes in docs/ |

### Code Quality
- Build: ✅ Passes
- Tests: ✅ 42 passed, 0 failed
- Lint: ⚠️ 2 warnings in src/api/auth/reset.ts

### Requirements Consistency
- Source reconciliation: ✅ Passes
- Supported combinations: ✅ Covered
- Representative artifact path: ✅ Verified / ⏭️ Not applicable

### Issues Found
1. **Task #3 incomplete** — Password reset endpoint created but email sending not implemented (SendGrid integration missing)
2. **Task #8 not done** — API documentation not updated despite plan requirement
3. **2 unfinished markers found** — src/services/auth.ts:45, src/middleware/rate-limit.ts:12
4. **New env var undocumented** — `SENDGRID_API_KEY` referenced but not in .env.example

### No Issues
- All imports resolved
- No unused dependencies
- DESCRIPTION.md up to date
- No leftover debug logs

4.2 全体のステータスの判定

• すべて良好 — すべて検証済みで、問題はありません
• 軽微な問題 — すぐに修正できる小さな不足があります
• 重大な不足 — タスクが未完了または一部しか完了しておらず、再実装が必要です

4.2.1 機械可読なゲート結果を追加する

人間が読めるレポートと全体ステータスの後に、最後の aif-gate-result のフェンス付き JSON ブロックを正確に 1 つ追加します。

{
  "schema_version": 1,
  "gate": "verify",
  "status": "pass",
  "blocking": false,
  "blockers": [],
  "affected_files": [],
  "suggested_next": {
    "command": "/aif-commit",
    "reason": "Verification passed without blockers."
  }
}

スキーマの確認："status": "pass|warn|fail"、"blocking": true|false、"blockers": [、"affected_files": [、"suggested_next": {。

4.3 問題への対応

問題が見つかった場合：

AskUserQuestion: Verification found issues. What should we do?

Options:
1. Fix now (recommended) — Use /aif-fix to address all issues
2. Fix critical only — Use /aif-fix for incomplete tasks, skip warnings
3. Fix directly here — Address issues in this session without /aif-fix
4. Accept as-is — Mark everything as done, move on

「今すぐ修正」または「重大な問題のみ修正」の場合：

• まず /aif-fix の使用を提案し、簡潔な問題の概要を引数として渡します
• 例：
  • /aif-fix complete Task #3 password reset email flow, implement Task #8 docs update, remove unfinished markers in src/services/auth.ts and src/middleware/rate-limit.ts, document SENDGRID_API_KEY in .env.example
• ユーザーが同意した場合は、/aif-fix で進めます
• ユーザーが /aif-fix を断った場合は、このセッションで直接実装を続けます
• 未完了または一部完了のタスクごとに、不足している部分を実装します（/aif-implement と同じ実装ルールに従います）
• 未完了を示すマーカーやデバッグ用の成果物は削除します
• ドキュメントに記載されていない設定については、.env.example とドキュメントを更新します
• 修正後、関連する検証チェックを再実行して確認します

「現状のまま受け入れる」の場合：

• 受け入れた問題を、プランのエントリーポイントにコメントとして記録します
• ステップ 5 に進みます

---

ステップ 5：フォローアップスキルを提案する

検証が完了した後、結果に基づいて次のステップを提案します：

• 未解決の問題が残っている場合（受け入れた問題、または保留した問題）、まず /aif-fix を提案します
• すべて問題がない場合は、セキュリティ／レビュー／コミットのフローを提案します

## Verification Complete

Suggested next steps:

1. 🛠️ /aif-fix [issue summary] — Fix remaining verification issues
2. 🔒 /aif-security-checklist — Run security audit on the new code
3. 👀 /aif-review — Code review of the implementation
4. 💾 /aif-commit — Commit the changes

Which would you like to run? (or skip all)

AskUserQuestion: Run additional checks?

Options:
1. Fix issues — Run /aif-fix with verification findings
2. Security check — Run /aif-security-checklist on changed files
3. Code review — Run /aif-review on the implementation
4. Both — Run security check, then code review
5. Skip — Proceed to commit

問題の修正を選択した場合 → /aif-fix <issue summary> の実行を提案します セキュリティチェックを選択した場合 → /aif-security-checklist の実行を提案します コードレビューを選択した場合 → /aif-review の実行を提案します 両方を選択した場合 → まずセキュリティチェック、次にレビューを提案します スキップを選択した場合 → /aif-commit を提案します

コンテキストのクリーンアップ

必要に応じて、コンテキストの空き容量を確保するため、/clear（完全にリセット）または /compact（履歴を圧縮）を提案します。

---

厳格モード

--strict を指定して実行した場合：

/aif-verify --strict

• すべてのタスクが完了している必要があります — 一部完了やスキップは認められません
• ビルドが成功する必要があります — ビルドに失敗した場合は検証を失敗とします
• テストが成功する必要があります — テストに 1 つでも失敗した場合は検証を失敗とします（厳格モードではテストが必須です）
• Lint が成功する必要があります — 警告ゼロ、エラーゼロ
• 変更したファイルに未完了タスクを示すマーカーがないこと
• ドキュメントに記載されていない環境変数がないこと
• アーキテクチャゲートを通過すること — 明確な境界違反や依存関係の違反がある場合は失敗とします
• ルールゲートを通過すること — 明確なルール違反がある場合は失敗とします
• ロードマップゲートを通過すること — ロードマップとの明確な不一致がある場合は失敗とします
• 要件整合性ゲートを通過すること — 明確な要件の矛盾、未解決のソースの曖昧さ、または重要なサポート対象の組み合わせを示す証拠の欠落がある場合は失敗とします
• feat／fix／perf のマイルストーンとの関連付けの欠落は、厳格モードでも警告となります
• マイルストーンとの関連付けの欠落のみを理由に、厳格モードの検証を失敗としないでください

設定されたベースブランチへのマージ前、またはプルリクエストの作成前には、厳格モードの使用を推奨します。

---

使用方法

実装後（自動的に提案）

/aif-verify

マージ前の厳格モード

/aif-verify --strict

単独で実行（プランなしでブランチの差分を検証）

/aif-verify
→ No plan found → verify branch diff against the configured base branch