repo-harmonization

リポジトリの調和

スラッシュコマンドまたはドル記号による呼び出しによって、すでにこれらの指示が会話に追加されている場合は、そのまま従ってください。 その場合、スキルツールを通じてこのスキルを再度呼び出さないでください。

相互に関連するリポジトリのリストを使って、検証済みの調査結果、ユーザーが承認した判断、影響範囲を絞った変更を導き出してください。 監査では、次の2種類の作業を対象とします。

• 整合性：リポジトリ間のずれ、古くなった相互参照、重複した内容、競合するワークフロー。
• 移転：あるリポジトリでうまく活用され、別のリポジトリにも役立つエージェント向けのガイダンス、ワークフロー、依存関係。 移転する内容は、移転先の規約に合わせて調整してください。

引数

$ARGUMENTS は、リポジトリのパスを空白区切りで並べたリストです。チルダ展開を利用できます。

• 2つ以上のパスを指定してください。各パスは既存のGitリポジトリのルートであり、解決後にそれぞれ異なるリポジトリである必要があります。インベントリヘルパーがこれらの規則を適用し、問題のある入力を示して終了コード2で終了します。その場合は処理を止め、ヘルパーのメッセージを伝えてください。
• ユーザーのリクエストによって、対象を整合性または移転に絞ることができます。そうした指定がなければ、両方を行ってください。インベントリヘルパーにはリポジトリのパスだけを渡してください。例外はテンプレートの差分にある--driftフラグです。
• リンク、リモート、インストール済みのコピーから、追加のリポジトリを推測しないでください。指定されたリストが監査の範囲を定めます。

契約

• 編集前に調査し、調査は厳密に読み取り専用で行います。ホストがサブエージェントをサポートしている場合は、並行して調査します。それ以外の場合は、順次調査します。
• あらゆる整合性または重複の主張を、diff、コンテンツハッシュ、再生成の往復検証、またはシンボリックリンクの解決によって機械的に検証します。文章を目視で確認するだけで済ませてはいけません。すべての指摘にファイル名と行番号の根拠を付けます。
• すべてのリポジトリを提供元であると同時に受け取り先として扱います。移行候補ごとに、方向別に評価します：提供元、プラクティス、受け取り先。
• 移行単位は1つのプラクティスです。ガイダンスルールまたはプロジェクトスキル、ワークフロー（タスク手順、スクリプト、CI ジョブ、フック、ツールチェーンの固定、リンター、フォーマッター、型チェック、テスト、またはリリース設定）、あるいはそれを使用するワークフローまたはコードと一体になった依存関係を指します。受け取り先で使用しない依存関係は移行してはいけません。
• 移行候補すべてに根拠を付けます。プラクティスと、それが実行されていること（タスク、CI、フック、またはコードから呼び出されていること）を示す提供元のファイル名と行番号を含めます。また、別名での機能的な同等物も含め、受け取り先に不足していることを証明する検索コマンドと、そのプラクティスが解決する必要性を示す受け取り先の根拠も含めます。
• 重要な指摘はすべて、統合して評価するに記載された分類のいずれか1つに厳密に分類します。
• コピーではなく、適合させます。移行する内容は、受け取り先の言語、ランタイムのバージョン、パッケージマネージャー、タスクランナー、命名規則、ファイル構成、フォーマット、ガイダンスの文体に合わせて書き直します。移行するガイダンスでは、計画適用後に受け取り先に存在するコマンド、パス、ツールのみを指定します。
• 提供元の秘密情報、認証情報、個人識別情報、ホスト名、アドレス、プロジェクト固有の名称や前提を受け取り先に持ち込んではいけません。
• 構成変更よりも、範囲を絞った修正を優先します。追加する複雑さを上回る複雑さを取り除ける場合を除き、include パイプライン、テンプレート層、共有リファレンス、その他の仕組みは導入しません。
• 効果を得られる最小限の移行を優先します。新しいスクリプトよりタスク手順、ラッパーより設定ファイル、文書のコピーより短いルールを選びます。共有パッケージ、テンプレートリポジトリ、同期パイプライン、サブモジュールについては個別に判断します。
• 判断を要する事項はすべて、計画の前にユーザーに提示します。承認された判断の範囲を超えてはいけません。
• 実装の承認範囲は、最初のファイル一覧ではなく、承認された結果と解決済みの判断事項に基づきます。実装中に、決定を実行するために必要なリポジトリ内の関連する前提条件が見つかった場合、オーケストレーターはファイル一覧を拡張し、新しい範囲の調整を行い、改めて確認を求めることなく、必要最小限の追加修正を委任できます。例として、開発用依存関係、ロックファイルの更新、設定のひな形、ignore エントリーがあります。ワーカーは割り当てられた書き込み範囲を逸脱せず、根拠をオーケストレーターに返します。
• 各リポジトリの生成パイプラインとフックを尊重します。正規のソースのみを編集します。コミットを行わないビルド専用の手順で生成物を再生成します。設計されたコミットフックはコミット時に実行させます。
• 実装エージェントにコミットやプッシュをさせてはいけません。オーケストレーターがリポジトリごとにコミットし、タスク対象ファイルに範囲を限定したうえで、ホストの調整ルールと共有ワークツリーのルールに従います。
• 経過時間ではなく、測定した件数（調査済みリポジトリ数、発見・検証・分類・実装済みの指摘数）を用いて、フェーズが変わるたびに進捗を報告します。

