audit-anything

あらゆる対象を監査する

一般的なコードレビューではなく、構造化された監査を実施してください。監査スキルは、対象範囲、証拠の取り扱い、重大度、網羅性、判定、レポートの保存を担います。組み合わせるドメインスキルは、その領域の用語と検査基準を提供します。ドメインスキルによって監査が実装作業に変わらないようにしてください。

スキルの組み合わせ方

flowchart TD
    A["Audit request"] --> B{"Named domain skill?"}
    B -- "Yes" --> C["Pair audit + domain skill"]
    B -- "No" --> D{"Domain obvious?"}
    D -- "Yes" --> E["Select best matching skill"]
    D -- "No" --> F["Ask one concise question"]
    C --> G{"Skill available and allowed?"}
    E --> G
    G -- "Yes" --> H["Load domain instructions"]
    G -- "No or explicit-only" --> I["Use composition checklist"]
    F --> I
    H --> J["Run audit loop"]
    I --> J

組み合わせのルール

1. 依頼内容または対象の成果物から、監査対象の領域を特定します。ユーザーが別のスキルを指定した場合は、このスキルと併せて読み、使用してください。
2. ドメインスキルが指定されていなくても、対象領域が明らかな場合は、利用可能な最適なスキルを選んで組み合わせてください。たとえば、ビジュアル／UI デザインのレビューには frontend-design、明示的に依頼されたアーキテクチャレビューには improve-codebase-architecture、スキーマレビューには database-schema-designer、エージェントのワークフローレビューには ai-agent-workflow を組み合わせます。
3. ドメインが本当に曖昧な場合は、誤った対象に労力を費やす前に、簡潔な質問を1つしてください。
4. 明示的な指定が必要、またはモデルで無効化されているスキルを、黙って呼び出さないでください。ユーザーにそのスキルを呼び出すよう依頼するか、references/compositions.md の該当するチェックリストを使用してください。
5. 組み合わせるスキルの創作的または計画的なワークフローは、監査モードの範囲内にとどめてください。ユーザーが修正を明示的に依頼しない限り、再設計、リファクタリング、依存関係のインストール、コードの修正は行わないでください。

監査モード

依頼を満たす最小限のモードを選択してください。

モード	対象	最低限必要な証拠
変更監査	差分、コミット、PR	差分全体、関連する呼び出し経路、テスト
モジュール監査	ファイル、コンポーネント、サービス、ワークフロー	エントリーポイント、依存関係、状態の流れ、テスト
システム監査	アーキテクチャ、ドメインモデル	ディレクトリ構成図、モジュール境界、データ／制御の流れ、ADR またはドキュメント
実稼働プロダクト監査	実行中のアプリ	実際の操作、該当する場合はスクリーンショット、コンソール／ネットワーク出力
コントラクト監査	API、スキーマ、イベント、データモデル	インターフェース、呼び出し元、制約、マイグレーション、障害ケース
ドキュメント監査	計画、仕様、IA、ユーザーフロー、レポート	成果物全体、参照元、実装との整合性

ユーザーが欠陥の指摘のみを求めるコード変更レビューでは、review-agent を優先してください。より広範な監査、ドメイン評価、または保存するレポートを求められた場合は、このスキルを使用してください。

実行ループ

flowchart LR
    A["Frame audit"] --> B["Read local conventions"]
    B --> C["Establish baseline"]
    C --> D["Collect evidence"]
    D --> E["Apply domain checklist"]
    E --> F{"Hard evidence satisfied?"}
    F -- "No" --> G["Downgrade or mark incomplete"]
    F -- "Yes" --> H["Classify findings"]
    G --> H
    H --> I["Assign verdict"]
    I --> J["Persist report"]

プロセス

