Skip to content
cccskills
FreePublished on GitHub

meta-apply

Apply staged improvements to skill files after explicit user selection and a fresh review by a different model family. Each applied change includes a backup, review records, and provenance details for later inspection.

OriginalShow the original description

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.

See how to install

Good for

  • Apply selected patches after reviewing an optimization report
  • Require a fresh model review before changing skill files
  • Keep backups and review records for skill updates

Files included (1)

  • SKILL.md7.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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 jury_verdict: 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:

  1. The human named THIS patch. Apply only patches the user listed (/meta-apply 1,3 or all); default to applying nothing.
  2. Fresh cross-model jury PASS, obtained now. Run mcp__codex__codex (fresh thread, NOT codex-reply; model: gpt-6-astra, config: {"model_reasoning_effort": "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.)
  3. Author ≠ reviewer family. The author is the producer's executor model; the reviewer is the codex model that just judged it. Run provenance.py assert_cross_family — if it raises (same family / unknown), refuse. (Here it always holds: producer=Claude, jury=codex. The check is the structural backstop.)

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/ → $ARIS_REPO/tools/ → $ARIS_REPO/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, jury_verdict, jury_thread_id, one_line_reason}. Print a one-line result per patch (PASS → eligible / KILL → refused: <reason>).

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:

  1. Back up the target to .aris/meta/backups/<date>/<target> (use the Write tool to copy contents; corpus paths are not Bash-writable when corpus_write_guard is active — and the applier should use Write/Edit for corpus mutation anyway).
  2. Apply the diff by Edit/Write on the target corpus file.
  3. 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.
  4. Log to .aris/meta/optimizations.jsonl: {ts, patch, target, author_model, reviewer_model, jury_thread_id, applied: true}.

Step 3: Report

Per patch: LANDED <target> (+ backup path + provenance sidecar) or REFUSED <patch>: <reason>. 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):

  • The stamp carries verdict_id (auditable review) + content_hash (a later hand-edit invalidates it).
  • Recommended (not yet built): a TTL forcing re-review of long-lived auto-authored 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.

Key Rules

  • 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 on the staged diff; never trust a producer-written verdict; the human picks among survivors, never resurrects a KILL.
  • Cross-family or refuse. assert_cross_family must not raise. A deterministic:<verifier> reviewer is valid per skill-governance.md.
  • Corpus mutation goes through Write/Edit (reviewable, attributable), not Bash. The corpus_write_guard 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).
  • Back up before every mutation. Reversible by construction.
  • Only land staged patches. Applies what producers staged in .aris/meta/pending/; invents nothing of its own.

Review Tracing

Save each landing-jury codex call's trace per review-tracing.md to .aris/traces/meta-apply/<date>_run<NN>/ — the acquittal that landed a corpus change must be forensically recoverable.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

ablation-planner

FreeSummary

Plan ablation studies, experiments that remove or replace parts of a machine learning method to test their contribution. Define reviewer questions, expected outcomes, priorities, execution order, and compute estimates, then implement experiments and record findings.

  • Testing the contribution of individual method components
  • Planning additional experiments before paper submission
  • Prioritizing experiments within a GPU budget
wanshuiyin/Auto-claude-code-research-in-sleep17.7KUpdated Oct 17, 2026

ablation-planner

FreeSummary

Plan and run ablation studies, experiments that remove or replace parts of a method to test their contribution. Organize reviewer questions, priorities, expected outcomes, and compute costs, then record results and findings.

  • Test how much each component contributes
  • Plan experiments that address reviewer questions
  • Prioritize comparisons within a compute budget
wanshuiyin/Auto-claude-code-research-in-sleep17.7KUpdated Oct 17, 2026

alphaxiv

FreeSummary

Understand a single arXiv paper through an AlphaXiv summary, with full text and LaTeX source available when needed. Use it to identify key findings or ask specific questions about methods, experiments, and equations.

  • Get a quick overview of a paper from its URL
  • Check a paper's methods and experimental results
  • Ask about equations, proofs, or appendix details
wanshuiyin/Auto-claude-code-research-in-sleep17.7KUpdated Oct 17, 2026

analyze-results

FreeSummary

Compare machine learning experiment results from JSON or CSV files. Calculate improvements over a baseline, summarize variation across repeated runs, identify trends and unusual results, and suggest experiments to test possible explanations.

  • Compare model performance across experimental conditions
  • Check variation across runs with different random seeds
  • Identify trends as a parameter changes
wanshuiyin/Auto-claude-code-research-in-sleep17.7KUpdated Oct 17, 2026

arxiv

FreeSummary

Search arXiv papers by topic or paper ID, review authors and abstracts, and summarize contributions stated in the abstracts. Download selected papers or all search results as PDFs to build a local paper library.

  • Find arXiv papers on a research topic
  • Retrieve details for a known arXiv paper ID
  • Download all PDFs from a set of search results
wanshuiyin/Auto-claude-code-research-in-sleep17.7KUpdated Oct 17, 2026

Improve an existing LaTeX paper through two rounds of Gemini review, targeted edits, and PDF rebuilding. Check whether claims match the evidence, resolve notation and presentation issues, and retain review logs and PDF versions.

  • Review and revise a completed paper draft
  • Align claims with supporting evidence
  • Resolve notation and explanation inconsistencies
wanshuiyin/Auto-claude-code-research-in-sleep17.7KUpdated Oct 17, 2026

See all skills by wanshuiyin

Report a problem with this skill