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.
In this repository48 other files it gives its agents.
- architect-analyzeSkill
- architect-bootSkill
- architect-clarifySkill
- architect-implementSkill
- architect-initSkill
- architect-specifySkill
- writing-skillsSkill
- change-bootSkill
- change-clarifySkill
- change-initSkill
- change-publishSkill
- change-specifySkill
- evals-analyzeSkill
- evals-clarifySkill
- evals-implementSkill
- evals-initSkill
- evals-validateSkill
- factory-cleanSkill
- factory-initSkill
- factory-intentSkill
- factory-learnSkill
- factory-missionSkill
- factory-orchestratorSkill
- factory-queueSkill
- factory-releaseSkill
- factory-reviewSkill
- factory-runbookSkill
- factory-setupSkill
- factory-ticketsSkill
- mission-briefSkill
- product-analyzeSkill
- product-bootSkill
- product-clarifySkill
- product-implementSkill
- product-initSkill
- product-roadmapSkill
- product-specifySkill
- team-bootSkill
- team-constitutionSkill
- team-diagnoseSkill
- team-discoverSkill
- team-initSkill
- team-levelupSkill
- team-repairSkill
- team-setupSkill
- team-skillsSkill
- workspaceSkill
- tech-radar-bootSkill
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
- Distinctive: line 21
Principle IX: Test Data as Code - Dataset planning and coverage analysis
- Distinctive: line 33
Starting evaluation development: No existing criteria, need discovery from failure logs
- Very specific: line 40
Known criteria already exist: Use /evals-clarify to refine or /evals-implement to generate code
- Distinctive: line 48
Treat user input as specific failure areas or error patterns to analyze (e.g., "authentication bypass", "RAG irrelevant results").
- Distinctive: line 63
Document real pass/fail examples directly from traces
≈ “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.
Files
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:
- Draft Eval Records - Individual
EVAL-*.mdfiles in.adlc/drafts/evals/with open coding notes - Error Pattern Documentation - Bottom-up failure taxonomy from actual traces
- Pass/Fail Examples - Real examples that should pass/fail each criterion
- Auto-handoff to
/evals-clarifyfor 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-initto set up security baselines - Known criteria already exist: Use
/evals-clarifyto refine or/evals-implementto generate code
Process
User Input
$ARGUMENTSTreat 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.mdto.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.mdupdated 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
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
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.

