product-audit

プロダクト監査

プロダクト全体の健全性チェックです。書き込むのは docs/audits/<n>-<YYYY-MM-DD>.md のみです。提案するアクションはすべてユーザーの判断に委ねられます。

ターン契約 — ターンを終える前に確認

✓ The full PRODUCT AUDIT report was printed in the fixed output format (health by dimension, F-numbered ranked findings, four proposal streams — the roadmap streams always present, `none — <why>` when empty)
✓ The report was WRITTEN to `docs/audits/<n>-<YYYY-MM-DD>.md` (incremental audit id) and committed — the file is the durable deliverable, the chat print is a copy
✓ Nothing else was fixed, filed, or changed — the report file is the ONLY mutation
✓ The closing `→ Next:` block is printed as the ABSOLUTE last output

チェックされていないボックスがある状態でターンを終えようとしていますか？そのターンはまだ完了していません。先に未完了のボックスを完了してください（性能の低いモデルはドキュメント末尾の作業を見落としがちなので、このリストを最初に置いています）。

使用するタイミング

• 定期的に（数機能ごと）、またはプロダクトのリリース準備が整った段階で使用します。
• 単一の変更（review-change）や PR（audit-pr）のレビューではなく、品質、セキュリティ、技術的負債、ドキュメント、ロードマップを含む、広範で率直な全体像を把握したい場合に使用します。
• リポジトリ全体の調査を担当します。 範囲を限定し、サンプリングし、次元ごとに予算を設定した、オープンエンドのリポジトリ全体にわたるバグ調査、セキュリティ調査、壊れたバージョンの調査は、すべてここで行います（何をサンプリングしたかを明記してください）。単一の変更に対する同じ調査はreview-changeの担当です。どちらのスキルも、もう一方の範囲を引き受けません。

差分、PR、ドキュメントのみを対象とするレビューとは異なり、このスキルはプロダクト全体を対象とします。

範囲

コードベース全体と、そのプロセス成果物を対象とします。ソースコード、テスト、ドキュメントツリー、ロードマップ、修正インデックス、未解決のイシュー、各機能フォルダーの計画ドキュメントが含まれます。部分監査の対象を絞るために、任意でパスや領域を指定できます。範囲と、各次元を網羅的に調査せずサンプリングする場合は何をサンプリングしたかを明記してください。実施していない調査を網羅したかのように示してはいけません。

ヒント（暫定）。 ユーザーはultracode（研究プレビュー版のClaude Codeセッション設定。どのスキルからも宣言できません）を有効にすると、この調査を単一のコンテキストウィンドウではなく、並列サブエージェントに分散できます。有効にしない場合は、各次元を順番に調査します。変わるのは所要時間だけで、網羅性は変わりません。

ステップ 0 — プロジェクトを把握する（必ず最初に実施）

エージェントガイドのワークフローの規約とドキュメントマップに従い、その後、このスキルに必要な情報を読みます。ロードマップ、修正インデックス、機能フォルダーの構成、検証ゲートを確認してください。マップに基づいて、プロダクトの種類（Web／モバイル／コンソール／ライブラリ／バックエンド／インフラ）を判断します。適用する次元は、AUDIT_DIMENSIONS.mdを読み込むまで決めないでください。このリソースが、適用可否を判断するための正式なマトリックスです。プロジェクトにインストールされている任意のプラットフォームレビュー用スキルがあれば記録します（追加要素であり、必須ではありません。内部パックですべての軸をカバーします）。

段階的な読み込み — 監査ルート

参照先として許可されているパスは、以下の2つのみです。ステップ 0 の後に、記載順に両方を読み込みます。どちらも規範となるもので、このエントリーポイントから1ホップ先にあります。

1. 監査の次元を読み、すべての次元を適用対象またはn-a: <reason>として記載し、サンプリングがあれば明記します。
2. 監査プロセスを読み、10個のステップをすべて実行した後、以下の固定レポートを返します。

リソースが見つからない場合は監査を中止します。記憶を頼りに内容を再構成してはいけません。任意のプラットフォームレビュー用スキルは追加要素であり、内部パックの代わりにはなりません。

出力形式