受け入れ

指定されたパスを使ってインベントリヘルパーを一度実行し、このスキルディレクトリを基準にスクリプトのパスを解決してください。作業ツリーを再生成、インストール、またはその他の方法で変更する可能性があるコマンドを実行する前に、必ず実行してください：

bun run "<skill-dir>/scripts/inventory.ts" <repo-path> <repo-path> [more-repos...]

標準出力に単一の JSON ドキュメント（schemaVersion: 1）を出力し、入力が無効な場合は 2 で終了します。それ以外の副作用はありません：

• repos[]：id、input、root、head、dirty（porcelain 形式の行）、packageManagers、ecosystems（エコシステムごとに解析された依存関係の数）、files.guidance、files.workflow、files.manifest（追跡対象のパス）、tasks[]（runner は just または package.json で、file と name を含む）、および解析できなかった項目を示す notes。
• dependencyGaps[]：同じエコシステムを共有する一部のリポジトリには存在し、すべてには存在しない依存関係。presentIn（リポジトリ、マニフェスト、セクション、仕様、使用回数）と missingIn を含みます。package.json、pyproject.toml（uv の場合は [project]、[dependency-groups]、[tool.uv]）、Cargo.toml、go.mod（直接の require と tool エントリー）を解析し、ワークスペース内のローカルパッケージはスキップします。
• taskGaps[]：一部のリポジトリには存在し、すべてには存在しないタスク名。
• summary：エコシステム別およびタスク別の共有数とギャップ数。

JSON はホストのスクラッチディレクトリまたは一時ディレクトリに保存し、全体を再読み込みするのではなく、jq でクエリしてください。

• 後続の証拠確認では、各 root を対象リポジトリのルートとして使用してください。レポート用に各 input の形式を維持してください。
• 各 dirty リストは調査前の git status スナップショットとして扱ってください。既存の変更は他のエージェントが進行中の作業として扱い、保全境界とします。監査対象、移管元、移管先には決してしないでください。
• 現在のブランチとリモート設定は、インストール、公開、またはリポジトリ間の参照に影響する場合に限って記録してください。
• ファイル一覧は初期インベントリとして扱ってください。ガイダンスには、AGENTS.md、CLAUDE.md、GEMINI.md、CONTRIBUTING.md、Copilot と Cursor のルール、.mcp.json、および .agents、.claude、.codex、.cursor、.gemini、.windsurf 配下のエントリーポイントが含まれます。ワークフローには、タスクランナー、CI、フック、ツールチェーンの固定指定、ツール設定が含まれます。各リポジトリのルートと CI ディレクトリをざっと確認し、一覧に含まれていない対象を探してください。また、requirements*.txt、foundry.toml、.gitmodules、Gemfile、composer.json など、解析対象外として一覧にあるマニフェストも読み込んでください。
• 各リポジトリの README とトップレベルのガイダンスを読み、その特性を記録してください。具体的には、目的（ライブラリ、アプリ、CLI、サービス、カタログ）、言語、ランタイムとツールチェーンのバージョン、パッケージマネージャー、タスクランナー、CI プロバイダー、設定済みのエージェントクライアントを記録します。適合性の判断は、この特性に基づいて行ってください。

