meta-optimize

Meta-Optimize：ARIS 向け外側ループのハーネス最適化

各レビュアー枠の前に、選択可能なレビュアーに従ってください： 呼び出しを解決 → .aris/reviewer.json → Claude Code のデフォルト（Codex MCP） の順に、正規ヘルパーリゾルバーを通じて reviewer_route.py を使用し、 この枠のティア、新しいコンテキスト、ソース／画像入力、決定論的ゲートを 保持します。以下の Codex の例／固定指定は backend=codex の場合にのみ適用されます。 ほかのルートでは、それぞれ固有の初回呼び出し／返信の契約を使用します。 ルートと、実際に返された識別情報を保存してください。 選択したレビュアーが利用できない場合は REVIEW_UNAVAILABLE です。 実際のファミリー／完了状況／スコープに基づいて受け入れ可否を分類します。 呼び出し時のレビュアー／モデル／推論労力の上書き設定は、レビュアーを使用する 子プロセスに引き継ぎます。生成ワーカーに変更はありません。

蓄積された利用ログを分析し、次の最適化案を提示します：$ARGUMENTS

権限の境界 — このスキルは読み取り専用の生成役です

meta-optimize が行うのは提案であり、反映ではありません。スキルコーパスの 変更は、別途、人間が呼び出すスキルである /meta-apply の 専任作業です。この分離は単なる助言ではなく、構造上のものです。指示を見落としても、 このループが自らのパッチを適用できないようにするためです（自己正当化の失敗モード）。

• Write／Edit ツールは使用できません。 このスキルは、コーパス内の SKILL.md／ shared-reference／その他のファイルを、手軽な変更ツールで編集できません。 出力できるのは REPORT とステージ済みパッチファイルのみで、書き込み先は .aris/meta/（コーパスではない一時領域）です。
• 適用ステップはありません。 スキル内に「パッチを適用する」経路はありません （ステップ 6 を参照）。生成役は、承認済みパッチを /meta-apply 用に ステージして終了します。その後、人間が /meta-apply を呼び出して 反映する必要があります。この人間による操作が反映ゲートです。
• コーパスへの Bash 書き込みはフィルタリングされますが、不可能ではありません。 多層防御の実態を正確に説明してください。 完全に防がれているのは、偶発的／ 実行中の自己正当化です。このスキルには Write／Edit も適用ステップもないため、 通常の実行でコーパスの編集に紛れ込むことはありません。多層防御として、 corpus_write_guard の PreToolUse フック（meta_logging.json と同様）をインストールすると、コーパスの パスに対する一般的な Bash シェル書き込み（>、tee、sed -i、cp／mv、 touch、open(...,'w')）を拒否できます。これはブラックリストであり、完全な サンドボックスではありません。 意図的に難読化された Bash 書き込み（git apply、 patch、$var／絶対パス、言語のファイル API など）は、すべて検出できるわけでは ありません。完全な構造的防止には、このスキルから Bash を取り除くか、 FS サンドボックスを設ける必要があります。 まだ重要な基盤となっていない生成役 には過剰な構成のため、ゲートが実際の自動変更量を担う段階（ブリック 3 の トリガー）まで延期されています。意図的な書き込みに対する想定上の最後の砦は、 防止ではなく検出です。正当かつ最新の provenance スタンプがない （コンテンツハッシュが不一致の）コーパス変更は、プッシュ前の整合性チェックで 検出可能なはずです。ただし、その検証機能はまだ実装されていません。 provenance.py には content_hash がありますが、整合性チェック用の サブコマンドはなく、それを実行するプッシュ前フックもありません。したがって、 現時点では意図的な書き込みを防止できず、積極的に検出することもできません。 この生成役が重要な基盤となる前に、整合性検証機能をフォローアップ項目として 管理してください。このスキルが正当に行う Bash 書き込み先は .aris/meta/ のみです。

shared-references/acceptance-gate.mdを参照してください。 ループは同一モデルで実行（提案、レビュー）できますが、変更を反映する承認 （ステップ 4 の審査）はモデル横断でなければなりません。さらに、反映は 別個の、人間によるゲート付き操作（/meta-apply）でなければなりません。

コンテキスト

ARIS はリサーチハーネスです。LLM を取り囲み、リサーチを調整するスキル、ブリッジ、ワークフロー、成果物の契約から成るシステムです。このスキルは、ハーネス自体の使用状況を観察し、ハーネスの改善を提案する（生成するリサーチ成果物の改善ではありません）プロトタイプの外側ループを実装します。