この正確な構成を、保存するファイル（docs/audits/<id>-<YYYY-MM-DD>.md）とチャットへの出力の両方に使用します。自由形式の変更を加えず、実行ごとに内容を一致させてください。以下のすべてのセクションを、各監査に含めます。報告する内容がないセクションは省略せず、none — <why>と記載します（特にロードマップの各ストリームでは、「必ずロードマップの全体像をまとめる」こと。黙って省略してはいけません）。

# PRODUCT AUDIT <id> — <product> — <YYYY-MM-DD>
Scope: <whole product | area>
Coverage: <dimensions run | sampled vs. exhaustive>
Verdict: <one-line honest health verdict>

## Health by dimension
  <dimension> .......... ✓ healthy | ⚠ concerns | ✗ at risk | n-a (why)
  ...
  Installed tooling ....... ✓ | ⚠ | ✗ | n-a

## Findings (severity-ranked, one F-sequence for the whole audit)
  F1 [SEV] <dimension> — <finding> — evidence: <file:line | metric | doc> — class: <fix-now|replan-in-unit|decision-required|proposal|ignore>
  F2 [SEV] ...
  [example — scope-export recurrence] F<k> [med] Workflow discipline — <N>
    consecutive units exported scope via `## Amendments`/descope issues —
    features are being cut too big for real capacity — evidence: <unit list +
    amendments/issues> — class: proposal — route: #64 (atomicity/split rules)

## Delta vs audit <prior-id>
  New: F<k>
  Unchanged: F<k> <- audit <prior-id> F<j>
  Resolved: <prior-id> F<j>
  (none — <why no equivalent-scope prior exists>)

## Proposals — the user decides which to act on

### Issues to open
  - <title> [sev] — from: F<k>[, F<j>] — <why> — route: /triage-issue <id> F<k> — evidence: <…>
  (none — <why>)

### Roadmap — add
  - <feature> — from: F<k> — <rationale & opportunity> — route: /unit-lane --from-issue <n>
  (none — <why>)

### Roadmap — remove / revise
  - <feature> — from: F<k> — <why it no longer fits> — route: triage-issue / roadmap edit
  (none — <why>)

### Tooling — register / re-design
  - <skill|MCP> — register in AGENTS.md (Optional review extras): <why> — route: user edits AGENTS.md
  - <skill|MCP> — would change <feature> scope: <why> — route: /unit-lane <slug>
  (none — <why>)

## Manual-verification checklist (what automation can't confirm)
  - <item> …

Finding set: F<k> + F<j> + F<m> (print every proposed finding; one finding → F<k>)
→ Next: /triage-issue <id> F<k> F<j> F<m> — classify the complete finding set in one batch (opens the ones that warrant it)
  · accepted bug/debt → /unit-lane --fix <n>   · accepted capability → /unit-lane --from-issue <n>
  · nothing to act on → the persisted report is the record; move on

出力する前に、すべての調査結果のプレースホルダーを、実際の調査結果すべてに置き換えてください。実際の引き継ぎで…を出力したり、最初の調査結果だけを出力したりしてはいけません。

<id>は監査の通し番号です（プロセスのステップ 9）。調査結果は<audit-id> F<k>として永続的に参照できます。たとえば、triage-issue 3 F2はdocs/audits/3-*.mdを読み、F2を特定し、必要に応じてイシューを作成して分類することを意味します。この振り分けを提案してください。ここでトリアージやイシューの作成を実行してはいけません。

最初に、率直な健全性評価を1行で示します（例：「追跡すべき高深刻度のセキュリティ項目が2件ありますが、リリース可能です」）。

ガードレール

