/aris-meta-optimize

name: aris-meta-optimize
description: "Analyze ARIS usage logs and propose optimizations to SKILL.md files, reviewer prompts, and workflow defaults. Outer-loop harness optimization inspired by Meta-Harness (Lee et al., 2026). Use when user says \"优化技能\", \"meta optimize\", \"improve skills\", \"分析使用记录\", or wants to optimize ARIS's own harness components based on accumulated experience."
argument-hint: "[target-skill-or-all]"
license: MIT
metadata:
  author: wanshuiyin/ARIS
  version: "2.0.0"
  upstream-commit: f1bd907b58f653131ebe6807c482e2554e07f9b9
allowed-tools: Bash(*), Read, Grep, Glob, mcp__codex__codex, mcp__codex__codex-reply

Meta-Optimize: Outer-Loop Harness Optimization for ARIS

Analyze accumulated usage logs and propose optimizations for: **$ARGUMENTS**

Privilege boundary — this skill is a READ-ONLY PRODUCER

aris-meta-optimize **proposes**; it does not **land**. The mutation of the skill corpus is the exclusive job of a separate, human-invoked skill: [`/aris-meta-apply`](../aris-meta-apply/SKILL.md). This is a workflow/tool-grant boundary, **not an OS sandbox**. The skill does not request `Write`/`Edit` and has no apply step. Its legitimate Bash writes are reports, staged diffs and bookkeeping under `.aris/meta/`, plus forensic reviewer traces under `.aris/traces/`. `allowed-tools` does not revoke capabilities granted by the host; do not claim a prompt can prevent every filesystem write.

The optional [`corpus_write_guard`](../aris-infra/templates/claude-hooks/corpus_write_guard.json) PreToolUse hook filters common Bash corpus-write patterns. It is a blacklist, **NOT a complete sandbox**: obfuscated writes, absolute paths, `git apply` and other language APIs can escape it. It does not gate Write/Edit. Full prevention requires host-enforced read-only corpus permissions. No pre-push provenance integrity verifier is installed; deliberate bypass is not actively detected. See [skill governance](../aris-infra/shared-references/skill-governance.md).

See [`shared-references/acceptance-gate.md`](../aris-infra/shared-references/acceptance-gate.md): a loop can DRIVE (propose, review) same-model, but the ACQUITTAL that lands a change must be cross-model (fresh landing jury, not Step 4 advisory screen) **and** the landing must be a separate human-gated act (`/aris-meta-apply`).

Context

ARIS is a **research harness** — a system of skills, bridges, workflows, and artifact contracts that wraps around LLMs to orchestrate research. This skill implements a prototype **outer loop** that observes how the harness is used and proposes improvements to the harness itself (not to the research artifacts it produces).

Inspired by Meta-Harness (Lee et al., 2026): the key insight is that harness design matters as much as model weights, and harness engineering can be partially automated by logging execution traces and using them to guide improvements.

What This Skill Optimizes (Harness Components)

| Component | Example | Optimizable? | |-----------|---------|:---:| | SKILL.md prompts | Reviewer instructions, quality gates, step descriptions | Yes | | Default parameters | `difficulty: medium`, `MAX_ROUNDS: 4`, `threshold: 6/10` | Yes | | Convergence rules | When to stop the review loop, retry counts | Yes | | Workflow ordering | Skill chain sequence within a workflow | Yes | | Artifact schemas | What fields go in EXPERIMENT_LOG.md, idea-stage/IDEA_REPORT.md | Cautious | | MCP bridge config | Which reviewer model, routing rules | No (infra) |

**Not optimized**: The research artifacts themselves (papers, code, experiments). That's what the regular workflows do.

Prerequisites

1. **Logging is opt-in.** Follow [Workflow M setup](../../docs/aris-self-evolution.md) to preview and explicitly merge hooks, preserving existing `.claude/settings.json`. Never copy a template over that file or auto-enable logging. 2. **Sufficient evidence.** The readiness heuristic is at least 5 logged skill invocations, not proof of 5 complete workflows. Check run completeness and target-specific evidence before proposing changes. 3. **Resolve helpers** using [integration-contract.md §2](../aris-infra/shared-references/integration-contract.md). Before review read [reviewer-routing.md](../aris-infra/shared-references/reviewer-routing.md) for capability/family gates and [review-tracing.md](../aris-infra/shared-references/review-tracing.md). Missing/unusable reviewer means `REVIEW_UNAVAILABLE`, never implicit approval.

Workflow

Step 0: Check Data Availability

EVENTS_FILE=".aris/meta/events.jsonl"
if [ ! -f "$EVENTS_FILE" ]; then
    echo "ERROR: No event log found at $EVENTS_FILE"
    echo "Enable logging only by explicit merge; see docs/aris-self-evolution.md"
    exit 1
fi

EVENT_COUNT=$(wc -l < "$EVENTS_FILE")
SKILL_INVOCATIONS=$(grep -cE '"event": *"skill_invoke"' "$EVENTS_FILE" || true)
SESSIONS=$(grep -cE '"event": *"session_start"' "$EVENTS_FILE" || true)

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

If a prior bottleneck entry exists, open the report (Step 5) by stating whether that named bottleneck was **resolved** (and by which landed patches) and what it has now **moved to** — bottleneck SUCCESSION, not just existence, is the signal this ledger exists to carry.

Step 1: Analyze Usage Patterns

Read `.aris/meta/events.jsonl` and compute:

**Frequency analysis:**

• Which skills are invoked most often?
• Which slash commands do users type most?
• What parameter overrides are most common? (These suggest bad defaul