結論を出す前に、最初のリンクマップを作成してください。リンクマップはインベントリとして扱い、2 つのファイルが同じソースを共有すべきである証拠とはみなさないでください。起源が不明なものは不明として記録してください。パスが似ていることだけでは、関連性の根拠になりません。

• 一覧にあるリポジトリ間を指すシンボリックリンクをマッピングし、解決後のターゲットも含めてください。各シンボリックリンクは、それを含むリポジトリを起点に解決し、意図的な外部シンボリックリンクか、リンク切れかを区別してください。
• 一覧にある別のリポジトリから生成されたファイルをマッピングしてください。明記されている場合はソースを特定してください。各生成関係を裏付ける生成コマンドまたはマニフェストのエントリーを記録してください。
• リポジトリ間で成果物、スキル、パッケージ、設定を移動するインストールおよび公開フローをマッピングしてください。各フローがファイルを変更するのか、外部状態を作成するのか、ソース成果物の検証のみを行うのかを記録してください。
• 他の一覧対象リポジトリへの参照を AI コンテキストファイルから検索してください。対象には AGENTS.md、CLAUDE.md、README のガイダンス、スキル、ローカル指示が含まれます。周辺の文章だけでなく、具体的なパス、コマンド、またはリポジトリ識別子を記録してください。

テンプレートとの乖離

一方のリポジトリがもう一方のテンプレートである場合は、インベントリヘルパーを実行する前に、乖離テーブルを実行します。

bun run "<skill-dir>/scripts/inventory.ts" --drift <template-root> <project-root>

ヘルパーは、surface、template、project、status の列を含む Markdown テーブルを1つ出力します。入力が無効な場合は 2 で終了し、それ以外の副作用はありません。

• テーブルでは、次の項目について、両方向の差異を比較します。package.json の scripts と devDependencies、lint と format の設定、tsconfig*.json ファイルとその compilerOptions キー、justfile のレシピ名、git フック、CI ワークフローファイル。
• 設定、フック、ワークフローファイルの値は、短いコンテンツハッシュです。値が60文字を超える場合は、省略した文字数が末尾に付記されます。
• status は same、missing-in-project、missing-in-template、または differs です。

これらの項目の乖離インベントリとしてテーブルを使用します。

• same 以外の各行を乖離候補として扱います。分類する前に、diff で確認します。
• 各項目について、テンプレートからプロジェクトへ、プロジェクトからテンプレートへ、または変更なしのいずれかの方向をユーザーに選んでもらいます。
• 承認された各方向の変更を、実装と最終確認 に従って必要最小限の転送として適用します。
• 方向が明らかに見える場合でも、行を自動的に適用してはいけません。

調査

• リポジトリまたは独立したサブシステムを、読み取り専用の調査担当者3名以内で分担します。それぞれに限定されたパス範囲を割り当て、同じリポジトリ境界、ヘルパーの JSON パス、変更済みファイル一覧を共有します。変更案ではなく、証拠を求めます。
• ホストが調査担当者を実行できない場合は、証拠の基準を緩めず、同じ分担で順次調査します。
• 各調査担当者は、担当範囲の整合性に関する証拠とプラクティスのインベントリを返します。タスクの説明で焦点が絞られている場合は、該当部分のみを収集します。

整合性に関する証拠

• 正規版と生成物の関係、および生成物を作成する正確なビルドパイプラインを特定します。ファイルの正規の所有元を割り当てる前に、ビルド設定とジェネレーターの入力を確認します。
• 重複している、または重複に近い指示、ドキュメント、スクリプトの内容を特定します。両方の箇所を正確に示します。
• 成果物の形式に適した正規化 diff またはコンテンツハッシュで、重複の疑いを検証します。完全一致にはバイト単位の比較を使い、重複に近いという主張には使用した正規化方法を示します。
• 古いパス、バージョンの不一致、矛盾するルール、未公開の変更など、乖離を特定します。関連する正規ソース、実在するパス、バージョンソース、または再現可能なコマンドを使って、疑いのある乖離を立証します。
• 古い参照については、リポジトリ全体の検索結果だけでなく、参照元のファイルと参照先を特定します。
• 同じ作業を実行する競合ワークフローを特定します。それぞれについて、入力、出力、副作用、ドキュメントに記載された起動条件、利用する正規ソースを説明します。
• リストにある他のすべてのリポジトリへの参照を確認し、それぞれの参照が有効かどうかを判断します。ローカル参照とリモートまたは公開済みの参照が両方ある場合は、個別に確認します。
• 結果を分類する際は、生成物とそのソースを区別します。

