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 agentmods add skills/uipath/coder_eval/analyzenpx skills add UiPath/coder_eval --skill analyzegit clone --depth 1 https://github.com/UiPath/coder_evalWhat 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 | $0.00057 | $0.03933 |
| Opus 5 | $0.00028 | $0.01966 |
| Sonnet 5 | $0.00011 | $0.00787 |
| Haiku 4.5 | $0.00006 | $0.00393 |
Grade A, and why
analyze 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 2d 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 — 331 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Analyze a coder-eval run
You analyze a coder-eval run and write analysis.md into the target directory. The
target path is $ARGUMENTS; when it is empty, resolve the run yourself by following
${CLAUDE_PLUGIN_ROOT}/reference/repo-layout.md — discover the run root rather than
assuming one, and say which run you picked and how. If you reach it through a
latest symlink, confirm that symlink resolves before reading through it.
Do all the reasoning yourself in this session — no sub-agents. Batch your Read calls in a single turn and write the report inline.
The run directory layout and its scope-marker files are described in
${CLAUDE_PLUGIN_ROOT}/reference/run-layout.md — read it first; step 1 relies on those
markers.
Step 1 — Determine scope
Inspect the target path:
task.jsondirectly inside → task scope (single replicate).??/task.jsonsubdirectories but novariant.json→ task scope, aggregated over replicates pertask_id.- Contains
variant.json→ variant scope. - Contains
run.json→ run scope. Ifexperiment.jsonis also present, it is a multi-variant experiment.
If the path contains none of those markers, say which markers you looked for and stop. Do not guess a scope from directory names.
Step 2 — Read the data
Task scope (single): read task.json.
Task scope (aggregated replicates): read every ??/task.json and merge —
per-replicate arrays for final_status, weighted_score, iteration_count,
duration_seconds, total_token_usage.total_cost_usd, and the union of
success_criteria_results keyed by criterion description. Drive recommendations from
the aggregate ("3/5 replicates failed criterion X"), never from a cherry-picked
replicate.
Variant / run scope with more than 20 tasks: do not read the full task.json
files — their iterations arrays are large and only useful per task. Extract a compact
summary per task with jq (or python3 if jq is missing):
{
task_id, final_status, weighted_score, duration_seconds,
iteration_count, model_used, max_turns_exhausted,
total_cost_usd: .total_token_usage.total_cost_usd,
total_tokens: (.total_token_usage.input_tokens + .total_token_usage.output_tokens),
assistant_turns: .total_assistant_turns,
max_turns: .task_config.resolved.run_limits.max_turns,
criteria_count: (.success_criteria_results | length),
all_criteria_perfect:
(.success_criteria_results | length > 0 and all(.[]; .score == 1.0)),
failed_criteria: [
.success_criteria_results[]
| select(.score < .pass_threshold)
| {criterion_type, description, score,
error_excerpt: ((.error // .details // "")[0:200])}
]
}
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.
- 2d ago First seen · 331 lines · 57 tokens per session scan A 4c7293c462ec
analyze is a skill published in the GitHub repository UiPath/coder_eval (119 stars, last pushed 4d ago), licensed Apache-2.0. It adds 57 tokens to every session and 3,933 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
execution
M-1.4 execution skill — 跑 single task 产 patch + 提交 envelope。.
fix-self-check
M-1.6 envelope self-check——独立性保证不自欺欺人 (5 blockingcheck)。由 CLI ./tw fix complete --self-check-mode fork(默认即 fork)自动派起,不经 Skill 工具调用;fix 主会话产 FixCompleted 前直读本文,是为理解双层验证关系。.
review
M-1.5 review skill — 在 patch 跟 contract 之间找 finding,produce Finding 一等对象。.
dependency-analyze
从 task 的 read/write set + concept statemachine 推导 6 种依赖类型的提案。主 planner 决定边的真实性。派它时只给 read/write set 与疑点、不给预期边集;已有预判逐条标「待复核」交它取证。.
execution-self-check
Pre-submit 自检——envelope 提交 commit gate 前必跑。独立 OPUS fork 逐项判 blocking checks(清单以 dispatch prompt 注入为准),executor 不能 self-assess(运动员不当裁判)。.
fix
修复者 — 把一条被发现的问题(finding)按它的闭合合约修干净,修一个不制造下一个。产 FixProposed + 临时的 FixCompleted,不自判问题关闭(那是复查的权)。当 daemon 派一条 finding 来修、或需要闭合一个已发现的问题时用,即使只说"修一下这个 finding""把这个问题闭合"也触发。调用名就是 fix(Skill 工具)或 /fix(命令),没有 harness: 之类的前缀。.