harness-master

Harness Master

AI ハーネスの設定品質、利用状況、エコシステムの選択肢を監査し、承認済みの設定修正を同じセッション内で適用します。

対象外： エージェントの作成（agent-conventions）、MCP サーバーの構築（mcp-creator）、一般的なアプリケーションのテレメトリ（observability-advisor）、またはハーネス／設定に焦点を当てない一般的なコードレビュー（review）。

入力： ハーネス名、レベル、または自然言語。モード：監査、検出（ギャップ＋範囲を限定した調査）、利用状況、適用／インストール、ジャーナル。モードが曖昧な場合は、scripts/discovery/classify_intent.py --args "$ARGUMENTS" --json を実行します。

振り分け

$ARGUMENTS	モード	最初の動作
Empty	インテーク	ハーネスまたは all を尋ねてから、project、global、both のいずれかを尋ねます
all	インテーク	レベルのみを尋ねます
all <level> / <level> all	監査	サポート対象のすべてのハーネスを決定論的な順序でドライランします
<harness...>	インテーク	1 つ以上のハーネスを特定してから、不足しているレベルのみを尋ねます
<level>	インテーク	レベルを特定してから、不足しているハーネスのみを尋ねます
<harness...> <level> / <level> <harness...>	監査	選択したハーネスとレベルについて、ドライランレビューを実行します
grok-build both とリポジトリに rig ワークフロー機能がある場合	監査＋記録	プラグインの所有権／競合を監査し、ハッシュに紐づく保存済みワークフローのプレビューを出力します。適用はしません
apply approved	承認済みの適用	ユーザーがこのセッションですでに承認している場合に限り、最後に一致したドライランのバッチを適用します
apply <harness...> <level> / apply <level> <harness...>	承認済みの適用	同じスコープがこのセッションですでにレビューされ、承認されている場合に限り適用します。そうでなければ、まず監査を再実行します
install <harness...>	インストール案内	正確な npx skills add ... コマンドのみを表示します。設定ファイルは編集しません
discover	詳細な探索	references/discovery-pipeline.md に従って、W0 スキャン → スカウト → アイデア創出 → レポートを実施します
discover audit / audit gaps	探索 W0	ギャップレポートのみを作成します。スカウトは行いません
discover resume / discover list	ジャーナル	~/.agents/harness-master/discovery/ のセッションを読み込むか、一覧表示します
usage <harness|all> [level] [days]	使用状況レビュー	安全な集計済みの使用状況／コスト／トークン／ツールのシグナルを収集します。読み取り専用です
自然言語：不足しているスキル／拡張／ハーネス向けに最適な X を探す	探索（推定）	深度は詳細、絞り込み、候補、比較のいずれかです。discovery-pipeline.md を参照してください
自然言語：「 の設定をレビュー／監査／確認／調整」	監査	ハーネスとレベルを正規化してから、ドライランレビューを実行します
自然言語：「 の使用状況／コスト／トークン／ツールをレビュー／分析」	使用状況レビュー	ハーネスとレベルを正規化し、安全なメタデータのみを収集して、最適化の方向性を報告します
自然言語：「 向けのプラグイン／拡張機能／MCP／スキルを探す／最新／最適」	絞り込み探索	W0 ＋カテゴリ別スカウト＋source_probe.py を実行します。読み取り専用です
「承認済み」「実行して」「その変更を適用して」などの自然言語での承認	承認済みの適用	直前の harness-master レビューがスコープと一致し、現在も有効な場合に限り続行します
エージェントまたは MCP サーバーの作成依頼	拒否＋誘導	適切な専門スキルに誘導します
サポート対象外のハーネス名	拒否＋確認	サポート対象のハーネスを一覧表示し、その中から選ぶようユーザーに尋ねます

空引数ハンドラー

引数なしで /harness-master を呼び出した場合：

1. レビューするハーネス、または all を使用するかどうかを尋ねます。
2. project、global、both のどれにするかを尋ねます。
3. 最初のパスは常にドライランのみであることを説明します。

入力の正規化