Meta-Harness（Lee et al., 2026）に着想を得ています。重要な洞察は、ハーネスの設計はモデルの重みと同じくらい重要であり、実行トレースを記録して改善の指針にすることで、ハーネスのエンジニアリングを部分的に自動化できるということです。

このスキルが最適化するもの（ハーネスの構成要素）

構成要素	例	最適化可能か
SKILL.md のプロンプト	レビュアーへの指示、品質ゲート、ステップの説明	はい
デフォルトパラメーター	difficulty: medium、MAX_ROUNDS: 4、threshold: 6/10	はい
収束ルール	レビューループを停止するタイミング、再試行回数	はい
ワークフローの順序	ワークフロー内のスキルチェーンの順序	はい
成果物スキーマ	EXPERIMENT_LOG.md、idea-stage/IDEA_REPORT.md に含めるフィールド	慎重に
MCP ブリッジの設定	使用するレビュアーモデル、ルーティングルール	いいえ（インフラ）

最適化対象外：リサーチ成果物そのもの（論文、コード、実験）。これらは通常のワークフローで扱います。

前提条件

1. ロギングが有効である必要があります。 templates/claude-hooks/meta_logging.json をプロジェクトの .claude/settings.json にコピーしてください（または hooks セクションをマージしてください）。
2. 十分なデータが必要です。 .aris/meta/events.jsonl に記録されたワークフローの実行が、完全な状態で少なくとも 5 回必要です。このスキルはデータが不十分な場合に確認し、警告します。

ワークフロー

ステップ 0：データの有無を確認する

EVENTS_FILE=".aris/meta/events.jsonl"
if [ ! -f "$EVENTS_FILE" ]; then
    echo "ERROR: No event log found at $EVENTS_FILE"
    echo "Enable logging first: copy templates/claude-hooks/meta_logging.json into .claude/settings.json"
    exit 1
fi

EVENT_COUNT=$(wc -l < "$EVENTS_FILE")
SKILL_INVOCATIONS=$(grep -c '"skill_invoke"' "$EVENTS_FILE" || echo 0)
SESSIONS=$(grep -c '"session_start"' "$EVENTS_FILE" || echo 0)

echo "📊 Event log: $EVENT_COUNT events, $SKILL_INVOCATIONS skill invocations, $SESSIONS sessions"

if [ "$SKILL_INVOCATIONS" -lt 5 ]; then
    echo "⚠️  Insufficient data (<5 skill invocations). Continue using ARIS normally and re-run later."
    exit 0
fi

# Bottleneck succession: what did the LAST cycle say was the limiting stage?
BOTTLENECK_LOG=".aris/meta/bottleneck_log.jsonl"
if [ -f "$BOTTLENECK_LOG" ]; then
    echo "🧭 Prior cycle's bottleneck: $(tail -1 "$BOTTLENECK_LOG")"
fi

以前のボトルネックの記録がある場合は、レポート（ステップ 5）の冒頭で、 そのボトルネックが解消されたかどうか（適用済みのパッチも併記）と、 現在は何に移ったのかを明記してください。この台帳が記録するのは、 単にボトルネックが存在するかどうかではなく、その移り変わりです。

ステップ 1：使用パターンを分析する

.aris/meta/events.jsonl を読み込み、次の項目を算出します。

頻度分析：

• 最も頻繁に呼び出されているスキルはどれですか？
• ユーザーが最もよく入力するスラッシュコマンドはどれですか？
• 最もよく使われるパラメーターの上書きは何ですか？（デフォルト設定に問題があることを示唆します。）

失敗分析：

• 最も頻繁に失敗するツールはどれですか？どのスキルで発生していますか？
• 繰り返し発生するエラーパターンは何ですか？（OOM、インポート、コンパイル、タイムアウト）
• ワークフローの実行ごとに、自動デバッグの再試行は何回行われていますか？

収束分析（auto-review-loop 向け）：

• しきい値に達するまでの平均ラウンド数
• スコア推移の形状（急速に改善？頭打ち？変動？）
• 最も重要な問題を検出するのは、どのレビューラウンドですか？
• 実行中にユーザーが難易度を上書きしていますか？

人間による介入の分析：

• ワークフロー中に、ユーザーが手動プロンプトを入力して中断するのはどの時点ですか？
• ユーザーが最もよく行う手動修正は何ですか？（スキルの不足を示しています。）

モデル差分分析（ハーネスのスリム化）：