プラクティスのインベントリ

• ガイダンス：ルール、規約、コマンド、プロジェクトスキル、フック、権限、MCP サーバー。それぞれにポータブルまたはプロジェクト固有の印を付けます。
• ワークフロー：実行するコマンドと確認または生成する内容を含むタスク、CI ジョブと起動条件、フック、ツールチェーンのバージョン固定、lint、format、型チェック、テスト、カバレッジ、セキュリティ、依存関係の更新、リリースの各ツール。
• 依存関係：ツールまたは共通の懸念事項に関係するギャップマトリックスの項目と、リポジトリでの各項目の使用方法（設定、タスク、またはファイル:行での import）。

統合

• すべての調査結果を、各主張の出所を保ちながら、証拠に基づく一つの全体像にまとめます。意見の食い違いは、より説得力のある説明を選ぶのではなく、機械的なチェックを再実行して解決します。
• オーケストレーターでリポジトリ横断のマトリクスを作成します。各プラクティスについて、該当するリポジトリ、同等のものがあるリポジトリ、何もないリポジトリを記録します。同等性は名称ではなく機能で判断します。例：oxlint と eslint、just check と npm run lint、ruff と flake8 および black。
• 各導入先の不足を、ツール名、設定ファイル、コマンド、機能的に同等なものを検索して機械的に検証します。コマンドと結果を記録します。
• 方向ごとに適合性を評価します。エコシステムおよびランタイムの互換性（engines、requires-python、rust-version、go ディレクティブ、ピア依存の制約）、導入先の目的、競合するツールや文書化されたポリシー、保守や CI のコストを確認します。概念レベルのプラクティスは、エコシステムをまたいで導入できる場合があります（型チェックのゲート、対象を限定したフォーマットルールなど）。依存関係は、同じエコシステム内でのみ、または承認済みのエコシステム同等ツールとしてのみ移行します。
• エージェントのコンテキストに読み込まれるグローバルまたは親ディレクトリの指示ファイルなど、より広い範囲から導入先がすでに受けている指針は省きます。重複させても、動作は変わらずコンテキストが増えるだけです。
• ツール候補については、手間がかからない場合、読み取り専用で影響を事前確認します。リポジトリのファイルを書き換えずに、一時的な実行手段（bunx、npx、uvx、go run、チェックモードの cargo）でツールを実行し、git status --short で確認します。検出された違反数や自動修正可能な件数なども記載します。
• 調査時点での最新のレジストリバージョンとランタイム要件を、導入先のパッケージマネージャーで確認します。実装時にも再確認します。

整理と評価

• 最も強力なファイル名・行番号の証拠や機械的な証拠を損なわずに、重複する観察結果を統合します。関連はあるものの同一ではなく、異なる修正や判断が必要な観察結果は分けておきます。
• 同じ手法に関する移植候補を、複数の提供元から統合します。最も優れた提供元の実装をモデルとして選び、ほかの提供元も記載します。
• 未検証の疑いを分類してはいけません。調査に戻すか、未解決の質問として記録します。
• 生成されたコピーにドリフトが疑われる場合は、ビルド専用の手順で再生成し、diff でバイト単位の一致を確認します。検証を再現するために必要なジェネレーター入力とコマンド出力を保存します。
• シンボリックリンクのリンク先を解決して比較してから、リンクされたコンテンツが重複または相違していると判断します。
• 客観的に壊れた参照と、重複したコンテキストをどの程度残すかという好みを分けます。

重要な各指摘は、次のいずれかに必ず一度だけ分類します。