1. 監査の枠組みを定めます。 対象、ドメイン、組み合わせ、モード、想定ユーザー、制約、およびスコープが変更、モジュール、システム、稼働中の製品、契約、文書のいずれに当たるかを記録します。
2. ローカルの規約を確認します。 対象を評価する前に、該当する AGENTS.md、README、ドキュメント、ADR、用語集、既存の監査レポートを読みます。
3. ベースラインを確立します。 テスト、型チェック、リンター、ビルド、スキーマ検証、依存関係の確認など、関連する読み取り専用のチェックを実行します。許可なく破壊的なコマンドを実行したり、外部サービスを要求したりしないでください。
4. 証拠に基づいて調査します。 依頼された成果物全体に加え、挙動を理解するのに十分な周辺のコードやドキュメントを確認します。稼働中の製品については、実際のフローを操作し、観察可能な証拠を記録します。
5. 組み合わせた観点から評価します。 references/compositions.md のドメインチェックリストを使用します。一般的な評価項目は、正確性、セキュリティ、信頼性、パフォーマンス、保守性、状態管理、テスト容易性、可観測性、アクセシビリティ、文書化された意図です。
6. 対処可能な指摘事項のみ報告します。 指摘事項には、具体的な影響、証拠、実行可能な最小限の修正方針が必要です。推測に基づく懸念、明示されたスコープ外の既存の問題、挙動を分かりにくくしていないスタイル上の細かな指摘は含めないでください。
7. 確認範囲を正直に示します。 調査した内容、サンプル確認した内容、検証できなかった内容を列挙します。アクセス権、認証情報、サービス、実行可能な状態が不足している場合、判定は合格ではなく未完了となります。
8. レポートを保存します。 ユーザーがチャットのみでの出力を求めていない限り、docs/ ディレクトリが存在する場合は完全なレポートを docs/audits/YYYY-MM-DD-<domain>-<target>.md に書き込みます。docs/ ディレクトリがない場合は OS の一時ディレクトリに保存し、絶対パスを提示します。
9. チャットで要約します。 判定と影響の大きい指摘事項から始め、レポートのパスと推奨する次の対応に触れます。

証拠の要件

flowchart TD
    A["Evidence"] --> B{"Source-backed and reproducible?"}
    B -- "No" --> C["Discard or mark speculative"]
    B -- "Yes" --> D{"Hard gate passed?"}
    D -- "No" --> E["Fail or incomplete"]
    D -- "Yes" --> F{"Any P0 or P1 finding?"}
    F -- "Yes" --> G["Fail"]
    F -- "No" --> H{"Only P3 gaps?"}
    H -- "Yes" --> I["Pass"]
    H -- "No" --> J["Conditional pass"]

指摘事項と判定

次の優先度を使用します。

• P0：リリースを阻止する問題、または重大な正確性、セキュリティ、データ損失の問題。
• P1：影響の大きい不具合またはリスク。早急に修正する必要があります。
• P2：通常の不具合、欠落、または保守性の問題。
• P3：対応すると有益な改善、またはドキュメントの改善。

次の判定を使用します。

• Pass：P0/P1 の指摘事項がなく、合意したすべての必須ゲートを通過しています。
• Conditional Pass：P0/P1 の指摘事項はありませんが、P2/P3 の課題が残っています。
• Fail：P0/P1 の指摘事項が1件以上あるか、必須ゲートに失敗しています。
• Incomplete：必要なアクセス、操作、ビルド、テスト、または証拠が不足しています。

すべての指摘事項に、次の内容を含めてください。

1. 優先度を含む、1行の命令形のタイトル。
2. ファイル名と行番号、コマンド出力、リクエスト／レスポンス、スクリーンショット、スキーマ、または成果物からの引用による証拠。
3. 影響を受けるシナリオまたはユーザーワークフロー。
4. 組み合わせたドメインの観点で、それが重要である理由。
5. 曖昧な提案ではなく、次に行うべき最小限の具体的な変更。

レポート形式：

# <Domain> Audit: <Target>

Date: YYYY-MM-DD
Scope: <artifact or boundary>
Pairing: audit + <skill or explicit lens>
Mode: <audit mode>

## Verdict

<Pass / Conditional Pass / Fail / Incomplete>

## Flow evidence

Use one or more Mermaid diagrams when they clarify state, sequence, ownership, trust boundary, or failure path. Prefer a diagram for any workflow that spans multiple components or decision points.

## Findings

### [P1] <Imperative finding title>

- Evidence: <path:line, output, screenshot, or quote>
- Impact: <affected workflow and why it matters>
- Next change: <smallest concrete fix direction>

## Coverage

- Inspected: <list>
- Sampled: <list>
- Not verified: <list and why>

## Roadmap

1. <Immediate / P0-P1 action>
2. <Structural action>
3. <Polish or documentation action>

ドメイン固有の組み合わせ、調査の質問、必須の証拠要件については、references/compositions.md を参照してください。