• セッションモデル（session_start イベントの model フィールド）または固定されたレビュアーモデルは、スキルの SKILL.md が最後に更新されてから変更されていますか？ （git log -1 --format=%cs -- skills/<skill>/SKILL.md とモデル更新日を比較します。）
• モデルの更新は再読のきっかけであり、それだけでは証拠になりません。その SKILL.md にある推論の足場となる各ステップや実例について、新しいモデルがそれを必要としなくなったという、対象を特定した証拠に基づいて削除を提案する必要があります。証拠には、特定の能力に関するリリースノート、またはイベントログで観測された動作の繰り返し（例：モデル更新後、ガード対象のステップで失敗や介入が一度もないこと）が該当します。「モデルが新しくなった」だけでは、削除の根拠になりません。
• モデルにかかわらず、削除候補にしてはならないもの： 権限境界、受け入れ／レビューのゲート、コーパスと来歴の完全性に関するルール、出力契約、安全性チェック。スリム化の対象は、モデルの能力を補う足場だけです。新しいモデルが本来備えている能力を補うものは、コンテキストの負荷、逸脱の発生源、読解コストを増やすだけです。ハーネスが増え続けるだけなら、誰も読み返さないハーネスになってしまいます。

トリガー率分析（任意、実測値。イベントログからは算出しません）：

• イベントログから分かるのは、使用されたスキルであり、使用したかったが選ばれなかったスキルではありません。インストール済みリストが長いために Claude Code が適切なスキルを見送るという、スキルの選択漏れはログからは確認できません。tools/meta_opt/trigger_eval.py はこれを直接測定します。中立的な作業ディレクトリから claude -p で意図を言い換えたクエリを実行し（これにより、現実的な長さのインストール済みコーパスが読み込まれます）、トリガー／混同（→どのスキルか）／見逃しとして評価します。
• 特定のスキルがトリガーされにくい、または誤ってトリガーされている疑いがある場合や、説明を編集する前後で確認する場合に実行します。 python3 tools/meta_opt/trigger_eval.py --eval-file tools/meta_opt/trigger_evals.sample.json --skills <name> --samples 2
• 指標だけでなく、混同行列が重要なシグナルです。同じクエリが繰り返し類似のスキルに振り分けられるなら、その意図について両者の説明が重複しています。必要なのは区別を明確にすることであり、「説明をより強く押し出す」ことではありません。
• 測定のみを行い、証拠として扱います。判定には使いません。 トリガー率が低い場合はステップ 2 の提案に反映するための入力ですが、説明を書き換えて自己適用してはいけません。変更が適用されるのは /meta-apply 経由のみです。トリガー率はモデルに依存するため、同じ条件で比較し（プローブに使用したモデルを記録してください）、あくまで代理指標として扱います。測定対象はクエリセットに対する選択であり、長いリスト全体で発生するスキルの選択漏れではありません。

調査結果は、構造化された要約テーブルとして提示してください。

ステップ 1.5：現在のボトルネックを特定する

ステップ 1 の分析をまとめ、現時点で最も制約となっている単一のパイプライン段階を、根拠とともに 1 文で示します。たとえば、「計画」「検証の品質」「実験実行の信頼性」「文章の仕上げ」などです。ボトルネックは常に移り変わります。コーディングが制約でなくなると計画が制約になり、計画が解決されると検証が、検証が自動化されるとセンスが制約になります。このステップでは、現在の制約を明確にします。これにより、ステップ 2 の順位付けされた表が、ばらばらの微調整ではなく、特定された 1 つの制約に対する修正案として読めるようになります。

判定結果を追記専用の台帳 .aris/meta/bottleneck_log.jsonl に追記します（.aris/runs/<run_id>.iterations.jsonl と同じく、決して変更しない運用です）。

mkdir -p .aris/meta
# json.dumps, NOT hand-interpolated shell strings: bottleneck/evidence are
# natural language — a stray quote must not break the JSONL (or the shell).
python3 - <<'PY'
import json, datetime
entry = {
    "ts": datetime.datetime.now().astimezone().isoformat(timespec="seconds"),
    "cycle": 3,
    "bottleneck": "verification quality",
    "evidence": "review rounds plateau at 6/10 while tool failures are rare",
    "top_patch_ids": ["P1", "P2"],
}
with open(".aris/meta/bottleneck_log.jsonl", "a", encoding="utf-8") as fh:
    fh.write(json.dumps(entry, ensure_ascii=False) + "\n")
PY

