agentleFS
tikalktikalk/adlc-team-skills/skills/evals/evals-clarify/SKILL.md

evals-clarify

Skill145 starsChanged 20 days agoMITView on GitHub

Use when draft eval criteria need refining, clustering, and acceptance into the published goldset with an isolated holdout split (goldset.md + goldset.json).

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 5 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Principle IX: Test Data as Code - Adversarial generation, holdout splits, version control

    line 23
  2. Very specific:

    No draft criteria exist: Run /evals-specify to discover patterns first

    line 35
  3. Very specific:

    Grader generation: Use /evals-implement to convert accepted goldset into code

    line 36
  4. Very specific:

    Check if the draft being reviewed uses the lightweight draft template (indicated by presence of type, evidence, source, revisit-when fields …

    line 53
  5. Distinctive:

    Read the draft's captured fields (Context, Decision, Rejected Alternatives, Reason)

    line 59
  6. Distinctive:

    If already full format, proceed with normal review.

    line 69
  7. Distinctive:

    Ensure holdout set is never used in implementation or training.

    line 82
  8. Distinctive:

    All criteria are strictly binary (no confidence scores or Likert scales)

    line 95

≈ “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

evals-clarify

What this skill does

Conducts axial coding following EDD Principles III & IX to cluster related failure patterns, refine evaluation criteria, generate adversarial examples, and accept validated drafts into the published goldset.

Output:

  1. Clustered Criteria - Related patterns grouped into coherent evaluation themes
  2. Adversarial Examples - Generated attack scenarios and edge cases for robustness
  3. Published Goldset - Accepted criteria in evals/{system}/goldset.md with full documentation
  4. Holdout Dataset - Reserved test set (20%) for unbiased evaluation validation
  5. JSON Configuration - Auto-generated goldset.json for system consumption
  6. Auto-handoff to /evals-implement for grader generation

Key EDD Principles Applied:

  • Principle III: Error Analysis & Pattern Discovery - Axial coding → theoretical relationships
  • Principle IX: Test Data as Code - Adversarial generation, holdout splits, version control
  • Principle II: Binary Pass/Fail - Maintain strict binary evaluation throughout
  • Principle I: Spec-Driven Contracts - Criteria validate spec compliance

When to use

  • After /evals-specify: Refine and accept draft criteria into goldset
  • Dataset maintenance: Balance pass/fail examples or add adversarial cases
  • Adding holdout split: Isolate validation data from training data

When NOT to use

  • No draft criteria exist: Run /evals-specify to discover patterns first
  • Grader generation: Use /evals-implement to convert accepted goldset into code

Process

User Input

$ARGUMENTS
  • --accept IDS — Accept specific draft IDs (e.g., "EVAL-001,EVAL-003")
  • --merge IDS — Merge related criteria (e.g., "EVAL-001+EVAL-002")
  • --split ID — Split complex criterion into multiple focused criteria
  • --holdout-ratio RATIO — Holdout percentage (default: 0.2, range: 0.1-0.3)

Execution Steps

Step 0: Detect Lightweight Draft Format

Check if the draft being reviewed uses the lightweight draft template (indicated by presence of type, evidence, source, revisit-when fields in frontmatter and ## Rejected Alternatives / ## Reason body sections without the full formal template sections).

If lightweight:

  1. Read the draft's captured fields (Context, Decision, Rejected Alternatives, Reason)
  2. Transform to full formal template:
    • ADR: full MADR format with Decision Drivers, Considered Options, Pros/Cons, Constitution Alignment, Related ADRs
    • PDR: full PDR format with Market Forces, Consequences, Alternatives Considered, Links
    • ChDR: full ChDR format with Issue Links, Commits, Consequences, Evidence
    • CDR: full CDR format with Context Type, Target Module, Descriptor, Evidence
    • EVAL: full eval format with Error Analysis, Pass/Fail Examples, Implementation Notes
  3. Enrich from session context (add details the lightweight draft may have omitted)
  4. Present the enriched draft for review

If already full format, proceed with normal review.

Phase 1: Axial Coding & Clustering

  • Group related draft patterns into coherent themes.
  • Resolve any overlaps or duplicate criteria.

Phase 2: Refinement & Adversarial Generation

  • Generate 3-5 adversarial (attack) examples per criterion to test robustness.
  • Balance pass/fail examples (~50/50 ratio).
  • Write every clarification point and criterion revision in Simplified Technical English (short sentences, one idea each, active voice, imperative asks, named referents, plain words). Read the contract at skills/authoring/references/ste-rules.md before drafting. Count crossed boundaries (record, lane, team, now): 0–1 boundaries use plain STE prose, however severe the gap; 2 or more boundaries draw the full ASCII decision map from the reference (WHAT/WHY, crossed boundaries, reach fan-out, candidates × discriminating axes, IF-UNDECIDED). Render unknown gaps as ? slots, never prose complaints.

Phase 3: Holdout Isolation

  • Isolate exactly 20% of examples as a reserved holdout set (saved to .adlc/memory/evals/holdout.json — machine data stays under .adlc/ per the shared layout).
  • Ensure holdout set is never used in implementation or training.

Phase 4: Publish Goldset

  • Copy accepted drafts to docs/adlc/memory/evals/ (the shared layout memory root; holdout.json alone stays at .adlc/memory/evals/holdout.json) and update status to accepted.
  • Compile published goldset to evals/{system}/goldset.md (human-readable) and evals/{system}/goldset.json (machine-readable).

Phase 5: Auto-Handoff

Trigger /evals-implement to generate code.

Verification

  • Accepted drafts stored in docs/adlc/memory/evals/EVAL-*.md
  • evals/{system}/goldset.md and goldset.json exist
  • Holdout set .adlc/memory/evals/holdout.json isolated and populated
  • All criteria are strictly binary (no confidence scores or Likert scales)
  • Handover summary lists accepted criteria and adversarial counts

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.