1. 修正すべきドリフトの確認済み事項：正規のソース、実際のパス、バージョンのソース、または再現可能なコマンドとの不一致が機械的に証明されているもの。
2. 単一ソース化の候補：1つの正規ソースで置き換えられる真の重複。実施するかどうかはユーザーが判断します。
3. 推奨する移植：明確なメリットがあり、ギャップが確認済みで、エコシステムとの互換性があり、既存のツールや文書化されたポリシーと競合せず、コストが低いもの。
4. 判断が必要な項目：既存のツールや競合するワークフローの置き換えまたは廃止、新しいエコシステム、ランタイム、タスクランナー、サービス、必須シークレットの導入、CI コストの増加、ライセンス上の懸念、コミット、リリース、レビューのルールなどポリシーを変更するガイダンス、新しいチェックによって明らかになった既存の違反（修正、ベースライン化、または削除）、重複コンテンツの簡略化の度合い、公開するか保留するか。
5. 意図的な変更なし、または却下：意図的または必要な重複、エコシステムの不一致、プロジェクト固有の手法、すでに存在する同等のもの、価値の低さ、または受け入れ側の文書化されたポリシーとの競合。

自己完結型の成果物や個別にインストールするスキルなど、設計ルールによって保護された重複は、証拠がその制約を裏付ける場合、意図的なものとして扱います。コピーがバイト単位で同一でも、自己完結型であることをインストール要件として求められる場合は、設計上の制約として扱います。変更なしおよび却下の一覧には、各項目の機械的な証拠と理由を記載して残します。

決定

• ユーザーがすでに決定した内容と委任した判断を適用します。結果に重大な影響を及ぼす未解決の選択肢についてのみ質問します。承認を求める前に、証拠と具体的な提案を準備します。
• 確認済みのドリフトは、判断が必要な項目と分けて提示します。通常、異論の出にくい修正バッチとしてまとめて提示します。各修正について、影響を受けるリポジトリと正確な機械的証拠を記載します。
• 推奨する移植は、提供元、移植先、証拠、メリット、コストを記載した簡潔な表で提示します。ユーザーが項目を除外できるよう、すべてをデフォルトで受け入れる一括提案として提示します。
• 単一ソース化の候補と、判断が必要な項目はすべて、推奨案とトレードオフを添えた明示的な質問として提示します。選択によって計画が変わる場合、選択肢は相互に排他的なものにします。
• 明確に簡略化する根拠がない場合は、デフォルトで現状を維持する選択肢を明示します。
• 各変更に影響する決定を、計画に着手する前に確定します。別の選択肢への回答を待つ間も、独立した調査と、すでに許可されている変更を続けます。進捗報告を、依頼された作業の完了として扱ってはいけません。
• 各ユーザーの決定を、解決する指摘の横に一字一句そのまま記録します。承認された変更に条件や例外が付されている場合は、それも保持します。
• 却下された項目は、黙って省略せず、変更なしおよび却下の一覧に追加します。

計画

• リポジトリごとに、意思決定に必要な情報をすべて含む計画を作成します。作成または編集する正確なファイル名、正規のソース、影響を受ける生成物、各転用元とその適用元（ファイル名:行番号）、および依存関係とそれを追加するパッケージマネージャーのコマンドを明記します。
• 各変更を、その根拠となる調査結果、検証コマンド、および変更を承認したユーザーの意思決定に関連付けます。
• 正規のソースを、その生成物またはインストール済みの対応物より先に変更するよう、編集順序を決めます。各変更先では、依存関係を、それを使用する設定やタスクより先に追加し、ガイダンスは最後に追加して、実在する内容を説明するようにします。
• リポジトリの規則上、正規の成果物そのものに該当する場合を除き、インストール済みの出力を手作業で編集しないでください。
• すべての再生成コマンドを、そのコマンドがビルドのみを行うのか、ファイルを変更せずに実行するのか、またはファイルの変更を伴うのかとともに明記します。コミットフックによる副作用を特定し、ビルドや再生成の手順とは明確に分けてください。
• コミットと公開の順序、およびリポジトリ間の依存関係を明記します。下流のリポジトリが上流で生成またはインストールされた成果物を安全に利用できる時点を特定します。
• Claude Code では、プランモードを優先してください。
• $orchestration が利用できる場合は、実装を通じて委任します。利用できない場合は、ホストのサブエージェントを使います。それらも利用できない場合は、直接実装します。
• どの実装方法でも、委任する作業の書き込み範囲はリポジトリごとに重複しないようにします。依存する編集が完了した後に一度だけ実行できるよう、リポジトリ横断の統合検証は担当者を一人に限定します。
• 計画は、ユーザーが承認した意思決定の範囲内にとどめます。それらの意思決定が対象とする技術的な前提条件は、自律的に計画へ追加します。新たな調査結果によって主観的な選択が必要になる場合、対象リポジトリや意図する成果が変わる場合、または承認されていない破壊的操作、公開、その他の外部への書き込みに踏み込む場合に限り、報告して確認を求めます。

