meta-apply skill
Privileged applier that LANDS meta-optimize / corpus-audit patches the user approved — the ONLY skill permitted to mutate the skill corpus from a self-modification proposal, with cross-model jury and human approval at landing. Use when the user says \"meta apply\", \"/meta-apply\", \"land the staged patches\", \"应用优化\", after a /meta-optimize run.
Is the meta-apply skill safe?
Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.
No findings.
Install the meta-apply skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/wanshuiyin/Auto-claude-code-research-in-sleep.git /tmp/Auto-claude-code-research-in-sleep mkdir -p ~/.claude/skills cp -r /tmp/Auto-claude-code-research-in-sleep/skills/meta-apply ~/.claude/skills/meta-apply
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
Meta-Apply: the privileged landing gate for self-modification patches
This skill exists to enforce a privilege boundary. Producers like /meta-optimize (and, later, corpus-audit) are read-only — no Write/Edit, no apply step; they can only stage candidate patches under .aris/meta/pending/. This skill is the only place a staged patch becomes a real change to the corpus. Splitting "propose" from "land" across two skills with different tool grants is what makes "a loop cannot apply its own patch" structural rather than a sentence the producer is asked to obey.
It is human-invoked only. It runs when the user explicitly types /meta-apply after reading the producer's REPORT. That invocation IS the landing authorization (the locked 2026-05-30 decision: the human stays at the landing gate).
The acquittal is generated HERE, not relayed
The earlier design trusted a juryverdict: pass field in the producer's manifest. That is forgeable — the producer writes that field, so a buggy/misaligned producer could stage a killed patch labelled "pass." So this skill does not trust any producer-written verdict. It runs the cross-model jury itself, at landing time, on the actual staged diff** (fresh thread, paths-only). The verdict is produced where it is consumed, by the privileged human-invoked skill — nothing to forge.
The non-negotiable rules (jury-at-landing, reject-default)
For each staged patch the user asks to land, in order — any failure ⇒ skip & report, never silently apply:
or all); default to applying nothing.
- The human named THIS patch. Apply only patches the user listed (/meta-apply 1,3
NOT codex-reply; model: gpt-6-astra, config: {"modelreasoningeffort": "ultra"}, sandbox: read-only, paths-only per reviewer-independence.md) on the staged .diff + its target. Ask: does this change improve the harness without regressions; PASS or KILL + one-line reason. Include the scope-limits block from review-scope-limits.md in that prompt: this jury judges ARIS's own mechanism, so an over-defensive KILL permanently blocks a good patch. Note the block bans proposing new hash binding — it is not a reason to KILL a patch that touches the existing provenance stamp. KILL ⇒ refuse. The human cannot override a KILL — they may only pick among jury-PASSED survivors. (A loop can DRIVE; only the cross-model jury can ACQUIT.)
- Fresh cross-model jury PASS, obtained now. Run mcpcodexcodex (fresh thread,
is the codex model that just judged it. Run provenance.py assertcrossfamily — if it raises (same family / unknown), refuse. (Here it always holds: producer=Claude, jury=codex. The check is the structural backstop.)
- Author ≠ reviewer family. The author is the producer's executor model; the reviewer
Workflow
Step 0: Load staging + resolve the helper
PENDING=".aris/meta/pending"
[ -d "$PENDING" ] || { echo "Nothing staged. Run /meta-optimize first."; exit 0; }
echo "Staged:"; cat "$PENDING/manifest.jsonl"Resolve provenance.py via the 4-layer chain in integration-contract.md §2 (.aris/tools/ → tools/ → $ARISREPO/tools/ → $ARISREPO/tools/ via ~/.aris/repo).
Step 1: Jury-at-landing for each requested patch
For every patch the user asked to land, read its staged .diff and target, then run the fresh codex jury (Rule 2) — paths-only, no producer reasoning, no prior-round context. Record {patch, juryverdict, jurythreadid, oneline_reason}. Print a one-line result per patch (PASS → eligible / KILL → refused: ).
The producer may have written an advisory pre-screen into the manifest to help the
human read the REPORT — ignore it for the landing decision. Only this fresh verdict
counts.
Step 2: Land the survivors (Write/Edit only — never Bash)
For each patch that PASSED Step 1 and was named by the user:
to copy contents; corpus paths are not Bash-writable when corpuswriteguard is active — and the applier should use Write/Edit for corpus mutation anyway).
- Back up the target to .aris/meta/backups// (use the Write tool
- Apply the diff by Edit/Write on the target corpus file.
- Stamp provenance on the changed file:
python3 "$PROVENANCE" stamp "$TARGET" --author "$AUTHOR" \
--reviewer "$JURY_MODEL" --verdict-id "$JURY_THREAD_ID"stamp() re-asserts cross-family and refuses on same-family — the structural backstop at the moment the authorization record is written. The stamp is a process receipt (who authored, who acquitted-at-landing, content hash) — NOT a claim the change is correct.
{ts, patch, target, authormodel, reviewermodel, jurythreadid, applied: true}.
- Log to .aris/meta/optimizations.jsonl:
Step 3: Report
Per patch: LANDED (+ backup path + provenance sidecar) or REFUSED : . Remove landed patches from .aris/meta/pending/. Remind the user a landed patch is revertable from its backup, and to test the changed skill next run.
Provenance is a receipt, not an acquittal of correctness
A stamp records that a change passed a process (cross-model jury at landing + human landing), not that it is correct. To prevent "approved-but-wrong with a stamp that vouches for it" (false-authority laundering — worse than no stamp, because a later auto-curator reads it as evidence):
invalidates it).
- The stamp carries verdictid (auditable review) + contenthash (a later hand-edit
artifacts, and a behavioral auditor that REVOKES a stamp when a landed skill misbehaves. Track as follow-up; never treat a stamp as permanent truth.
- Recommended (not yet built): a TTL forcing re-review of long-lived auto-authored
Key Rules
on the staged diff; never trust a producer-written verdict; the human picks among survivors, never resurrects a KILL.
- Human-invoked only. Never run as a side-effect of another skill or a hook.
- Jury-at-landing, reject-default, no override. The binding verdict is produced HERE
deterministic: reviewer is valid per skill-governance.md.
- Cross-family or refuse. assertcrossfamily must not raise. A
corpuswriteguard hook (if installed) additionally denies Bash corpus writes — it does NOT gate Write/Edit, so it does not by itself stop this skill from editing the corpus; the jury-at-landing + stamp discipline above is what governs Write/Edit mutations (that discipline is procedure, not a hook-enforced mechanism).
- Corpus mutation goes through Write/Edit (reviewable, attributable), not Bash. The
invents nothing of its own.
- Back up before every mutation. Reversible by construction.
- Only land staged patches. Applies what producers staged in .aris/meta/pending/;
Review Tracing
Save each landing-jury codex call's trace per review-tracing.md to .aris/traces/meta-apply/_run/ — the acquittal that landed a corpus change must be forensically recoverable.
More skills from wanshuiyin/Auto-claude-code-research-in-sleep
- Aablation-plannerUse when main results pass result-to-claim (claim_supported=yes or partial) and ablation studies are needed for paper submission.
- Aablation-plannerUse when main results pass result-to-claim (`claim_supported = yes` or `partial`) and ablation studies are needed for paper submission. A secondary Codex agent designs ablations from a reviewer's perspective; the local executor reviews feasibility and implements.
- AalphaxivQuick single-paper lookup via AlphaXiv LLM-optimized summaries with tiered source fallback. Use when user says "explain this paper", "summarize paper", pastes an arXiv/AlphaXiv URL, or provides a bare arXiv ID for quick understanding - not for broad literature search.
- AalphaxivQuick single-paper lookup via AlphaXiv LLM-optimized summaries with tiered source fallback. Use when user says "explain this paper", "summarize paper", pastes an arXiv/AlphaXiv URL, or provides a bare arXiv ID for quick understanding - not for broad literature search.
- Aanalyze-resultsAnalyze ML experiment results, compute statistics, generate comparison tables and insights. Use when user says "analyze results", "compare", or needs to interpret experimental data.
- Aanalyze-resultsAnalyze ML experiment results, compute statistics, generate comparison tables and insights. Use when user says \"analyze results\", \"compare\", or needs to interpret experimental data.
- AarxivSearch, download, and summarize academic papers from arXiv. Use when user says "search arxiv", "download paper", "fetch arxiv", "arxiv search", "get paper pdf", or wants to find and save papers from arXiv to the local paper library.
- AarxivSearch, download, and summarize academic papers from arXiv. Use when user says \"search arxiv\", \"download paper\", \"fetch arxiv\", \"arxiv search\", \"get paper pdf\", or wants to find and save papers from arXiv to the local paper library.
- Aauto-paper-improvement-loopAutonomously improve a generated paper via GPT-6-Astra xhigh review → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\", \"论文润色循环\", \"auto improve\", or wants to iteratively polish a generated paper.
- Aauto-paper-improvement-loopAutonomously improve a generated paper via Claude review through claude-review MCP → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\", \"论文润色循环\", \"auto improve\", or wants to iteratively polish a generated paper.
- Aauto-paper-improvement-loopAutonomously improve a generated paper via Gemini review through gemini-review MCP → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\", \"论文润色循环\", \"auto improve\", or wants to iteratively polish a generated paper.
- Aauto-paper-improvement-loopAutonomously improve a generated paper via GPT-6-Astra xhigh review → implement fixes → recompile, for 2 rounds. Use when user says \"改论文\", \"improve paper\", \"论文润色循环\", \"auto improve\", or wants to iteratively polish a generated paper.