MCP.Market

eval-integrity skill

by code-yeongyu·code-yeongyu/oh-my-openagent·71k stars

Assess integrity of an eval, benchmark, metric, A/B test, holdout, LLM-judge, or user-study claim when the question is whether measurement, comparison, or evidence is independent and trustworthy.

A100/100content scan

Is the eval-integrity skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-11-03.

No findings.

Install the eval-integrity skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/code-yeongyu/oh-my-openagent.git /tmp/oh-my-openagent
mkdir -p ~/.claude/skills
cp -r /tmp/oh-my-openagent/packages/shared-skills/skills/eval-integrity ~/.claude/skills/eval-integrity
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

Evaluation Integrity

Provide a read-only audit of whether an evaluation can support its stated claim. Do not alter code, data, prompts, labels, or study operations. Begin with exactly one verdict line in the form Verdict: PASS, Verdict: FAIL, or Verdict: INCONCLUSIVE. Emit no other verdict line and do not restate the verdict later in the report. A favorable score is not itself evidence of integrity.

Route correctly

review-work.

  • NOT for code review: route implementation, correctness, security, or maintainability review to

data-scientist.

  • NOT for data processing: route cleaning, transforming, joining, modeling, or analyzing data to

result from it.

  • Use this skill for the independence and validity of the measurement setup, not for producing a

Audit method

1. State the claim and map the evaluation

Write the claim in testable form: what comparison, metric, threshold, or causal statement is being made; for which population; and under which decision rule. Map every role before judging it:

Trace shared ownership, shared data, shared prompts, shared labels, and shared selection decisions across this map. Several models do not establish independence merely because there are several of them; identify distinct training, tuning, prompt design, labels, data, and decision authority.

2. Check the ground truth

Identify the independent ground truth that could confirm the claim without reusing the system's own preferences, outputs, labels, or optimization target. Test whether it is:

  • external to the system under test and its designer;
  • collected or adjudicated without seeing the treatment identity when blinding is feasible;
  • appropriate to the claim rather than a proxy selected because it favors one arm; and
  • fixed before comparison, or accompanied by a disclosed multiplicity and selection procedure.

If no independent ground truth exists, do not substitute agreement among related systems. Mark the claim INCONCLUSIVE unless the stated claim is explicitly limited to that related system's score.

3. Probe independence failures

Check only risks relevant to the mapped design:

retrieval, tuning, or post-hoc selection.

  • Contamination: benchmark items, answers, or near duplicates reached training, prompt design,

unequal, or the control cannot answer the causal comparison.

  • Invalid controls: arms differ beyond the intended treatment, allocation is biased, exposure is

success without external confirmation.

  • Circular judging: the evaluated system, its designer, or a derived rubric defines its own

scorer in a way that makes agreement self-fulfilling.

  • Scorer-label coupling: labels, thresholds, reward signals, or rubric choices are reused by the

tuned, or influenced by the comparison designer without an independent safeguard.

  • Evaluator-designer coupling: the evaluator, judge prompt, or adjudication process is selected,

annotators, or correlated annotation policies invalidate assumed independence.

  • Split or annotator dependence: overlapping sources, duplicates, temporal leakage, shared

evaluators or analysts toward the expected outcome.

  • Hypothesis priming: task framing, examples, pre-registration gaps, or interim results steer

behavior or ratings change because of that knowledge.

  • Observer and demand effects: subjects or observers infer the desired treatment or outcome, and

For each concern, distinguish documented evidence from an assumption. Missing provenance for data, splits, labels, prompts, evaluator selection, or scoring is INCONCLUSIVE, not evidence that the design was independent.

4. Reach the verdict

material unresolved dependency.

  • PASS: evidence supports an independent, valid measurement path for the stated claim, with no

the stated claim.

  • FAIL: evidence shows a dependency or invalid design that materially invalidates or overstates

established, or remaining uncertainty prevents either result.

  • INCONCLUSIVE: provenance or evidence is missing, the ground truth is not independently

Do not convert uncertainty into PASS because a metric looks plausible, a result is statistically significant, or multiple related evaluators agree.

Report

Report the verdict first. Then report only findings that fired; do not pad the report with risks that were checked and did not fire. For each fired finding include:

