advanced-evaluation
Skill2 starsChanged 42 days agoMITView on GitHub
This skill should be used when the user asks to "implement LLM-as-judge", "compare model outputs", "create evaluation rubrics", "mitigate evaluation bias", or mentions direct scoring, pairwise comparison, position bias, evaluation pipelines, or automated quality assessment.
10 other projects use a version of this, 9 of them edited.
Adopted by
Most recently taken up by
- docxology/templateedited, first seen Oct 30, 2026
- AbdelrhmanAlquran/claude-skillsedited, first seen Oct 20, 2026
- xfstudio/skillsedited, first seen Oct 13, 2026
- brake71/1c-ssl-skillsedited, first seen Oct 13, 2026
- nek1987/auto-agent-harnessedited, first seen Oct 11, 2026
- muratcankoylan/Agent-Skills-for-Context-Engineeringedited, first seen Aug 10, 2026
Used with
Projects with it also use bdi-mental-states, hosted-agents and 6 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
Downey6689Skillbdi-mental-states
Transforms external RDF context into BDI mental states. Invoke when modeling beliefs, desires, and intentions.
Also in 5 projects that use this
Downey6689Skillhosted-agents
Guidance for hosted/sandboxed agents. Invoke when running background agents in isolated VMs or multi-client setups.
Also in 5 projects that use this
DVwebBiz11Skillself-improvement-loops
This skill should be used when the harness, scaffold, workflow, or optimizer itself is the optimization target: recursive self-improvement (RSI) loops, meta-harnesses, self-improving harnesses that mine their own failures and propose bounded edits, evolutionary or population-based search over agent scaffolds, acceptance gates for self-modifying systems, and agentic context evolution where the mechanism that produces context is versioned and evolved. Route governance of a single autonomous loop (locked surfaces, durable logs, rollback, novelty gates, approval boundaries) to harness-engineering, measurement and quality-gate design to evaluation, judge design to advanced-evaluation, and remote sandbox infrastructure to hosted-agents.
Also in 4 projects that use this
DVwebBiz11Skilllong-horizon-prompting
This skill should be used when writing, enhancing, or evaluating the launch prompt for a long-running autonomous agent or a parallel multi-agent orchestration attacking a hard problem: pseudo-formal task briefs that define terms and an exact success predicate linguistically, enumerate non-counting outcomes, set persistence rules with explicit stop and return conditions and effort floors, manage a diverse portfolio of parallel approaches with an approach registry and blocked-route bookkeeping, and gate the return on adversarial audit. Route agent topology and coordination protocols to multi-agent-patterns, runtime control surfaces and loop governance to harness-engineering, evaluator and quality-gate construction to evaluation, judge design to advanced-evaluation, and compaction or memory mechanics to context-compression and memory-systems.
Also in 4 projects that use this
AbdelrhmanAlquranSkilllatent-briefing
This skill should be used when the user asks to "share memory between agents", "KV cache compaction for multi-agent", "orchestrator worker context", "latent briefing", "reduce worker tokens", "cross-agent memory without summarization", or discusses Attention Matching compaction, recursive language models with workers, or token explosion in hierarchical agents.
Also in 4 projects that use this
GitHubSkillharness-engineering
Adopt repository-level harness engineering for coding agents. Use when a user wants to prevent repeated AI coding-agent mistakes by turning failures into durable instructions, drift checks, regression tests, failure memory, and adoption reports tailored to the target repository.
Also in 4 projects that use this
- +2 more from Downey6689
Other versions10 projects use a version of this.
Word for word · 0
None found.
Edited · 9
- muratcankoylan/Agent-Skills-for-Context-Engineering★ 18k53% same
- brake71/1c-ssl-skills★ 8553% same
- docxology/template★ 2353% same
- xfstudio/skills★ 999% same
- rohunvora/my-claude-skills★ 697% same
- nek1987/auto-agent-harness★ 499% same
- corticalstack/flow★ 162% same
- AbdelrhmanAlquran/claude-skills★ 053% same
- DVwebBiz11/claude-skills★ 053% same
Wrote their own version · 1
- Downey6689/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository191 other files it gives its agents.
- AGENTS.mdAGENTS.md
- docs/agents.mdAGENTS.md
- skills/postgres-best-practices/AGENTS.mdAGENTS.md
- skills/react-best-practices/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- accessibility-compliance-accessibility-auditSkill
- acquire-codebase-knowledgeSkill
- agent-evaluationSkill
- alexSkill
- ariaSkill
- depSkill
- lunaSkill
- masonSkill
- maxSkill
- quinnSkill
- rexSkill
- agent-squadSkill
- ai-agent-developmentSkill
- ai-agents-architectSkill
- ai-engineering-toolkitSkill
- api-and-interface-designSkill
- api-design-principlesSkill
- api-documentation-generatorSkill
- api-documentationSkill
- api-documenterSkill
- api-endpoint-builderSkill
- api-fuzzing-bug-bountySkill
- api-patternsSkill
- api-security-testingSkill
- api-testing-observability-api-mockSkill
- application-performance-performance-optimizationSkill
- architecture-decision-recordsSkill
- architecture-patternsSkill
- async-python-patternsSkill
- attack-tree-constructionSkill
- autonomous-agent-patternsSkill
- aws-cost-optimizerSkill
- aws-serverlessSkill
- awt-e2e-testingSkill
- azure-functionsSkill
- backend-architectSkill
- backend-dev-guidelinesSkill
- backend-security-coderSkill
- brainstormingSkill
- breakdown-feature-implementationSkill
- breakdown-feature-prdSkill
- broken-authenticationSkill
- browser-testing-with-devtoolsSkill
- ci-cd-and-automationSkill
- clean-codeSkill
- cloud-architectSkill
- cloud-devopsSkill
- cloudformation-best-practicesSkill
- code-refactoring-refactor-cleanSkill
- code-refactoring-tech-debtSkill
- code-review-and-qualitySkill
- code-simplificationSkill
- comprehensive-review-full-reviewSkill
- comprehensive-review-pr-enhanceSkill
- container-security-hardeningSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
8 rules. 2 are common, 6 are distinctive, and 0 are very specific to this project.
2
Common
Most of the 9 edited versions we read keep these.
6
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 113
Chain-of-Thought Requirement: All scoring prompts must require justification before the score.
- Distinctive: line 241
Use this decision tree:
- Distinctive: line 260
Panel of LLMs (PoLL): Use multiple models as judges, aggregate votes
- Common: line 402
Match scale granularity to rubric specificity: - Don't use 1-10 without detailed level descriptions
- Common: line 404
Separate objective and subjective criteria: - Use direct scoring for objective, pairwise for subjective
- Distinctive: line 455
Use this skill only when the task clearly matches the scope described above.
- Distinctive: line 456
Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Distinctive: line 457
Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Advanced Evaluation
This skill covers production-grade techniques for evaluating LLM outputs using LLMs as judges. It synthesizes research from academic papers, industry practices, and practical implementation experience into actionable patterns for building reliable evaluation systems.
Key insight: LLM-as-a-Judge is not a single technique but a family of approaches, each suited to different evaluation contexts. Choosing the right approach and mitigating known biases is the core competency this skill develops.
When to Use
Activate this skill when:
- Building automated evaluation pipelines for LLM outputs
- Comparing multiple model responses to select the best one
- Establishing consistent quality standards across evaluation teams
- Debugging evaluation systems that show inconsistent results
- Designing A/B tests for prompt or model changes
- Creating rubrics for human or automated evaluation
- Analyzing correlation between automated and human judgments
Core Concepts
The Evaluation Taxonomy
Evaluation approaches fall into two primary categories with distinct reliability profiles:
Direct Scoring: A single LLM rates one response on a defined scale.
- Best for: Objective criteria (factual accuracy, instruction following, toxicity)
- Reliability: Moderate to high for well-defined criteria
- Failure mode: Score calibration drift, inconsistent scale interpretation
Pairwise Comparison: An LLM compares two responses and selects the better one.
- Best for: Subjective preferences (tone, style, persuasiveness)
- Reliability: Higher than direct scoring for preferences
- Failure mode: Position bias, length bias
Research from the MT-Bench paper (Zheng et al., 2023) establishes that pairwise comparison achieves higher agreement with human judges than direct scoring for preference-based evaluation, while direct scoring remains appropriate for objective criteria with clear ground truth.
The Bias Landscape
LLM judges exhibit systematic biases that must be actively mitigated:
Position Bias: First-position responses receive preferential treatment in pairwise comparison. Mitigation: Evaluate twice with swapped positions, use majority vote or consistency check.
Length Bias: Longer responses are rated higher regardless of quality. Mitigation: Explicit prompting to ignore length, length-normalized scoring.
Self-Enhancement Bias: Models rate their own outputs higher. Mitigation: Use different models for generation and evaluation, or acknowledge limitation.
Verbosity Bias: Detailed explanations receive higher scores even when unnecessary. Mitigation: Criteria-specific rubrics that penalize irrelevant detail.
Authority Bias: Confident, authoritative tone rated higher regardless of accuracy. Mitigation: Require evidence citation, fact-checking layer.
Metric Selection Framework
Choose metrics based on the evaluation task structure:
| Task Type | Primary Metrics | Secondary Metrics |
| Binary classification (pass/fail) | Recall, Precision, F1 | Cohen's κ |
| Ordinal scale (1-5 rating) | Spearman's ρ, Kendall's τ | Cohen's κ (weighted) |
| Pairwise preference | Agreement rate, Position consistency | Confidence calibration |
| Multi-label | Macro-F1, Micro-F1 | Per-label precision/recall |
The critical insight: High absolute agreement matters less than systematic disagreement patterns. A judge that consistently disagrees with humans on specific criteria is more problematic than one with random noise.
Evaluation Approaches
Direct Scoring Implementation
Direct scoring requires three components: clear criteria, a calibrated scale, and structured output format.
Criteria Definition Pattern:
Criterion: [Name]
Description: [What this criterion measures]
Weight: [Relative importance, 0-1]Scale Calibration:
- 1-3 scales: Binary with neutral option, lowest cognitive load
- 1-5 scales: Standard Likert, good balance of granularity and reliability
- 1-10 scales: High granularity but harder to calibrate, use only with detailed rubrics
Prompt Structure for Direct Scoring:
You are an expert evaluator assessing response quality.
## Task
Evaluate the following response against each criterion.
## Original Prompt
{prompt}
## Response to Evaluate
{response}
## Criteria
{for each criterion: name, description, weight}
## Instructions
For each criterion:
1. Find specific evidence in the response
2. Score according to the rubric (1-{max} scale)
3. Justify your score with evidence
4. Suggest one specific improvement
## Output Format
Respond with structured JSON containing scores, justifications, and summary.Chain-of-Thought Requirement: All scoring prompts must require justification before the score. Research shows this improves reliability by 15-25% compared to score-first approaches.
Pairwise Comparison Implementation
Pairwise comparison is inherently more reliable for preference-based evaluation but requires bias mitigation.
Position Bias Mitigation Protocol:
- First pass: Response A in first position, Response B in second
- Second pass: Response B in first position, Response A in second
- Consistency check: If passes disagree, return TIE with reduced confidence
- Final verdict: Consistent winner with averaged confidence
Prompt Structure for Pairwise Comparison:
You are an expert evaluator comparing two AI responses.
## Critical Instructions
- Do NOT prefer responses because they are longer
- Do NOT prefer responses based on position (first vs second)
- Focus ONLY on quality according to the specified criteria
- Ties are acceptable when responses are genuinely equivalent
## Original Prompt
{prompt}
## Response A
{response_a}
## Response B
{response_b}
## Comparison Criteria
{criteria list}
## Instructions
1. Analyze each response independently first
2. Compare them on each criterion
3. Determine overall winner with confidence level
## Output Format
JSON with per-criterion comparison, overall winner, confidence (0-1), and reasoning.Confidence Calibration: Confidence scores should reflect position consistency:
- Both passes agree: confidence = average of individual confidences
- Passes disagree: confidence = 0.5, verdict = TIE
Rubric Generation
Well-defined rubrics reduce evaluation variance by 40-60% compared to open-ended scoring.
Rubric Components:
- Level descriptions: Clear boundaries for each score level
- Characteristics: Observable features that define each level
- Examples: Representative text for each level (optional but valuable)
- Edge cases: Guidance for ambiguous situations
- Scoring guidelines: General principles for consistent application
Strictness Calibration:
- Lenient: Lower bar for passing scores, appropriate for encouraging iteration
- Balanced: Fair, typical expectations for production use
- Strict: High standards, appropriate for safety-critical or high-stakes evaluation
Domain Adaptation: Rubrics should use domain-specific terminology. A "code readability" rubric mentions variables, functions, and comments. A "medical accuracy" rubric references clinical terminology and evidence standards.
Practical Guidance
Evaluation Pipeline Design
Production evaluation systems require multiple layers:
┌─────────────────────────────────────────────────┐
│ Evaluation Pipeline │
├─────────────────────────────────────────────────┤
│ │
│ Input: Response + Prompt + Context │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Criteria Loader │ ◄── Rubrics, weights │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Primary Scorer │ ◄── Direct or Pairwise │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Bias Mitigation │ ◄── Position swap, etc. │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ Confidence Scoring │ ◄── Calibration │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ Output: Scores + Justifications + Confidence │
│ │
└─────────────────────────────────────────────────┘Common Anti-Patterns
Anti-pattern: Scoring without justification
- Problem: Scores lack grounding, difficult to debug or improve
- Solution: Always require evidence-based justification before score
Anti-pattern: Single-pass pairwise comparison
- Problem: Position bias corrupts results
- Solution: Always swap positions and check consistency
Anti-pattern: Overloaded criteria
- Problem: Criteria measuring multiple things are unreliable
- Solution: One criterion = one measurable aspect
Anti-pattern: Missing edge case guidance
- Problem: Evaluators handle ambiguous cases inconsistently
- Solution: Include edge cases in rubrics with explicit guidance
Anti-pattern: Ignoring confidence calibration
- Problem: High-confidence wrong judgments are worse than low-confidence
- Solution: Calibrate confidence to position consistency and evidence strength
Decision Framework: Direct vs. Pairwise
Use this decision tree:
Is there an objective ground truth?
├── Yes → Direct Scoring
│ └── Examples: factual accuracy, instruction following, format compliance
│
└── No → Is it a preference or quality judgment?
├── Yes → Pairwise Comparison
│ └── Examples: tone, style, persuasiveness, creativity
│
└── No → Consider reference-based evaluation
└── Examples: summarization (compare to source), translation (compare to reference)Scaling Evaluation
For high-volume evaluation:
- Panel of LLMs (PoLL): Use multiple models as judges, aggregate votes
- Reduces individual model bias
- More expensive but more reliable for high-stakes decisions
- Hierarchical evaluation: Fast cheap model for screening, expensive model for edge cases
- Cost-effective for large volumes
- Requires calibration of screening threshold
- Human-in-the-loop: Automated evaluation for clear cases, human review for low-confidence
- Best reliability for critical applications
- Design feedback loop to improve automated evaluation
Examples
Example 1: Direct Scoring for Accuracy
Input:
Prompt: "What causes seasons on Earth?"
Response: "Seasons are caused by Earth's tilted axis. As Earth orbits the Sun,
different hemispheres receive more direct sunlight at different times of year."
Criterion: Factual Accuracy (weight: 1.0)
Scale: 1-5Output:
{
"criterion": "Factual Accuracy",
"score": 5,
"evidence": [
"Correctly identifies axial tilt as primary cause",
"Correctly explains differential sunlight by hemisphere",
"No factual errors present"
],
"justification": "Response accurately explains the cause of seasons with correct
scientific reasoning. Both the axial tilt and its effect on sunlight distribution
are correctly described.",
"improvement": "Could add the specific tilt angle (23.5°) for completeness."
}Example 2: Pairwise Comparison with Position Swap
Input:
Prompt: "Explain machine learning to a beginner"
Response A: [Technical explanation with jargon]
Response B: [Simple analogy-based explanation]
Criteria: ["clarity", "accessibility"]First Pass (A first):
{ "winner": "B", "confidence": 0.8 }Second Pass (B first):
{ "winner": "A", "confidence": 0.6 }(Note: Winner is A because B was in first position)
Mapped Second Pass:
{ "winner": "B", "confidence": 0.6 }Final Result:
{
"winner": "B",
"confidence": 0.7,
"positionConsistency": {
"consistent": true,
"firstPassWinner": "B",
"secondPassWinner": "B"
}
}Example 3: Rubric Generation
Input:
criterionName: "Code Readability"
criterionDescription: "How easy the code is to understand and maintain"
domain: "software engineering"
scale: "1-5"
strictness: "balanced"Output (abbreviated):
{
"levels": [
{
"score": 1,
"label": "Poor",
"description": "Code is difficult to understand without significant effort",
"characteristics": [
"No meaningful variable or function names",
"No comments or documentation",
"Deeply nested or convoluted logic"
]
},
{
"score": 3,
"label": "Adequate",
"description": "Code is understandable with some effort",
"characteristics": [
"Most variables have meaningful names",
"Basic comments present for complex sections",
"Logic is followable but could be cleaner"
]
},
{
"score": 5,
"label": "Excellent",
"description": "Code is immediately clear and maintainable",
"characteristics": [
"All names are descriptive and consistent",
"Comprehensive documentation",
"Clean, modular structure"
]
}
],
"edgeCases": [
{
"situation": "Code is well-structured but uses domain-specific abbreviations",
"guidance": "Score based on readability for domain experts, not general audience"
}
]
}Guidelines
- Always require justification before scores - Chain-of-thought prompting improves reliability by 15-25%
- Always swap positions in pairwise comparison - Single-pass comparison is corrupted by position bias
- Match scale granularity to rubric specificity - Don't use 1-10 without detailed level descriptions
- Separate objective and subjective criteria - Use direct scoring for objective, pairwise for subjective
- Include confidence scores - Calibrate to position consistency and evidence strength
- Define edge cases explicitly - Ambiguous situations cause the most evaluation variance
- Use domain-specific rubrics - Generic rubrics produce generic (less useful) evaluations
- Validate against human judgments - Automated evaluation is only valuable if it correlates with human assessment
- Monitor for systematic bias - Track disagreement patterns by criterion, response type, model
- Design for iteration - Evaluation systems improve with feedback loops
Integration
This skill integrates with:
- context-fundamentals - Evaluation prompts require effective context structure
- tool-design - Evaluation tools need proper schemas and error handling
- context-optimization - Evaluation prompts can be optimized for token efficiency
- evaluation (foundational) - This skill extends the foundational evaluation concepts
References
Internal reference:
- LLM-as-Judge Implementation Patterns
- Bias Mitigation Techniques
- Metric Selection Guide
External research:
- Eugene Yan: Evaluating the Effectiveness of LLM-Evaluators
- Judging LLM-as-a-Judge (Zheng et al., 2023)
- G-Eval: NLG Evaluation using GPT-4 (Liu et al., 2023)
- Large Language Models are not Fair Evaluators (Wang et al., 2023)
Related skills in this collection:
- evaluation - Foundational evaluation concepts
- context-fundamentals - Context structure for evaluation prompts
- tool-design - Building evaluation tools
Skill Metadata
Created: 2024-12-24 Last Updated: 2024-12-24 Author: Muratcan Koylan Version: 1.0.0
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
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.