過去の行は編集も削除もしないでください。変遷の履歴こそが重要です。

ステップ 2：最適化の対象を特定する

ステップ 1 に基づき、期待される効果の大きい順に最適化の機会を並べます。

## Optimization Opportunities (ranked)

| # | Target | Signal | Proposed Change | Expected Impact |
|---|--------|--------|-----------------|-----------------|
| 1 | auto-review-loop default threshold | Users override to 7/10 in 60% of runs | Change default from 6/10 to 7/10 | Fewer manual overrides |
| 2 | experiment-bridge retry count | 40% of runs hit max retries on OOM | Add OOM-specific recovery (reduce batch size) | Fewer failed experiments |
| 3 | paper-write de-AI patterns | Users manually fix "delve" in 80% of runs | Add "delve" to default watchword list | Fewer manual edits |
| 4 | experiment-bridge Phase-2 hand-holding steps | Model bump (session_start model changed); scaffold untouched since 2 generations ago; zero tool_failures in the steps it guards | **DELETE steps N–M — the new model does this unprompted** | Smaller harness, less drift surface |

提案変更列では、明示的に削除も認められています。「新しいモデルが無料で対応するため、ステップ N を削除」は、追加と同じ影響度の基準で順位付けする、正式な最適化案です。

$ARGUMENTS に対象スキルが指定されている場合は、そのスキルだけを分析します。 $ARGUMENTS が空または "all" の場合は、十分なデータがあるすべてのスキルを分析します。

ステップ 3：パッチ案を生成する

各最適化対象について、具体的な差分を生成します。

--- a/skills/auto-review-loop/SKILL.md
+++ b/skills/auto-review-loop/SKILL.md
@@ -15,7 +15,7 @@
 ## Constants
 
-- **SCORE_THRESHOLD = 6** — Minimum review score to accept.
+- **SCORE_THRESHOLD = 7** — Minimum review score to accept. (Raised based on usage data: 60% of users overrode to 7+.)

パッチ生成のルール：

• 最適化対象ごとにパッチを 1 つ作成します
• 各パッチには、理由（ログのデータに基づく）を説明するコメントを含めます
• パッチは最小限にします。データで裏付けられる変更だけを行います
• v1 ではアーティファクトのスキーマや MCP ブリッジの設定を変更しないでください
• 既存のユーザーワークフローを壊す動作変更は行わないでください
• 自己汚染防止の確認（shared-references/capture-antipatterns.md を参照）： 提案パッチの根拠を tools/capture_filter.py に通します（正規のチェーンをたどって解決します）。ツールの能力に関する否定的な主張（「codex は……できない」「gemini は壊れている」）や、一度限り／一時的な失敗を恒久的なルールとして埋め込む変更は、決して提案しないでください。そうしたルールは、自己引用する拒否へと固定化されます。「X は Y ができない」ではなく、修正方法／必要なフラグ／回避策を記述してください。

ステップ 4：パッチのクロスモデルレビュー（助言用の事前確認）

このレビューは助言用です。ステップ 5 のレポートを明確にし、人間がステージする内容を判断できるようにします。最終的な採否判定ではありません。拘束力のあるクロスモデル審査は、実際にステージされた差分を対象に、後の適用時に /meta-apply 内で実施されます（作成者から中継された判定結果は偽造可能なためです）。この結果は advisory_screen としてのみ記録してください。

各パッチを GPT-6-Astra xhigh に送り、敵対的レビューを受けます。

まずこのレビュアー枠を解決してください。以下は backend=codex の例です。

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are reviewing a proposed optimization to an ARIS SKILL.md file.
    
    ## Original Skill (relevant section)
    [paste original]
    
    ## Proposed Patch
    [paste diff]
    
    ## Evidence from Usage Log
    [paste summary stats]
    
    Review this patch:
    1. Does the evidence support the change?
    2. Could this change hurt other use cases?
    3. Is the change minimal and safe?
    4. Score 1-10: should this be applied?
    
    If score < 7, explain what additional evidence would be needed.

    === SCOPE LIMITS (these bound what you PROPOSE, never what you look for) ===
    Report anything that is actually wrong here — including a rare-looking case, if
    this repo actually produces it. Then keep the fix in scope:
    1. This is a RESEARCH-WORKFLOW tool, not a security paper. Verification is
       welcome; over-defense is not. Assume a cooperating operator on their own
       machine — a malicious local user is NOT in the threat model.
    2. Do NOT propose SHA / hash / content-fingerprint / digest-binding schemes.
       Reporting a real defect in hashing code that already exists is fine.
    3. NO speculative machinery: do not add feature flags, migration frameworks,
       compat layers, wrappers, pins, or similar mechanisms unless evidence shows
       a current repo defect they fix or an explicit existing invariant they must
       preserve. "Load-bearing", "compatibility", and "not scaffolding" are labels,
       not evidence. Point to the failing path/artifact or invariant, and check the
       proposal's factual premises, such as whether a named package version exists.
    4. NO corner-case obsession: exotic encodings, symlink races, RTL text and
       millisecond races are out of scope unless you can show the case arises here.
    5. Where a rubric or checklist is genuinely needed, do not over-mechanize
       judgement. A clear sentence a human reads beats a scored table nobody
       maintains.
    Exception: code that runs remote commands, starts a network service, or installs
    an MCP server runs on the user's machine with their credentials — trust-boundary
    findings there are in scope and the default is strict.
    Say plainly when something is correct. Do not manufacture findings.

