Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add yiouli/pixie-qa --skill eval-driven-devgit clone --depth 1 https://github.com/yiouli/pixie-qaWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/yiouli/pixie-qa/eval-driven-dev)<a href="https://agentmods.dev/skills/yiouli/pixie-qa/eval-driven-dev"><img src="https://agentmods.dev/badge/skills/yiouli/pixie-qa/eval-driven-dev/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/yiouli/pixie-qa/eval-driven-dev"><img src="https://agentmods.dev/badge/skills/yiouli/pixie-qa/eval-driven-dev.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00089 | $0.03888 |
| Opus 5.5 | $0.00036 | $0.01555 |
| Sonnet 5.5 | $0.00018 | $0.00778 |
| Haiku 4.5 | $0.00009 | $0.00389 |
Grade A, and why
eval-driven-dev scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to eval-driven-dev — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 211 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Eval-Driven Development for Python LLM Applications
You're building an automated evaluation pipeline that tests a Python-based AI application end-to-end — running it the same way a real user would, with real inputs — then scoring the outputs using evaluators and producing pass/fail results via pixie test.
What you're testing is the app itself — its request handling, context assembly (how it gathers data, builds prompts, manages conversation state), routing, and response formatting. The app uses an LLM, which makes outputs non-deterministic — that's why you use evaluators (LLM-as-judge, similarity scores) instead of assertEqual — but the thing under test is the app's code, not the LLM.
During evaluation, the app's own code runs for real — routing, prompt assembly, LLM calls, response formatting — nothing is mocked or stubbed. But the data the app reads from external sources (databases, caches, third-party APIs, voice streams) is replaced with test-specified values via instrumentations. This means each test case controls exactly what data the app sees, while still exercising the full application code path.
Rule: The app's LLM calls must go to a real LLM. Do not replace, mock, stub, or intercept the LLM with a fake implementation. The LLM is the core value-generating component — replacing it makes the eval tautological (you control both inputs and outputs, so scores are meaningless). If the project's test suite contains LLM mocking patterns, those are for the project's own unit tests — do NOT adopt them for the eval Runnable.
The deliverable is a working pixie test run with real scores — not a plan, not just instrumentation, not just a dataset.
This skill is about doing the work, not describing it. Read code, edit files, run commands, produce a working pipeline.
Before you start
First, activate the virtual environment. Identify the correct virtual environment for the project and activate it. After the virtual environment is active, run the setup.sh included in the skill's resources.
The script updates the eval-driven-dev skill and pixie-qa python package to latest version, initialize the pixie working directory if it's not already initialized, and start a web server in the background to show user updates.
What ships with it
18 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- references/1-a-project-analysis.md 5.7 KB
- references/1-b-entry-point.md 2.3 KB
- references/1-c-eval-criteria.md 7.5 KB
- references/2a-instrumentation.md 7.3 KB
- references/2b-implement-runnable.md 7.4 KB
- references/2c-capture-and-verify-trace.md 5.7 KB
- references/3-define-evaluators.md 10 KB
- references/4-build-dataset.md 22 KB
- references/5-run-tests.md 6.0 KB
- references/6-analyze-outcomes.md 16 KB
- references/evaluators.md 18 KB
- references/runnable-examples/cli-app.md 2.0 KB
- references/runnable-examples/fastapi-web-server.md 4.1 KB
- references/runnable-examples/standalone-function.md 1.8 KB
- references/testing-api.md 16 KB
- references/wrap-api.md 8.8 KB
- resources/setup.sh 3.0 KB runs code
- resources/verify_step6_completion.py 4.4 KB runs code
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 211 lines · 89 tokens per session scan A dbaac08a46bd
eval-driven-dev is a skill published in the GitHub repository yiouli/pixie-qa (9 stars, last pushed 5mo ago), licensed MIT. It adds 89 tokens to every session and 3,888 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 100% identical to eval-driven-dev, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
preservation-verifier
Use when the user provides an original and rewritten version, asks whether a rewrite preserved protected content, or wants a deterministic check for code, frontmatter, quotes, tables, links, paths, numbers, headings, and residual AI-pattern regressions.
skillgrade-graders
Authors deterministic, LLM rubric, and human graders for skillgrade evaluations. Use when creating scoring scripts, writing evaluation rubrics, setting up human review workflows, or combining multiple graders with weighted scoring. Don't use for setting up eval pipelines, configuring eval.yaml defaults, or general…
skillgrade-setup
Sets up and runs skillgrade evaluation pipelines for AI agents and Agent Skills. Use when initializing eval configurations, running trials, reviewing results, exporting reports, or integrating with CI. Don't use for writing grader scripts, general test authoring, or non-agentic documentation.
llm-evaluation
LLM evaluation — automated metrics, human feedback, benchmarking. Use when testing performance, measuring AI quality, or establishing evaluation frameworks.
human-loop-audit
Interaktives Reißverschluss-Audit-Verfahren für eine Serie von Apps/Prüfobjekten: der User testet live und gibt kurzes Feedback im Chat, der Agent startet dabei bereits das nächste Objekt UND wertet parallel das Feedback des vorigen aus (strukturiert erfassen, Reparaturaufträge sofort an Worker delegieren) — statt…
eval-before-ship
Use before merging, deploying, or demo'ing any LLM feature. Requires documented eval results — pass rate, failure analysis, baseline comparison. Blocks "it looked good when I tested it" completions.