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 jxoesneon/Ciel --skill eval-harnessgit clone --depth 1 https://github.com/jxoesneon/CielWrote 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/jxoesneon/ciel/eval-harness)<a href="https://agentmods.dev/skills/jxoesneon/ciel/eval-harness"><img src="https://agentmods.dev/badge/skills/jxoesneon/ciel/eval-harness.svg" alt="Measured on agentmods" 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.00024 | $0.00723 |
| Opus 5 | $0.00012 | $0.00362 |
| Sonnet 5 | $0.00005 | $0.00145 |
| Haiku 4.5 | $0.00002 | $0.00072 |
Grade A, and why
eval-harness 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 4d 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.
How it starts
The opening of the file, as written. The whole thing — 72 lines — stays where its author put it; the contents beside it link to each section on GitHub.
CIEL ADAPTATION: Eval-Harness (Verification Architecture)
This skill formalizes Eval-Driven Development (EDD) within CIEL. It acts as the ultimate quality gate for agent-generated code, prompt engineering, and complex workflows. It treats AI evaluations as "unit tests for agent development."
Integration Context
Adapted from ~/.agents/skills/eval-harness/. This skill is reserved for complex, multi-agent orchestration, autonomous loops, or benchmarking. For standard, everyday coding tasks, CIEL's default Test-Driven Development (TDD) rule applies. This harness provides the heavy-duty framework for the Verification-Loop when formal reliability metrics are required.
The EDD Lifecycle
1. Define (Before Coding)
Before dispatching a sub-agent for a complex task, the Orchestrator MUST define the pass/fail criteria.
- Capability Evals: What new thing must the system do?
- Regression Evals: What existing things must the system NOT break?
2. Grader Types
Evals must be graded using one of three methods:
- Code-Based Grader: Deterministic shell commands (e.g.,
npm test,pytest,grep). Preferred. - Model-Based Grader: Using an LLM-as-a-Judge with a strict rubric to evaluate open-ended outputs.
- Human Grader: Pausing the workflow for manual review (used for high-risk or subjective changes).
3. Metrics
Track agent reliability using formal metrics:
- pass@1: Success on the first attempt (Measures prompt clarity).
- pass@3: Success within 3 attempts (Measures self-correction capability).
- pass^3: Three consecutive successes (Measures absolute stability for critical paths).
Orchestration Workflow
When triggered to formally evaluate a complex feature or agent workflow:
- Create an eval definition file (e.g.,
.ciel/evals/<feature>.md). - Run the implementation (
subagent-driven-development). - Execute the defined graders against the output.
- Conditional: Only generate a formal report detailing the
pass@kmetrics if explicitly benchmarking or running in a continuous autonomous loop (to prevent context bloat).
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.
- 4d ago First seen · 72 lines · 24 tokens per session scan A 68c739175a27
eval-harness is a skill published in the GitHub repository jxoesneon/Ciel (1 stars, last pushed today), licensed Apache-2.0. It adds 24 tokens to every session and 723 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
tdd-workflow
Use this skill when writing new features, fixing bugs, or refactoring code. Enforces test-driven development with 80%+ coverage including unit, integration, and E2E tests.
tdd-guide
Test-Driven Development specialist enforcing write-tests-first methodology. Use PROACTIVELY when writing new features, fixing bugs, or refactoring code. Ensures 80%+ test coverage.
ap-implementer
L3 executor - G4 IMPLEMENT. Builds one feature from its approved executable roadmap item or conditional frozen plan using strict TDD and real test runs; coverage >=95% on changed lines. Reports PLAN-CONFLICT rather than improvising.
superpowers
Use when the user wants a disciplined software development workflow with design-first planning, implementation plans, TDD, systematic debugging, code review, or verification-before-completion, adapted from obra/superpowers.
Test-first
Use before implementing a feature or bugfix — write the failing test before the code.
review-tests
Reviews test quality and coverage. Use when checking that a diff has adequate tests, checking a new or edited test, or auditing the test suite of a codebase.