adjudication, or control change that would address it.

  1. Evidence: the observed artifact, provenance record, or explicit absence of one.
  2. Impact: which claim or inference the issue weakens or invalidates.
  3. Minimal independence fix: the smallest separation, blind, held-out source, external
  1. Missing evidence: what must be supplied to resolve the finding, if applicable.
  2. Residual risk: what remains uncertain after the minimal fix.

Keep conclusions bounded to the evidence. This audit advises; it does not certify a system, recompute results, or approve deployment.

More skills from code-yeongyu/oh-my-openagent

  • Aast-grepSearches and rewrites code by AST shape across 25 languages. Use when the target is a syntax pattern (every call/class/import shaped like X, a codemod, a YAML rule) rather than literal text; for plain strings, comments, or filenames, use rg.
  • AbrowserDrives a real browser through the omowright library from the js eval kernel: sites the user is already signed into, forms and clicks, JS-rendered pages, screenshots, web QA, extension popups, a human handoff for login, CAPTCHA or OTP, and a browser you own for scraping, bot-scored targets, network capture and QA traces. Use for any interactive browser task; not for a plain search or an unblocked static fetch.
  • Acodex-qaQA the omo Codex Light edition (lazycodex / packages/omo-codex) itself, in strict isolation so ONLY our plugin is exercised, never the user's real ~/.codex. The first-party method drives the real `codex app-server` against an isolated CODEX_HOME plus a LOCAL mock model (no real API call), and proves a plugin hook fired by asserting hook/started + hook/completed notifications. Also: isolated install verification, per-component hook probes, a tmux TUI smoke, and runtime log observation (RUST_LOG / logs SQLite / /debug-config). Ships tested helper scripts each with a --self-test. Use whenever someone changes anything under packages/omo-codex or wants to QA, smoke-test, verify, or debug the Codex plugin, its hooks/components, the installer/config.toml, the app-server flow, or the Codex TUI. Triggers: codex qa, qa codex, codex-qa, test codex plugin, verify codex hook, codex app-server, lazycodex qa, isolated CODEX_HOME, prove codex hook fired, codex tui test.
  • Acoding-agent-sessionsFinds, reads, and reconstructs coding-agent sessions across Codex, Claude, OpenCode, OMO/Senpi, and other local agent logs. Use when asked to find or search past sessions, transcripts, or subagent runs, or to recover what an earlier session did.
  • Acomment-checkerUse when Codex needs to understand or respond to automatic comment-checker feedback emitted after an edit-like PostToolUse hook.
  • Adag-libraryStores a DAG definition once and re-runs it by name, instead of pasting the definition into every run. Use when the user wants to save a DAG, run a saved one, or schedule the same multi-agent graph repeatedly.
  • Ddata-scientistProcesses and analyzes data with resident-kernel engines (DuckDB, Polars) and one-shot tools. Use for CSV/parquet/JSON analysis, group-by/join/aggregation, time series, distributions, cleaning, or plotting a dataset.
  • AdebuggingRuns a hypothesis-driven debugging loop across any language or binary, escalating to orthogonal oracle angles and locking the fix with a failing test. Use for crashes, silent failures, hangs, wrong responses, memory leaks, async misbehavior, or reverse engineering.
  • Adev-browserBrowser automation with persistent page state. Use when users ask to navigate websites, fill forms, take screenshots, extract web data, test web apps, or automate browser workflows. Trigger phrases include "go to [url]", "click on", "fill out the form", "take a screenshot", "scrape", "automate", "test the website", "log into", or any browser interaction request.
  • AfrontendBuilds, styles, and polishes anything drawn with HTML, CSS, or SVG: web UI, pages, components, HTML reports rendered to PDF or print, figures, PNG/SVG diagrams, slides, and images for Notion or Slack. Use for any styling, layout, animation, or visual-quality task, or when asked to make something look or feel a certain way.
  • AfrontendBuilds, styles, and polishes anything drawn with HTML, CSS, or SVG: web UI, pages, components, HTML reports rendered to PDF or print, figures, PNG/SVG diagrams, slides, and images for Notion or Slack. Use for any styling, layout, animation, or visual-quality task, or when asked to make something look or feel a certain way.
  • Aget-unpublished-changesCompare HEAD with the latest published npm versions and list all unpublished changes by release layer. Triggers: unpublished changes, changelog, what changed, whats new.

All agent skills → · MCP servers