Skip to content
cccskills
FreePublished on GitHub

ce-retune

Retune a collection of skills for a new model using archived runs and controlled comparisons. Establish normal measurement variation, register success criteria before editing, and make targeted changes until measured behavior meets the criteria or a specific limitation is reported.

OriginalShow the original description

Retune a skill corpus for a new model, measurement-first: mine the run archive for a baseline, establish a noise floor, audit the corpus adversarially, then cut in measured passes until a pre-registered bar clears. Requires a benchmark harness that can A/B two builds of the corpus; refuses without one.

See how to install

Good for

  • Investigating skill regressions after switching models
  • Measuring the effect of instruction changes
  • Separating behavior improvements from normal run variation
  • Checking a skill collection against predefined success criteria

Files included (8)

  • SKILL.md4.6 KB
  • agents/openai.yaml43 B
  • references/baseline-mining.md10.4 KB
  • references/corpus-audit.md12.5 KB
  • references/cut-passes.md10.7 KB
  • references/halt-taxonomy.md11.0 KB
  • references/noise-floor.md12.9 KB
  • references/workflow-shapes.md11.5 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Retune a Corpus for a New Model

A corpus that degrades on a new model is a measurement problem before it is a writing problem: rewriting what looks wrong produces a plausible fix list and no way to know whether any item mattered.

Outcome: a corpus whose measured behavior on the target model clears a bar registered before any change, with the regression classes removed and each removal attributable.

Done: the bar is cleared, or the run reports the specific claim it could not support. A green test suite is not done: it proves nothing broke, not that behavior improved.

Non-goal: word reduction. Leanness and performance are separate programs that share a corpus; only one of them is the result here. Report completion, not word count.

Phase 0: the measurement gate — check this first

This skill cannot run without a way to observe behavior. Check for all three, and name whichever is missing:

  1. A run archive or a harness that produces one — per-run logs carrying the tool-call trace, a terminal marker, token counts, and the final message.
  2. A build selector — the harness can point a run at a specific source checkout of the corpus (a --plugin-dir-style override, a configurable skills path, an env var), so two builds are comparable under one runner.
  3. A repeatable task the corpus actually executes end to end.

If any is missing, stop and say so, naming what to build. Do not fall back to a static audit and present it as retuning: an audit can say what looks cuttable and never whether cutting helped. An audit-only pass is a legitimate thing to want; it is a different request.

State the target model and the harness you found before continuing.

The phases

They run in order, and each names the reference it cannot start without. Read references/workflow-shapes.md before dispatching any phase: the wrong orchestration shape is the common failure. Fan out by disjoint file ownership, never by item. Items cross files, and agents that share a file lose each other's edits.

Before assessing whether the registered bar is met or interpreting its results, read references/noise-floor.md.

  1. Mine the archive before spending a run — references/baseline-mining.md. Historical runs are a free baseline, usually larger than any experiment affordable now.
  2. Establish the noise floor — references/noise-floor.md. Run the harness against two identical copies of the corpus, same commit on both sides; whatever difference appears is the floor every later claim must clear. Register the bar now, in writing, before any change exists. A bar chosen after seeing results is not a bar.
  3. Audit the corpus adversarially — references/corpus-audit.md. One agent per skill proposes cuts; a second per skill does the opposite and defends the existing prose. The two passes require independent contexts. If the host exposes no way to run them as separate agents, report that as a blocker and stop the audit — do not argue both sides in one context and present the result as an audit.
  4. Cut in surgical passes, one problem per agent — references/cut-passes.md, and references/halt-taxonomy.md when the symptom is stalling, halting, or a run that ends while naming work it did not do. Two rules bound every pass, whatever class it is cutting. Never edit a test to make a suite green: a removed string a test pins is a finding to report, not a test to weaken. And not every stop is the enemy. Some workflows exist to stop and ask; that is the product. Sort every stop by who is actually on the other side before touching it. references/halt-taxonomy.md carries the screens that decide, so read them before cutting any stop.
  5. Measure, then let the failure choose the next fix — references/cut-passes.md again for what each failure site means and for auditing the phases the instrument never enters. Loop 4 and 5 until the registered bar clears. Then stop; a bar cleared is done. Also report what stayed unmeasured: a cleared bar never implies coverage it does not have.
  6. Ship — references/cut-passes.md carries what the commits and the write-up must preserve.

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

ce-babysit-pr

FreeSummary

Monitor an open GitHub pull request over time, respond to review feedback, and address automated check failures. Apply and push fixes, then report whether it appears ready to merge or what still blocks progress.

  • Monitoring a pull request until it appears ready to merge
  • Addressing review feedback as it arrives
  • Handling automated check failures during review
EveryInc/compound-engineering-plugin25.6KUpdated Oct 17, 2026

ce-bakeoff

FreeSummary

Develop independent solutions to a defined problem, compare them against shared requirements, and combine useful contributions into a coherent recommendation. An independent assessment and evidence checks support the selection, while unresolved tradeoffs and verification needs remain explicit.

  • Comparing concrete solutions to a defined problem
  • Developing rough options before choosing an approach
  • Comparing architectural or product proposals
EveryInc/compound-engineering-plugin25.6KUpdated Oct 17, 2026

ce-brainstorm

FreeSummary

Turn a vague feature idea into clear requirements through dialogue. Define what to build, its scope, and success criteria, then capture the result in a short chat summary or a requirements document ready for implementation planning.

  • Clarifying a vague feature idea
  • Narrowing the scope of an ambitious improvement
  • Documenting requirements before implementation planning
EveryInc/compound-engineering-plugin25.6KUpdated Oct 17, 2026

ce-code-review

FreeSummary

Review code changes or a pull request for bugs, effects on existing behavior, test gaps, and project standards. Receive findings supported by the code and a clear account of review coverage, with local fixes available when explicitly requested.

  • Reviewing a pull request before release
  • Checking changes for bugs and test gaps
  • Applying review findings locally
EveryInc/compound-engineering-plugin25.6KUpdated Oct 17, 2026

ce-commit

FreeSummary

Save working changes as local Git commits with messages that explain the outcome. Follow the project's commit style, select files explicitly, and split clearly separate changes into a few logical commits when appropriate.

  • Saving completed work as a local commit
  • Writing messages that explain the outcome
  • Separating unrelated changes into commits
EveryInc/compound-engineering-plugin25.6KUpdated Oct 17, 2026

Commit and push code changes, then open a pull request with a clear title and description. You can also draft or update PR descriptions and hand published requests to the follow-up monitoring workflow.

  • Committing changes and opening a pull request
  • Drafting only a PR title and description
  • Updating an existing PR description
EveryInc/compound-engineering-plugin25.6KUpdated Oct 17, 2026

See all skills by EveryInc

Report a problem with this skill