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

evals-specify

Skill145 starsChanged 20 days agoMITView on GitHub

Use when you want guided bottom-up error analysis, structured failure taxonomy discovery, or comprehensive trace coding before documenting eval criteria. Class boots only suggest capture — they never write drafts; running this skill writes the lightweight eval draft.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    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. Distinctive:

    Principle IX: Test Data as Code - Dataset planning and coverage analysis

    line 21
  2. Distinctive:

    Starting evaluation development: No existing criteria, need discovery from failure logs

    line 33
  3. Very specific:

    Known criteria already exist: Use /evals-clarify to refine or /evals-implement to generate code

    line 40
  4. Distinctive:

    Treat user input as specific failure areas or error patterns to analyze (e.g., "authentication bypass", "RAG irrelevant results").

    line 48
  5. Distinctive:

    Document real pass/fail examples directly from traces

    line 63

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

What this skill does

Conducts bottom-up error analysis following EDD Principles III & IX (Error Analysis & Test Data as Code) to discover and document draft evaluation criteria from human observation of system failures.

Output:

  1. Draft Eval Records - Individual EVAL-*.md files in .adlc/drafts/evals/ with open coding notes
  2. Error Pattern Documentation - Bottom-up failure taxonomy from actual traces
  3. Pass/Fail Examples - Real examples that should pass/fail each criterion
  4. Auto-handoff to /evals-clarify for axial coding and clustering

Key EDD Principles Applied:

  • Principle III: Error Analysis & Pattern Discovery - Open coding → failure taxonomy
  • Principle IX: Test Data as Code - Dataset planning and coverage analysis
  • Principle II: Binary Pass/Fail - Maintain strict binary pass/fail conditions
  • Principle V: Trajectory Observability - Track full multi-turn conversation traces

When to use

Note: Class boots detect decisions and suggest this skill — running it is how the capture happens (it writes the lightweight draft to .adlc/drafts/). Use it for interactive deep-dive exploration — when you want guided trade-off analysis, multi-option comparison, or structured decision facilitation before documenting.

  • Starting evaluation development: No existing criteria, need discovery from failure logs
  • Production incident analysis: Recent failures require systematic analysis
  • Quality assessment: Discovering and codifying boundary conditions from failures

When NOT to use

  • No failure traces/specs: Generate synthetic traces first, or use /evals-init to set up security baselines
  • Known criteria already exist: Use /evals-clarify to refine or /evals-implement to generate code

Process

User Input

$ARGUMENTS

Treat user input as specific failure areas or error patterns to analyze (e.g., "authentication bypass", "RAG irrelevant results").

  • --traces N — Number of traces to analyze (default: 20, min for theoretical saturation)
  • --source SOURCE — Trace source location (e.g., logs, support tickets)

Execution Steps

Phase 1: Open Coding Analysis

  • Reviews the user-provided failure logs or spec requirements.
  • Conducts open coding of traces to discover recurring failure patterns (EDD Principle III).
  • Identifies: core problem, causal conditions, and consequences.

Phase 2: Create Draft Criteria

Group patterns into draft criteria. For each:

  • Define strict Pass Condition (observable, binary yes/no)
  • Define strict Fail Condition (observable, binary yes/no)
  • Document real pass/fail examples directly from traces

Phase 3: Create Draft Files

  • Copy skills/evals/evals-templates/eval-criterion-template.md to .adlc/drafts/evals/EVAL-{NNN}.md.
  • Populate metadata and error analysis notes.
  • Regenerate index at .adlc/drafts/evals/evals.md.

Phase 4: Auto-Handoff

Trigger /evals-clarify for axial coding and clustering.

Verification

  • Draft files created at .adlc/drafts/evals/EVAL-*.md
  • Index file .adlc/drafts/evals/evals.md updated with draft summaries
  • Each draft contains: status "draft", pass/fail conditions, trace sources, and concrete examples
  • Auto-handoff context produced with list of created drafts

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.