• 対応ハーネス：claude-code、claude-desktop、chatgpt、codex、cursor、cursor-cli、grok-build、opencode、perplexity-desktop、cherry-studio、lm-studio
• 対応レベル：project、global、both
• 対応する調査カテゴリ：config、plugin、extension、mcp、skill、all
• 対応する使用期間：7、14、30、days=14 などの正の整数の日数。指定がない場合は 14 を使用します
• ハーネスの別名：
  • claude、claude-code -> claude-code
  • claude-desktop -> claude-desktop
  • chatgpt、chatgpt-desktop、openai-chatgpt -> chatgpt
  • codex -> codex
  • cursor、cursor-editor、cursor-desktop、cursor-web、cursor-cloud、cursor-cloud-agent、cursor-background-agent -> cursor
  • cursor-cli、cursor-agent、cursor-agent-cli、agent-cli、agent -> cursor-cli
  • grok、grok-build、grok-cli -> grok-build
  • opencode、open-code -> opencode
  • perplexity、perplexity-desktop、perplexity-mac -> perplexity-desktop
  • cherry、cherrystudio、cherry-ai、cherry-studio -> cherry-studio
  • lm-studio、lmstudio、lms -> lm-studio
• レベルの別名：
  • project、repo、local -> project
  • global、user -> global
  • both、all-levels -> both
• 複数のハーネスは、カンマと空白で分割します。
• all と名前付きハーネスの両方が指定された場合、どちらを使用するか尋ねます。
• all の決定的な順序：claude-code、claude-desktop、chatgpt、codex、cursor、cursor-cli、grok-build、opencode、perplexity-desktop、cherry-studio、lm-studio
• 不明なトークンを推測してはいけません。焦点を絞った確認質問を1つ尋ねます。

Grok Build（grok-build）