実装と仕上げ

転送する場合：

• 受け取り側のパッケージマネージャーを使って依存関係を追加します（例：bun add -d、pnpm add -D、uv add --dev、 cargo add、go get -tool）。制約に適合する最新の安定版を使い、受け取り側のバージョン範囲と固定方法に合わせます。ロックファイルはパッケージマネージャーに更新させます。
• 提供元の設定から、提供元固有のパス、名前、機能を参照するオプションを削除して調整します。
• CI のプロバイダー、アクションのバージョン固定方式、ランナー、キャッシュ、最小権限の設定など、受け取り側の CI 規約に合わせます。
• ガイダンスファイルがシンボリックリンクまたは生成物の場合は、正規のソースを編集します。プロジェクトのスキルは受け取り側のスキルディレクトリに合わせて移植するか、提供元が共有カタログからインストールしている場合は、同じインストール方法で移植します。
• 新規または変更したタスクはすべて受け取り側で一度実行し、提供元のバージョンと同じ役割を果たすことを確認します。移植したチェックは受け取り側で成功するか、既存の失敗についてユーザーが下した判断を適用します。
• CI やフックの変更は、actionlint など、利用可能なローカルリンターまたはドライランで検証します。CI の実行でしか証明できない場合は、その旨を明記します。
• 移植したガイダンスを検証します。そこに記載されたコマンド、パス、ツールがすべて受け取り側に存在することを確認します。

すべての変更について：

• 各実装エージェントの結果を、作業ツリーに見える変更と割り当てられた書き込み範囲に照らして確認します。エージェントの結果を完了とみなす前に、報告された変更パスがすべて承認済みの範囲に属していることを確認します。
• 既存の未コミット変更と無関係な並行変更は、バイト単位でそのまま保持します。
• 意図した編集を証明できる、リポジトリごとの最も対象を絞ったチェックを実行します。そのチェックが対象とする規則や依存関係を持つリポジトリで実行します。
• リポジトリ横断の不変条件は一度だけ確認します。該当する場合は、再生成の冪等性と、ソースとインストール済み成果物の差分も確認します。
• 集約的な失敗が発生した場合は、対処する前にその原因を特定します。まず、このタスクの変更、フォーマッター、フック、ジェネレーターの影響を、承認済みファイルの範囲外にある後続の失敗も含めて除外します。無関係であることが証拠によって確認され、タスク固有のチェックも成功している場合に限り、失敗を無視して続行します。
• $commit が利用可能な場合は、検証後に使用し、タスクに関係するファイルだけを渡します。git add -A、git commit -a、stash、reset で代用してはなりません。
• 履歴、フック、公開状態をそれぞれ独立して監査できるよう、リポジトリごとにコミットします。可能であれば、各転送を個別にコミットし、独立して取り消せる状態にします。
• 次のコミットを作成する前に、対象範囲のコミットを確認し、上流のコミットを独立して取り消せる状態にします。
• ソースを変更した後は、必要な公開またはインストールのフローをすべて再実行します。検証していないソースや、ソースと一致しなくなったインストール済み成果物を公開してはなりません。
• ユーザーの判断によって公開を保留する場合は、検証済みのソースコミットをすぐに実行できる状態で残し、必要なリリース手順を報告します。

レポート

• 最初に、リポジトリごとに適用した修正と転送、および残っているブロッカーを一行で示します。
• 適用した修正と転送を表にまとめます。リポジトリまたは受け取り側、検出事項または採用した手法、提供元（該当する場合）、変更ファイル、コミット識別子を記載します。
• 検証コマンドとその結果をすべて報告します。成功したチェックと、意図的に実行しなかったチェックを区別し、CI でしか検証できない場合も含め、その理由を説明します。
• 意図的に変更しなかった項目、却下した項目、見送った項目とその理由を、簡潔な表にまとめます。
• 未実行の公開フロー、利用できない再生成ツール、未解決のリポジトリ横断参照など、残存リスクを示します。
• 承認された判断の範囲を超えて保留された、または後から判明した未解決事項を示します。
• 監査可能なレポートにします。すべての結論を、記録された検出事項、判断、証拠、またはコマンドの結果に結び付けます。