• 自動修正は行わず、課題を作成せず、ロードマップも編集しません。 出力するのはレポートと提案です。すべての対応はユーザーが決定します。 このスキルが書き込むファイルは docs/audits/ 配下のレポートだけです（加えて mkdir -p docs/audits を実行します）。リポジトリ内のほかのものには一切触れません。
• 検出事項の ID は F1, F2, … のみです。監査ごとに 1 つの連番を使用し、重大度の高い順に付けます。問題の種類ごとに異なる文字を使うことはありません。保存後、ID は固定されます。後続の監査では新しい監査 ID を割り当て、古いファイルの番号は付け直しません。監査間の関連付けは、Delta マッピングで <audit-id> F<k> としてのみ示し、グローバルなスラッグや置き換えられた ID は使いません。ユーザーが承認した場合は、triage-issue で課題を作成・分類し、/unit-lane でロードマップへの作業追加または具体的な修正の範囲設定を行います。
• ツールの登録や AGENTS.md の編集は行いません。 ツールの調査では、登録するスキル／MCP を提案しますが、編集するのはユーザー自身（または振り分け先の /unit-lane <slug> の実行）です。スコープに影響する発見事項は、ユーザーが承認する /unit-lane <slug> に振り分けます。
• プラットフォームに応じて実施します。該当する評価軸のみを実行し、スキップした項目とその理由は必ず列挙します。
• 上限を黙って設けてはいけません。 ある評価軸でサンプリング、優先順位付け、または時間制限を行った場合は、その旨を明記します。部分的な調査を網羅的な調査として示してはいけません。
• 重大度順に並べ、重複を排除します。複数の評価軸や複数の機能ドキュメントから見つかった同じ問題は、1 つの提案にまとめます。
• プロジェクトのワークフロー規約（ドキュメントの言語、エビデンス）を遵守します。検出事項／提案にはすべて file:line、メトリクス、ドキュメント、または課題の出典を記載し、不確実な点には verify と付けます。
• エビデンスは、references/AUDIT_PROCESS.md に定める固定のエビデンス出所ゲートにも合格する必要があります。 不確実な点には引き続き verify と付けます。

移植性（Claude Code 以外のエージェント）

ワークフローが規約であり、Claude Code の機能は利便性を高めるものです。エージェントに機能がない場合は代替手段を適用し、その機能が可能にする手順を決して省略しないでください。

• スラッシュコマンドメニューがない場合 — このスキルで /<skill> と記載されている箇所では、そのスキルの SKILL.md（エージェントにスキルがインストールされている場所）を開き、新しい会話で文字どおり手順に従います。引き継ぎではクリーンなコンテキストを前提とします。
• スキルごとの model:／effort: がない場合 — これはワークフローで最も広範かつ重大な影響を伴う調査です。最も高性能なモデルを最も深い設定で使用し、専用の実行として行います。ほかのタスクのコンテキストに押し込んではいけません。
• ultracode／サブエージェントがない場合 — 評価軸を順番に調査します（上記のヒントを参照）。いずれの場合も、調査範囲を正直に示します。

ほかのスキルとの関係

product-audit (whole product, all axes, periodic)
   ├─ composes review-change axes (codebase-wide) + audit-docs (doc coherence)
   ├─ mines feature docs (decisions / known-issues / architecture-notes)
   ├─ sweeps installed skills / connected MCP servers (product-wide, periodic)
   └─ proposes ─┬─ Issues to open ........ ▶ triage-issue / unit-lane --fix
                ├─ Roadmap: add .......... ▶ unit-lane --from-issue
                ├─ Roadmap: remove/revise  ▶ triage-issue / roadmap edit   (user decides)
                └─ Tooling: register/re-design ▶ user edits AGENTS.md / unit-lane

• review-change（1 件の変更）や audit-pr（1 件の PR）よりも広範で、audit-docs の整合性チェックを評価軸の 1 つとして含みます。
• 自動的に引き継ぐことはありません。提案のみを行い、ユーザーが選択した場合に限り、計画／修正／トリアージのスキルが実行します。

完了条件

• 該当するすべての評価軸について、根拠として引用したエビデンスを伴う健全性の判定があり、スキップまたはサンプリングした項目が明記されていること。
• 重大度順のF 番号付き検出事項リストと、4 つの提案系列（作成する課題、ロードマップへの追加、ロードマップからの削除／改訂、ツールの登録／再設計）があること。すべての系列を提示し（空の場合は none — <why> と記載）、重複を排除し、各提案を振り分け、出典となる検出事項を引用します。
• レポートが docs/audits/<id>-<YYYY-MM-DD>.md として保存・コミットされ、次の連番の監査 ID が割り当てられ、チャットにも出力されていること。
• ほかのものは何も修正、登録、変更されていないこと。何を実行するかはユーザーが決定します。
• 最後の → Next: ブロックが出力されていること。通常は提案した課題に対する一括の /triage-issue <id> F<k> … に続いて、承認された作業に対する /unit-lane を示します。