ステップ 5：結果を提示する

構造化されたレポートを出力します。

# ARIS Meta-Optimization Report

**Date**: [today]
**Data**: [N] events, [M] skill invocations, [K] sessions
**Target**: [skill name or "all"]

## Current Bottleneck

**[one-phrase name]** — [one-line evidence]. Prior cycle's bottleneck: [name —
resolved by <patch ids> / unresolved / first recorded cycle]. (Ledger:
`.aris/meta/bottleneck_log.jsonl`)

## Proposed Changes

### Change 1: [title]
- **Target**: [skill/file:line]
- **Signal**: [what the data shows]
- **Patch**: [diff]
- **Reviewer Score**: [X/10]
- **Reviewer Notes**: [summary]
- **Status**: ✅ Recommended / ⚠️ Needs more data / ❌ Rejected

### Change 2: ...

## Changes NOT Made (insufficient evidence)
- [pattern observed but too few samples]

## Recommendations
- [ ] Apply Change 1 (reviewer approved)
- [ ] Collect more data for Change 3 (need N more runs)
- [ ] Consider manual review of Change 2

## Next Steps
This skill only **proposes**. To land changes: tell me which to stage, then run
`/meta-apply` (a separate, human-invoked applier that re-checks the cross-model
verdict before mutating anything). meta-optimize never applies.

ステップ 6：承認済みパッチを /meta-apply 用にステージングする（スキル内では適用しない）

このスキルでは何も適用しません。ユーザーがステップ 5 のレポートを読み、反映する変更を指定した後、特権アプライヤー用にステージングします。

1. 承認された各変更 N について、統合差分を .aris/meta/pending/<NN>_<skill>.diff に書き込み、次の行を .aris/meta/pending/manifest.jsonl に追加します。 {patch: "<NN>_<skill>.diff", target: "<corpus path>", author_model: "<executor>", advisory_screen: "pass|kill", advisory_reason: "<one line>"}。 advisory_screen（ステップ 4 の Codex による事前レビュー）は助言のみです。人間がレポートを読む際の参考になります。これは反映の判定ではなく、/meta-apply はこれを信頼しません。生成側が書き込む判定結果は偽造できるためです。拘束力のあるクロスモデル審査は、実際にステージングされた差分を対象に、反映時に /meta-apply 内で行われます。
2. ユーザーに次のように伝えます。"M 件のパッチをステージングしました。/meta-apply を実行して、審査して反映してください。"

バックアップ → 反映時の新たな審査 → 適用 → 来歴の記録 → ログのすべては、/meta-apply 内で行われます。meta-optimize はコーパスに触れず、無罪判定も行いません。

このスキルでは決して適用しないでください。反映には常に /meta-apply、新たな審査、そして人間の判断が必要です。

主なルール

