agentleFS
epicsagasepicsagas/epic-harness/skills/_critic/SKILL.md

_critic

Skill20 starsChanged 2 months agoApache-2.0View on GitHub

HarnessX Critic (Tier 2.1) — adversarial review of evolved-skill proposals against trace evidence. Detects reward hacking and manifest/evidence contradictions. Out-of-band LLM counterpart to the in-loop deterministic critic in src/evolve/critic.rs.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 9 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When reward_hacking_suspected is true in metrics

    line 17
  2. Distinctive:

    After a seesaw-regression round, before re-proposing

    line 18
  3. Distinctive:

    Read the evolved skill proposal(s) from this round

    line 23
  4. Distinctive:

    Read the EditManifest (edit_type, target, intended_effect, predicted_impact)

    line 24
  5. Distinctive:

    Read the round's TaskDigests (outcome, failure_categories, evidence_excerpts)

    line 25
  6. Distinctive:

    Read recent score_history dimension_averages (tool_success, output_quality, execution_cost)

    line 26
  7. Distinctive:

    If the manifest claims "Lift avg_score_with" but output_quality is regressing → Reject

    line 30
  8. Distinctive:

    If the manifest claims a tool fix but the implicated component shows no change → Warn

    line 31
  9. Distinctive:

    If the evidence corroborates the predicted effect → Approve

    line 32
  10. Distinctive:

    If yes, the skill must NOT ship — flag for the rejected buffer.

    line 37

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Critic — Adversarial Proposal Review

In-loop vs out-of-band. epic-harness forbids external LLM calls from production, so the reflect loop ships a deterministic critic (src/evolve/critic.rs) that gates seeding when reward hacking is suspected. THIS skill is the out-of-band LLM version a meta-agent or human runs during /evolve review for the cases the deterministic check cannot catch (non-local effects, manifest/evidence nuance).

When to Trigger

  • During /evolve review of newly seeded skills
  • When reward_hacking_suspected is true in metrics
  • After a seesaw-regression round, before re-proposing

Process

1. Gather the proposal + evidence

  • Read the evolved skill proposal(s) from this round
  • Read the EditManifest (edit_type, target, intended_effect, predicted_impact)
  • Read the round's TaskDigests (outcome, failure_categories, evidence_excerpts)
  • Read recent score_history dimension_averages (tool_success, output_quality, execution_cost)

2. Falsify the manifest (paper §4.3, Table 9)

For each proposal, ask: does the trace evidence support the predicted_impact?

  • If the manifest claims "Lift avg_score_with" but output_quality is regressing → Reject
  • If the manifest claims a tool fix but the implicated component shows no change → Warn
  • If the evidence corroborates the predicted effect → Approve

3. Reward-hacking cross-check

  • Is execution_cost rising while output_quality falls across the window?
  • Could the skill be gaming a metric (fewer tool calls inflating cost score) rather than improving outcomes?
  • If yes, the skill must NOT ship — flag for the rejected buffer.

4. Non-local effect scan

  • Will this skill's guard rules conflict with existing skills (overlapping triggers, contradictory rules)?
  • Does it interact with shared state (context, memory, control) in a way the manifest didn't account for?

Anti-Rationalization

ExcuseRebuttalDo instead
"The score went up, so it works"Score can rise via metric gamingVerify the outcome improved, not just the score
"The seesaw passed, it's safe"Seesaw is coarse; sub-threshold coupling evades itCheck dimension deltas, not just aggregate pass
"It's just a prompt tweak"Prompt edits have non-local effects on shared contextTrace the effect across skills, not just the target

Evidence Required

  • Manifest's predicted_impact checked against observed dimension deltas
  • reward_hacking_suspected consulted
  • No conflict with ≥1 existing skill demonstrated
  • Verdict (Approve/Warn/Reject) recorded per proposal with reason

Red Flags

  • Approving a skill whose only evidence is "score went up"
  • Ignoring a falling output_quality because execution_cost rose
  • Shipping after a seesaw-regression round without explicit justification
  • Treating the deterministic critic as sufficient for non-local effects (it is not — it only checks reward hacking + score-claim contradiction)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.