• 指示エントリー： AGENTS.md -> instructions/grok-global.md -> instructions/global.md
• ポリシーテンプレート： リポジトリの Grok プラットフォームアダプター同期により、config/grok-config.toml を ~/.grok/config.toml にマージします
• 所有権： replace-owned（models、mcp_servers、plugins、compat、telemetry）と blend-owned（ui、features、session、tools、toolset、subagents、memory）
• リポジトリスキル： 正規化された ~/.grok/config.toml の [plugins].paths がこの有効なリポジトリルートを指す場合、そのプラグインを CLI 以外で優先される所有者とします。リポジトリのスキル本文に対して、Skills CLI、Claude 別名、~/.grok/skills ミラーを出力してはいけません。
• 外部スキル： ネイティブの Skills CLI アダプターはありません。厳選された外部インストール／同期では、claude-code 別名と ~/.grok/skills へのミラーを維持します。
• 競合： ~/.agents/skills、~/.claude/skills、~/.grok/skills にあるプラグイン対象の名前はクリーンアップ候補であり、競合のない有効化を主張する際の妨げとなります。
• 保存済みワークフロー： リポジトリの .grok/workflows/*.rhai はソースのみです。プロジェクトユーザーへの投影と認識済みのレガシー移行には、scripts/grok_workflow_projection.py、正確なプレビュー受領記録、新しいカナリア、受領記録に紐づくロールバックを使用します。
• Plannotator： CLI + スキル + フック（Grok npm プラグインはありません）。インストール：grok plannotator install（リポジトリ CLI）。ポリシー：config/grok-plannotator-hooks.json -> ~/.grok/hooks/plannotator.json。ホームシムは block を deny に対応づけます。厳選された定義は docs/src/authoring/skills/*.mdx にあります。OpenCode の @plannotator/opencode@latest とは異なります。
• 環境変数（TOML には含まれません）： GROK_WEB_FETCH、GROK_MEMORY、GROK_SUBAGENTS、GROK_LSP_TOOLS — config/grok-env.sh に記載し、/grok-delegate preflight で確認します
• ハーネス間の委任： /grok-delegate — Codex／OpenCode のタスクグラフ向けに、ネイティブのヘッドレス grok -p／-r／ワークツリー／リーダーを使用します（設定同期ではありません）
• 分離同期： --platforms grok --targets home を使用したリポジトリスタック同期（他のハーネスのホームマージをスキップし、Plannotator フックの更新を含みます）

Cursor Agent CLI (cursor-cli)

• バイナリ： agent（cursor-agent も使用できます）。Skills CLI アダプターは cursor（-a cursor）のままです。
• 指示のエントリ： AGENTS.md + CLAUDE.md + .cursor/rules + instructions/cursor-cli-global.md（薄い .cursor/rules/cursor-cli.mdc ポインター）
• エディターと共有する SSOT： .cursor/hooks.json、.cursor/mcp.json、.cursor/skills、.cursor/agents、~/.cursor/{hooks,mcp,skills,agents} — Cursor アダプター（harness="cursor"）によって一度だけレンダリングされます。
• CLI 専用： プロジェクトの .cursor/cli.json 権限、ユーザー所有の ~/.cursor/cli-config.json（同期では書き込みません）。Doctor：リポジトリの CLI cursor-cli doctor
• プラグイン： --plugin-dir と agent plugin marketplace（オペレーターが明示的に選択した場合のみ。同期で追加しません）
• ACP / worktrees / worker： cursor-acp を参照してください。agent --worktree。agent worker はリポジトリ同期の対象外です。
• フック： 共有の hooks.json とプラグインのフックを使用します。フックレジストリのレンダーリストに cursor-cli を追加しないでください。ホーム専用 Plannotator：config/cursor-global-hooks.json → ~/.cursor/hooks.json + plannotator-plan-hook.py 経由の CreatePlan / SwitchMode。インストール／同期：cursor-cli plannotator sync。Git 追跡対象の .cursor/hooks.json には決して反映しないでください。

分類ゲート

1. $ARGUMENTS をハーネス、レベル、all、インストールの意図、適用の意図、未解決のトークンに解析します。
2. 未解決のトークンが残っている場合は、続行する前に確認の質問を1つだけします。
3. リクエストが discover ...、不足／欠落／拡張の意図、またはハーネスに最適なものを探す自然言語リクエストの場合は、Discover を実行します（classify_intent.py または discovery-pipeline.md で深さを推定します）。
4. リクエストが usage ... の場合は、Usage Review のみを実行します。
5. リクエストが install ... の場合は、Install Guidance のみを実行します。
6. 場当たり的な「X 用のスキルを探して」というリクエストは、skill-router search または npx skills find に誘導します。スキル／MCP の体系的な拡張であれば、Discover を続行します。スキルの作成であれば、skill-creator に誘導します。ハーネスに関係しない自由形式の調査であれば、/research に誘導します。
7. リクエストが apply ... または承認を示すフレーズの場合、同じセッション内に対応するドライランレビューがすでにある場合に限り、Apply Approved を実行します。そうでない場合は、先に監査を再実行します。
8. リクエストにサポートされていないハーネスが含まれている場合は、適切に拒否し、サポート対象の一覧を示します。
9. ハーネスが指定されておらず、all も指定されていない場合（監査／使用状況）は、ハーネスまたは all のみを尋ねます。
10. レベルが指定されていない場合（監査／使用状況）は、project、global、both のみを尋ねます。
11. それ以外の場合は、ドライランモードで Audit を実行します。

分類ロジック

1. 明示的なモードトークンを最初に振り分けます：discover、usage、install、apply、resume、list。
2. 不足／欠落／拡張／最適なものを探す自然言語リクエストは、Audit ではなく Discover の深さに振り分けます。
3. Discover を示す要素がなく、設定の調整／修正の意図がある完全なハーネス／レベルの範囲指定は、Audit に振り分けます。
4. 使用状況／コスト／トークンに関する自然言語リクエストは、Usage Review に振り分けます。
5. 承認は、直前のドライラン監査がリクエストされた範囲と一致する場合に限り、Apply Approved に振り分けます。

ワークフロー

モード A：監査（デフォルト、まずドライラン）

1. ゲート 0 — 対象領域を検出する

   • 次を実行します。

     uv run python scripts/discover_surfaces.py --repo-root . --level <level> --harness <canonical-harness> [--harness ...]
     

   • JSON 出力を解析し、各対象領域を present、missing、generated、merged、repo-observed、または blind-spot に分類します。
   • スクリプトを実行できない場合は、Glob、Read、Grep を使った手動検出に切り替えます。

2. ゲート 1 — 修正を提案する前にプロジェクトのコンテキストを確認する

   • まず、リポジトリの目的と運用モデルを読み取ります。対象は README.md、AGENTS.md、ハーネス向けのプロジェクトファイル、主要なマニフェスト、CI／ワークフローの手掛かり、および存在する場合はリポジトリ固有のオーケストレーションロジックです。
   • このリポジトリでは、リポジトリレベルのハーネス同期スクリプトと config/tooling-policy.json、config/sync-manifest.json を、管理対象／生成済み／統合済みのハーネス対象領域に関する正規のコンテキストとして扱います。

3. ゲート 2 — 最新の公式ガイダンスを確認する

   • references/latest-doc-sources.md を読みます。
   • 利用できる場合はまず llms.txt を参照し、次に公式ドキュメント、正規のベンダーリポジトリのドキュメントを確認します。必要な場合に限り、最後にウェブ検索を使います。
   • 公式ドキュメントを入手できない場合は、縮退モードに移行して信頼度を下げます。

4. ゲート 3 — 選択した各ハーネスを個別に監査する

   • 選択したハーネスに限り、references/harness-surfaces.md、references/harness-checklists.md、references/evidence-boundaries.md を必要な範囲で読み込みます。
   • both の場合は、編集を提案する前にプロジェクトとグローバルの優先順位を比較します。
   • 生成済みの対象領域は明示します。生成された出力を直接編集するより、正規のソースを修正することを優先します。
   • ネイティブの対象領域が存在しない場合は、評価すべき証拠として扱い、自動的に不合格とはしません。
   • grok-build both の場合、選択したリポジトリが .grok/workflows/rig-ecosystem-index.rhai と skills/rig-ecosystem-refresh/SKILL.md を所有している場合は、設定パスによるプラグインの所有権と、重複する 3 つのスキルルートを確認します。下流の dotfiles ルートは現在のタスクコンテキストから解決し、ユーザーパスをハードコードしないでください。
   • レシートを承認対象として扱う前に、Grok のネイティブワークフローバリデーターで正規のワークフローを検証し、設定されたプラグインソースも検証します。これらの結果は、レシートのソースハッシュに紐付けた別々の証拠として保持します。
   • 次のコマンドでワークフローのプレビューを作成します。

     uv run python skills/harness-master/scripts/grok_workflow_projection.py preview \
       --repo-root <agents-repo> \
       --dotfiles-root <dotfiles-repo> \
       --receipt-out <user-state-receipt.json> \
       --format json
     

     レシートのパスは、Grok のスキル／ワークフロー検出ルートの外部に置く必要があります。宛先の不一致、旧ハッシュの不一致、無効なプラグイン所有者、またはスキルの重複公開がある場合、バッチはブロックされます。プラグインの所有権には、読み取り可能で移植性のあるフロントマターが必要です。その name と description が空でなく、スキルディレクトリと一致している必要があります。既存のトランザクション所有者マーカーがある場合も、新しいプレビューはブロックされます。

5. ゲート 4 — ドライランの監査結果を報告する

   • references/output-format.md の構成を使用します。
   • すべての指摘に、重大度、影響を受ける対象領域、証拠タグ、このプロジェクトにとって重要な理由、修正すべき場所を記載します。
   • 正しい変更内容が明確な場合は、具体的なパッチのプレビューを提示します。
   • ドライランの報告後に停止し、ユーザーから明示的な承認を得るまで待機します。

Mode B: 承認済みの適用

1. 明示的な承認ゲートを通過した後にのみ適用します。
2. 承認が有効なのは、同じセッション内で直前に実施した harness-master のドライランレビューが、同じハーネスセットとレベルをすでに対象としていた場合に限ります。
3. レビュー対象の範囲が古い、不明、曖昧、または新たな証拠と矛盾する場合は、編集前に Audit を再実行します。
4. 変更を行う前に、承認されたバッチを再提示します。
5. 承認された最小限のバッチのみを適用します。対象範囲を暗黙に広げてはいけません。
6. 承認された修正がインストール手順の場合は、references/install-guidance.md に記載された正確な npx skills add ... の手順を使用します。
7. 編集後、サーフェス検出と、変更したハーネスを対象とするドライランチェックを再実行し、残っているギャップを要約します。
8. 承認済みの rig-ecosystem-index Grok レシートについては、ハーネス横断の広範なスキル同期適用を行わないでください。正確なレシートダイジェストを段階的に適用します。次を実行する前に、ネイティブのワークフロー／プラグイン検証の証拠が、変更されていないレシートのソースハッシュを引き続き対象としていることを再確認します。

   uv run python skills/harness-master/scripts/grok_workflow_projection.py apply \
     --receipt <receipt.json> --receipt-sha256 <approved-sha256> --format json
   

   新しい Grok プロセスを開始し、プラグイン所有のユーザー呼び出し可能なスキルを 1 つ、ワークフローの正確なバイト列、変更を加えないヘルプ、およびワークフロー検証を確認します。すべてのカナリアチェックに合格した場合に限り、同じ承認済みレシートで認識済みのレガシーバイト列を移行できます。

   uv run python skills/harness-master/scripts/grok_workflow_projection.py migrate \
     --receipt <receipt.json> --receipt-sha256 <approved-sha256> \
     --canaries-passed --format json
   

   失敗した場合は、同じレシートの rollback コマンドのみを実行します。ロールバックでは、まず検証済みのレガシーバックアップをすべて復元し、その後、新たに投影された一致バイト列を最後に削除します。これにより、復元に失敗しても Grok に動作するワークフローが残るようにします。削除には、その正確なレシートダイジェストとトランザクションに対応する、有効で永続的な所有者マーカーが必要です。レシート所有の投影 inode を破棄する前に、ロールバックはそのマーカーを、ワークフロー検出の対象外にある、ファイルとディレクトリへの同期が完了したトランザクション固有の rolled-back トゥームストーンへ移行します。このトゥームストーンは、古いレシートが後続トランザクションの同一バイト列を取得できないよう、恒久的に残ります。マーカーがない、異なる、またはトゥームストーン化されている場合は、パブリック投影を保持します。レガシーと投影の削除では、inode に紐付けた上書き禁止の隔離を使用するため、同一ハッシュへの置換競合が発生した場合は安全側に失敗します。

Mode C: 検出

読み取り専用のギャップ拡張と、ハーネスの範囲内での調査を行います。references/discovery-pipeline.md と references/discovery/coordinator-contract.md を読み込みます。

1. 深度を分類します（full、focused、candidate、compare、w0only、ideate、journal）。
2. 深度の要件にギャップ調査が含まれる場合は、スカウトを開始する前に W0 スクリプトを実行します。
3. W2/W2b 内で source_probe.py と candidate_score.py を使用します。これらをユーザー向けの独立したモードとして扱ってはいけません。
4. ユーザーの確認があるまで、適用／インストールを行わないでください。設定の修正には、Audit と apply approved の両方が必要です。

モード D：使用状況のレビュー

usage または、トークンコスト、クォータ、ツールの使い勝手、MCP の使用状況、スキルの適合性、プラグインの適合性、コンテキストの健全性、セッションの帰属、ハーネスのテレメトリーに関する方針をレビューする自然言語のリクエストには、このモードを使用します。

1. モード全体を読み取り専用として扱います。ファイルの編集、パッケージのインストール、ジョブの作成、セッションの生データのエクスポート、生のプロンプトやトレースの出力、ハーネス設定の変更は行わないでください。
2. ハーネス、レベル、使用期間を正規化します。期間が指定されていない場合は、14 日に設定します。
3. サーフェスの検出と安全な使用状況のプローブを実行します。

   uv run python scripts/usage_probe.py --repo-root . --harness <canonical-harness> --level <level> --days <days> --json
   

4. references/usage-review.md、references/evidence-boundaries.md、references/output-format.md を読み込みます。
5. token_stats、token_history、token_export、insights_collect、agent_attribution、quota_status、gemini_quota、workspace-summary、git-smart-status などのランタイムツールは、リクエストされたハーネスとプライバシークラスに合致する場合に限り使用します。
6. 調査結果を使用状況のシグナルに正規化し、情報源の網羅性、プライバシーの安全性、コスト／トークンの状況、ツールの効率性、MCP の健全性、スキルの適合性、プラグインの適合性、コンテキストの健全性、承認の安全性、推奨事項の実行可能性を評価します。
7. 推奨レーンとして、keep、tune-config、tune-skill、tune-mcp、tune-plugin、tune-workflow、instrument、defer、do-not-change を報告します。
8. ユーザーが Usage Review の推奨事項の適用を求めた場合は、適用をブロックし、先に該当する Audit のドライランと明示的な承認を求めます。

スケーリング戦略

スコープ	戦略
small	1 つのハーネスと 1 つのレベル：ハーネスごとのレポートを 1 つ作成し、インラインでレビューします
medium	2～3 個のハーネス、または 1 つの both スコープ：各ハーネスを個別にレビューしてから、簡潔な統合結果を追加します
large	4 個以上のハーネス、または all：可能な範囲で検出をまとめて実施し、ハーネスごとのセクションを厳密に分けたうえで、ハーネス横断の統合結果と優先順位付きの整理順で締めくくります
Discover (full/focused)	Pattern F のセマンティクスを使用します：情報源を調査し、候補を評価し、根拠を統合して、適用前に停止します
Team-capable Discover	情報源ファミリーの調査担当には Pattern E またはネストされたウェーブを使用し、派遣した調査担当をすべて記録します
使用状況のレビュー	まず集計プローブとランタイムの概要を優先し、生の記録、生のトレース、シークレットファイル、メッセージテーブルの読み取りは避けます

最新ドキュメントの参照ポリシー

入手できる最新の権威あるガイダンスを使用します。

1. llms.txt または同等の公式インデックス
2. 設定、指示、ルール、MCP、権限に関する公式ドキュメントページ
3. 公式の製品ドキュメントが不完全な場合は、ベンダーの正規リポジトリにあるドキュメント
4. 上記を利用できない場合に限り、ウェブで補完

現行の情報源による根拠がない場合は、latest と主張しないでください。

ハーネスごとのレビュールール

• 統合結果を作成する前に、各ハーネスを個別にレビューします。
• 各調査結果に verified-file、verified-doc、repo-observed、blind-spot のいずれかのタグを付けます。
• 選択したレベルについて、権威ある設定サーフェス、二次設定サーフェス、生成された設定サーフェス、マージ済み設定サーフェスを明示します。
• both の場合は、変更を推奨する前にプロジェクトとグローバルの競合を報告します。
• 現在のセッションからハーネス固有のネイティブサーフェスを確認できない場合、動作を創作せず、ブラインドスポットとして明示します。

インストールガイダンスの契約

• ユーザーから harness-master のインストール方法について尋ねられた場合、またはスキルが利用できないことが実際の根本原因である場合に限り、references/install-guidance.md を読み込みます。
• 既定で提示する形式：

  npx skills add <source> --skill harness-master -y -g --agent claude-code --agent codex --agent crush --agent cursor --agent opencode
  

• ネイティブ設定の問題に対して、インストールコマンドを推奨しないでください。
• 既定ではプロジェクトローカルへのインストールを提案しないでください。プロジェクトローカルへのインストールをユーザーが明示的に求めた場合に限り、python scripts/install_skills.py --local --execute に触れてください。

検証の契約

このスキルを変更した後、次を実行します。

python scripts/check.py
uv run python skills/skill-creator/scripts/audit.py skills/harness-master/
uv run python skills/skill-creator/scripts/package.py skills/harness-master/ --dry-run
uv run pytest tests/test_grok_workflow_projection.py tests/test_grok_doctor_json.py -q
uv run python scripts/usage_probe.py --repo-root . --harness opencode --level both --days 14 --json
uv run python scripts/discover_surfaces.py --repo-root . --level both --harness claude-code --harness claude-desktop --harness chatgpt --harness codex --harness cursor --harness cursor-cli --harness grok-build --harness opencode --harness perplexity-desktop --harness cherry-studio --harness lm-studio

完了条件：

• メタデータと評価マニフェストが検証に合格する
• パッケージのポータビリティが維持されている
• サーフェス検出のスモークチェックが、すべての標準ハーネスを受け入れる
• ドライラン／適用の動作で、編集前に承認が引き続き必要である
• Discover は引き続き読み取り専用であり、対応する監査が承認されるまで適用をブロックする
• usage review は引き続き読み取り専用であり、機密性の高いソースをマスキングし、対応する監査が承認されるまで適用をブロックする

ハーネス横断の統合契約

各ハーネスのレビュー後、次の内容を統合します。

• ハーネス間で共通する問題
• 矛盾する規約や優先順位ルール
• 重複する指示ソースや MCP 定義
• 生成物と標準版の間に見られるドリフトのパターン
• ユーザーが後続の適用バッチを希望する場合の、最も効果の大きい整理の順序

出力契約

ハーネスごとのレポートには、必ず次の項目を含めます。

1. ハーネス
2. レベル
3. レビューしたファイル
4. 確認したドキュメント
5. プロジェクトコンテキストの概要
6. 見落としやすい点
7. 評価表
8. 指摘事項
9. 推奨する変更
10. パッチ案のプレビュー
11. 信頼度

2つ以上のハーネスをレビューした場合は、続けてハーネス横断の統合セクションを追加します。

リファレンスファイル一覧

ファイル	内容	読み込むタイミング
references/workflow.md	ゲートごとの監査／適用ワークフロー、優先順位ルール、縮退モード、承認ゲートの詳細	Audit、Apply Approved
references/latest-doc-sources.md	各ハーネスの公式 llms.txt とドキュメント URL、およびフォールバック順	最新ドキュメントの更新
references/harness-surfaces.md	プロジェクト／グローバルのサーフェス、優先順位、インストール時のエージェント名、生成／統合される注記	サーフェスの解釈
references/harness-checklists.md	ハーネスごとの監査チェックリストとエッジケース	ハーネスごとのレビュー
references/evidence-boundaries.md	エビデンスタグ、死角への対処、矛盾に関する方針	調査結果の報告
references/install-guidance.md	正確な npx skills add ... コマンド、提示するタイミング、アンチパターン	インストールガイダンス
references/output-format.md	ハーネスごと、およびハーネス横断レポートのテンプレート	最終出力
references/discovery-pipeline.md	W0～W4 の探索ウェーブ、深度の推定、エビデンスと契約、リダイレクト	Discover
references/discovery/	コーディネーターの契約、調査担当用テンプレート、出力形式、調査の統合	Discover の調査担当とレポート
references/ecosystem-research.md	レガシーソースファミリーに関する注記。ディスパッチには discovery-pipeline.md を優先してください	Discover W2 のソース計画
references/source-profiles.md	ソースファミリー、プログラムによるアクセス、信頼度の役割、縮退時のソースの動作	Discover W2 のソース計画
references/usage-review.md	読み取り専用の利用状況ソース、プライバシークラス、スコアカード、シグナルスキーマ、推奨レーン	利用状況のレビュー
data/research-sources.json	ソース計画とプローブスクリプト用の機械可読なソースレジストリ	Discover W2 のソース計画

現在のステップに必要なリファレンスのみを読み込んでください。すべてのリファレンスを事前に読み込まないでください。

段階的な情報開示

現在のモードに応じて、指定されたリファレンスファイルを読み込みます。すべてのリファレンスを一度に読み込まず、ディスパッチテーブル、ソース計画、最終出力の要件に基づき、関連する最小限のファイルを選んでください。

正規用語

これらの用語は harness-master のレポートで正規のものとして定められており、指定どおりに使用してください。

以下の用語を全体で指定どおりに使用してください。

用語	意味	使用しない用語
harness	サポート対象のエージェント／ランタイムのターゲットひとつ	editor、toolchain
level	レビューのスコープを示す project、global、または both	environment
project surface	ハーネスが使用する、リポジトリ内のファイルまたは生成された成果物	global config
global surface	リポジトリ外にある、ユーザーレベルのハーネス設定	project file
dry-run	検出結果とパッチプレビューのみを表示し、編集は行わない	apply
approval gate	編集前に明示的なユーザーの同意が必要であること	implied approval
blind-spot	現在のセッションでは観測できないサーフェスまたは動作	guess
repo-observed	現在のコードベースにおける実際のハーネス構成から推測された動作	official-doc evidence
patch preview	編集前に提示される、提案された差分またはコードスニペット	applied change
canonical source	生成された出力ではなく、変更すべきファイルまたは設定	generated surface
source plan	ソース、URL／コマンド、環境変数、エビデンス項目、障害モードをまとめた読み取り専用のリスト	apply plan
candidate dossier	ひとつのエコシステム候補について、正規化されたエビデンスをまとめたもの	endorsement
support tier	エビデンスと検証状態に裏付けられた、導入準備度の区分	popularity rank
quarantine	認証情報、プロキシ、破壊的操作、攻撃的行為、または広範な権限に関するリスクがある候補の区分	rejection without review
usage signal	トークン、コスト、クォータ、ツール、MCP、スキル、プラグイン、またはワークフローの動作に関する、サニタイズ済みの集計エビデンス	raw transcript
privacy class	ソースを収集・要約できるか、手動のみで扱う必要があるかを決定する機密性の区分	permission bypass

重要なルール

1. 新しい harness-master の実行はすべて、ドライラン監査モードで開始します。
2. ユーザーの明示的な承認を得る前に、編集してはいけません。
3. Apply Approved が有効なのは、同じセッション内で対応するドライランのレビューを行った後に限られます。
4. 不足している入力のみを尋ねてください。解決済みのハーネスやレベルを再度尋ねてはいけません。
5. ハーネスの変更を推奨する前に、必ずプロジェクトのコンテキストを調査してください。
6. 構成が最新または古いと判断する前に、必ず最新の公式ガイダンスを確認してください。
7. 見落としがある箇所は明示してください。隠れた設定や UI でしか確認できない設定を推測してはいけません。
8. 証拠から明らかな場合は、生成された出力やマージ済みの出力ではなく、正規のソースを編集してください。
9. すべての指摘に、証拠タグ verified-file、verified-doc、repo-observed、blind-spot のいずれかを付けてください。
10. 適切な編集内容が明らかな場合は、必ず具体的なパッチのプレビューを表示してください。
11. インストールが次の適切な手順である場合に限り、npx skills add ... を使用してください。
12. サポート対象外のハーネスは明確に拒否し、サポート対象を一覧で示してください。
13. エコシステムの調査は参考情報の提供のみを目的とし、読み取り専用です。調査レポートだけを根拠に適用してはいけません。
14. 認証情報が必要な API は任意の補足情報です。認証情報がない場合は確信度が下がりますが、ソースに基づく基本的な計画を妨げてはいけません。
15. GitHub GraphQL は既知の候補リポジトリの情報を補足するために使用します。広範な検索には REST／検索、またはコード／ファイル検索を使用してください。
16. Usage Review は参考情報の提供のみを目的とし、読み取り専用です。Usage Review の指摘だけを根拠に、構成変更の適用、ツールのインストール、未加工のセッションのエクスポート、未加工のプロンプト／トレースの表示を行ってはいけません。
17. Usage Review では、集計しても安全な情報源やサニタイズ済みのメタデータ情報源を使用できます。ただし、シークレットファイル、認証情報の値、未加工のトランスクリプト、未加工のトレース、メッセージテーブルの未加工の本文は対象外です。
18. 正規化されたパス、有効なマニフェスト、ディレクトリ名／名前が一致し説明が空でない、読み取り可能かつ移植可能な SKILL.md のフロントマターを満たした場合に限り、構成済みの Grok プラグインをリポジトリスキルの所有者として扱います。所有権が無効な場合、専用の有効化はフェイルクローズしますが、外部スキルへのフォールバック動作は変更しません。
19. 保存済みワークフローの投影、カナリアでゲートされたレガシー移行、ロールバックでは、すべて同一の正確なレシートダイジェストを使用してください。内容が異なるワークフローを上書きしたり、検出ルート内にワークフローのバックアップを保持したりしてはいけません。ミューテーションロックを導出する前に、レシートパスとロールバック形状を完全に検証してください。また、正確なアクティブな適用所有者マーカーがある場合に限り、投影されたワークフローを削除してください。レシートが所有するワークフローの inode を破棄する前に、トランザクション固有の rolled-back トゥームストーンを公開し、永続的に同期してください。このトゥームストーンは削除してはいけません。