• 推測ではなく、ログに基づくこと。 提案する変更はすべて、イベントログ内の具体的なデータを根拠として示す必要があります。「こちらの方がよいと思います」では不十分です。
• パッチは最小限に。 一度に変更するのは一つだけです。スキル全体を書き直してはいけません。認められている大規模な編集は、TARGET-SPECIFIC なモデル差分の証拠（機能に特化したリリースノート、または足場が使われていないことを示す、バージョン変更後に繰り返し観測されたイベントログの挙動）に基づく足場の削除だけです（モデル名の変更は調査開始のきっかけにはなりますが、それだけでは証拠として不十分です）。権限境界、受け入れゲート、コーパス／来歴のルール、出力契約、安全チェックは、削除の対象にはなりません。削除にも、他の変更と同じレビューおよび承認ゲートを適用します。
• レビュアーの承認を必須とすること。 すべてのパッチは、推奨する前にクロスモデルレビューを受けます。
• 元に戻せるようにすること。 適用前には必ずバックアップを取り、変更内容を必ず記録します。
• ユーザーの承認を得ること。 自動適用は禁止です。内容を提示して説明し、ユーザーに判断してもらいます。
• 不確実性について正直であること。 データが不十分な場合は、その旨を伝えます。ノイズに基づいて最適化してはいけません。
• 幅広く使えること。 最適化によって、特定のユーザーのスタイルだけでなく、すべてのユーザーにとってスキルが改善されるようにします。ユーザー固有と思われる変更は、その旨を明示します。

イベントスキーマの参照

.aris/meta/events.jsonl のログには、次の形式の JSONL レコードが含まれます。

{"ts":"...","session":"...","event":"skill_invoke","skill":"auto-review-loop","args":"difficulty: hard"}
{"ts":"...","session":"...","event":"PostToolUse","tool":"Bash","input_summary":"pdflatex main.tex"}
{"ts":"...","session":"...","event":"codex_call","tool":"mcp__codex__codex","input_summary":"review..."}
{"ts":"...","session":"...","event":"tool_failure","tool":"Bash","input_summary":"python train.py"}
{"ts":"...","session":"...","event":"slash_command","command":"/auto-review-loop","args":""}
{"ts":"...","session":"...","event":"user_prompt","prompt_preview":"change difficulty to hard"}
{"ts":"...","session":"...","event":"session_start","source":"startup","model":"claude-opus-4-6"}
{"ts":"...","session":"...","event":"session_end"}

トリガー

このスキルは、標準の W1→W1.5→W2→W3→W4 パイプラインには含まれません。次の 3 つのトリガー方式を持つメンテナンスワークフローです。

1. 受動的なログ記録（常時有効）：Claude Code のフックが、通常の使用中にイベントを .aris/meta/events.jsonl へ自動的に記録します。ユーザーの作業は不要です。

2. 自動準備状況チェック（SessionEnd フック）：Claude Code のセッション終了時に、check_ready.sh が前回の /meta-optimize 実行後のスキル呼び出し数を数えます。新しい呼び出しが 5 件以上蓄積されている場合、リマインダーを表示します。

   📊 ARIS has logged 8 skill runs since last optimization. Run /meta-optimize to check for improvement opportunities.
   

   また、呼び出し数にかかわらず、前回の最適化以降にセッションのモデルが変更されている場合も実行されます（.aris/meta/.last_optimize_model と比較します）。

   🔁 Model changed since last optimization (claude-opus-4-6 → claude-opus-4-8). Run /meta-optimize — a model bump makes existing scaffolding a deletion candidate (harness diet).
   

   どちらも提案のみであり、最適化を自動実行するものではありません。

3. 手動トリガー：ユーザーは、リマインダーを確認したとき、または任意のタイミングで /meta-optimize を実行します。

各 /meta-optimize の実行後、スキルは現在のタイムスタンプを .aris/meta/.last_optimize に、現在のセッションモデル（最新の session_start イベントの model フィールド）を .aris/meta/.last_optimize_model に書き込みます。これにより、準備状況チェックで新たな使用状況とモデルの変更の両方を検出できます。

謝辞

Meta-Harness（Lee et al., 2026）に着想を得ています。ファイルシステムベースの経験へのアクセスと、エージェントによるコード検索を通じて、モデルハーネスをエンドツーエンドで最適化する研究です。

出力プロトコル

すべての出力ファイルで、次の共通プロトコルに従ってください。

• 出力バージョニングプロトコル — まずタイムスタンプ付きファイルを書き込み、その後、固定名にコピーします
• 出力マニフェストプロトコル — すべての出力を MANIFEST.md に記録します
• 出力言語プロトコル — プロジェクトの言語設定を遵守します

レビューのトレース記録

mcp__codex__codex または mcp__codex__codex-reply によるレビュー呼び出しのたびに、shared-references/review-tracing.md に従ってトレースを保存してください（ポリシー C — フォレンジック。黙って省略しないでください）。shared-references/integration-contract.md §2 の手順に沿って解決した save_trace.sh を使用するか、.aris/traces/<skill>/<date>_run<NN>/ にファイルを直接書き込んでください。--- trace: パラメーターを遵守してください（デフォルト：full）。