Agent Evaluation
This is a Hermes-native agent-evaluation workflow skill.
Why This Exists
agent-evaluation gives OMH a way to improve executor choice empirically, not by vibes, while preserving executor-neutral product language across Codex, Claude Code, Hermes, and generic runtimes.
Do Not Use When
- The user needs current runtime readiness only; use
executor-runtime-readiness.
- The user already selected an executor and wants implementation; use the coding handoff or delivery workflow.
- The user asks for workflow learning from a single failed route; use
workflow-learning.
- The ask is to find and fix runtime, memory, cost, or rendering hotspots rather than score executor or model output quality; use
ultraperf.
Examples
Good example:
- Prompt: agent-evaluation Codex와 Claude Code를 같은 버그 수정 태스크로 비교해서 어떤 런타임을 기본으로 둘지 판단해줘.
- Expected behavior: Prepare paired_run_decision/v1 requirements and a scenario-specific recommendation.
- Why: The request compares executor choices and needs fair evaluation boundaries.
Bad example:
- Prompt: agent-evaluation 실행 증거 없이 Codex가 항상 최고라고 결론내줘.
- Expected behavior: Reject universal ranking and require observed runs or mark the recommendation as ungrounded.
- Why: Agent evaluation must be reproducible and evidence-backed.
Completion Checklist
- Confirm the workflow target, evidence boundary, and stop condition are named.
- Report which outputs are prepared, observed, blocked, or missing.
- Name the smallest next verification or handoff instead of claiming completion from narration.
Recovery Notes
- If required context is missing, ask one blocking question or route back to the narrower workflow.
- If runtime or wrapper evidence is unavailable, keep the status as not_observed and expose the next observable action.
Workflow Lane
- Current lane: Automation and status (
achievements, workspace-audit, production-audit, automation-blueprint, github-event-ops, github-issue-intake, buzz, agent-board, +35 more) - schedules, status, health, and ops review.
- If intent belongs to another lane, hand back to
oh-my-hermes or name the adjacent workflow.
- Shared product, routing, compatibility, and evidence rules:
omh-routing/references/skill-common-rail.md.
Use When
Use when Hermes should design or summarize a fair comparison of Codex, Claude Code, Hermes coding, or generic executors for a bounded task set.
Strong routing signals: `agent-evaluation`, `agent evaluation`, `agent eval`, `agent benchmark`, `executor evaluation`, `executor benchmark`, `compare agents`, `compare codex claude`, `agent tournament`, `which agent is better`, `에이전트 평가`, `에이전트 비교`, `실행자 평가`, `코덱스 클로드 비교`
Catalog Metadata
Category: operations
Phase: agent-evaluation
Hermes role: operator
Quality tier: agent-eval-gated
Reasoning demand: light
Quality bar:
- Define tasks, rubric, isolation, budgets, and stop rules before comparing agents.
- Use the same inputs and success criteria across candidates unless the difference is the variable under test.
- Require receipt-authenticated observed_at provenance before public parse or validation can return pass or fail.
- Report quality, correctness, time, cost, tool coverage, verification, and review gaps separately.
- When the question is an agent judging and improving its own output rather than comparing executors, load
omh-agent-evaluation/references/self-evaluation-loops.md and pick the loop shape from it - reflection, evaluator-optimizer, or test-driven refinement - remembering that an executable check outranks a judge whenever one exists.
- Declare all three stop rules before the loop runs - a maximum iteration count, a score threshold chosen in advance, and a no-improvement break - and report the iteration count, the final score, and which of the three ended the run. A loop whose only stop is that the output looks good now is a defect.
- Write criteria before generation and score a rubric dimension by dimension beside its total: criteria derived from an output describe it instead of testing it, and a single number hides which dimension failed.
- Recommend executor choice per scenario and confidence, not as a universal ranking.
Handoff policy:
Keep evaluation design and scoring in Hermes. Actual executor runs, costs, timings, tool calls, code edits, and review results must come from observed runtime or supplied artifacts.
Required inputs:
- candidate executors or agents
- task set and fixtures
- success criteria and scoring rubric
- allowed tools, budget, timebox, and isolation policy
- observed run artifacts when comparing completed attempts
Expected outputs:
- paired_run_decision/v1
- not-evidence boundary
Artifact expectations:
- paired_run_decision/v1 with per-task input digests, explicit criteria, baseline and variant exposure, attempted-run and per-dispatch time budgets, signed observed_at receipt provenance, and a scoped Pareto outcome
Safety rules:
- Do not claim an executor is better from anecdotes, brand names, or unobserved runs.
- Do not send secrets, credentials, private data, or production tasks into evaluation without explicit authority.
- Keep benchmark design, observed run evidence, scoring, and executor selection separate.
- A judge score is never correctness: it licenses no claim that the output is right, tested, reviewed, or shippable, and a model scoring its own output is the weakest evidence class - labelled as such, never reported as verification.
- A signed local Hermes-child receipt proves that OMH recorded a process-sealed confirmed local dispatch event; it does not prove executor internals or protect evidence from the owning OS user.
Runtime Evidence
Preferred harness for this skill: agent-evaluation.
omh runtime record --skill agent-evaluation --harness agent-evaluation --status started
Record observed delegation results; otherwise return not_available or not_observed.
Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
- Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.
Preserve workflow intent and stop conditions; verify before claiming completion.
Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.
Shared product, compatibility, topology, memory, harness, and execution rules: omh-routing/references/skill-common-rail.md. Load it when applicable; otherwise name an unavailable capability.
1---
2name: "omh-agent-evaluation"
3description: "[omh] Hermes Agent Evaluation workflow: compare executor or agent choices on reproducible tasks using quality, cost, time, tool, and evidence metrics. Use when the user says: agent-evaluation, agent evaluation, agent eval, agent benchmark, executor evaluation, executor benchmark, compare agents, compare codex claude."
4metadata:
5 hermes:
6 tags: [workflow, oh-my-hermes, operations]
7 category: operations
8 phase: agent-evaluation
9 role: operator
10 quality_tier: agent-eval-gated
11---
12
13# Agent Evaluation
14
15This is a Hermes-native `agent-evaluation` workflow skill.
16
17## Why This Exists
18
19`agent-evaluation` gives OMH a way to improve executor choice empirically, not by vibes, while preserving executor-neutral product language across Codex, Claude Code, Hermes, and generic runtimes.
20
21## Do Not Use When
22
23- The user needs current runtime readiness only; use `executor-runtime-readiness`.
24- The user already selected an executor and wants implementation; use the coding handoff or delivery workflow.
25- The user asks for workflow learning from a single failed route; use `workflow-learning`.
26- The ask is to find and fix runtime, memory, cost, or rendering hotspots rather than score executor or model output quality; use `ultraperf`.
27
28## Examples
29
30Good example:
31
32- Prompt: agent-evaluation Codex와 Claude Code를 같은 버그 수정 태스크로 비교해서 어떤 런타임을 기본으로 둘지 판단해줘.
33- Expected behavior: Prepare paired_run_decision/v1 requirements and a scenario-specific recommendation.
34- Why: The request compares executor choices and needs fair evaluation boundaries.
35
36Bad example:
37
38- Prompt: agent-evaluation 실행 증거 없이 Codex가 항상 최고라고 결론내줘.
39- Expected behavior: Reject universal ranking and require observed runs or mark the recommendation as ungrounded.
40- Why: Agent evaluation must be reproducible and evidence-backed.
41
42## Completion Checklist
43
44- Confirm the workflow target, evidence boundary, and stop condition are named.
45- Report which outputs are prepared, observed, blocked, or missing.
46- Name the smallest next verification or handoff instead of claiming completion from narration.
47
48## Recovery Notes
49
50- If required context is missing, ask one blocking question or route back to the narrower workflow.
51- If runtime or wrapper evidence is unavailable, keep the status as not_observed and expose the next observable action.
52
53## Workflow Lane
54
55- Current lane: **Automation and status** (`achievements`, `workspace-audit`, `production-audit`, `automation-blueprint`, `github-event-ops`, `github-issue-intake`, `buzz`, `agent-board`, `+35 more`) - schedules, status, health, and ops review.
56- If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
57- Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.
58
59## Use When
60
61Use when Hermes should design or summarize a fair comparison of Codex, Claude Code, Hermes coding, or generic executors for a bounded task set.
62
63 Strong routing signals: `agent-evaluation`, `agent evaluation`, `agent eval`, `agent benchmark`, `executor evaluation`, `executor benchmark`, `compare agents`, `compare codex claude`, `agent tournament`, `which agent is better`, `에이전트 평가`, `에이전트 비교`, `실행자 평가`, `코덱스 클로드 비교`
64
65## Catalog Metadata
66
67Category: `operations`
68Phase: `agent-evaluation`
69Hermes role: `operator`
70Quality tier: `agent-eval-gated`
71Reasoning demand: `light`
72
73Quality bar:
74
75- Define tasks, rubric, isolation, budgets, and stop rules before comparing agents.
76- Use the same inputs and success criteria across candidates unless the difference is the variable under test.
77- Require receipt-authenticated observed_at provenance before public parse or validation can return pass or fail.
78- Report quality, correctness, time, cost, tool coverage, verification, and review gaps separately.
79- When the question is an agent judging and improving its own output rather than comparing executors, load `omh-agent-evaluation/references/self-evaluation-loops.md` and pick the loop shape from it - reflection, evaluator-optimizer, or test-driven refinement - remembering that an executable check outranks a judge whenever one exists.
80- Declare all three stop rules before the loop runs - a maximum iteration count, a score threshold chosen in advance, and a no-improvement break - and report the iteration count, the final score, and which of the three ended the run. A loop whose only stop is that the output looks good now is a defect.
81- Write criteria before generation and score a rubric dimension by dimension beside its total: criteria derived from an output describe it instead of testing it, and a single number hides which dimension failed.
82- Recommend executor choice per scenario and confidence, not as a universal ranking.
83
84Handoff policy:
85
86Keep evaluation design and scoring in Hermes. Actual executor runs, costs, timings, tool calls, code edits, and review results must come from observed runtime or supplied artifacts.
87
88Required inputs:
89
90- candidate executors or agents
91- task set and fixtures
92- success criteria and scoring rubric
93- allowed tools, budget, timebox, and isolation policy
94- observed run artifacts when comparing completed attempts
95
96Expected outputs:
97
98- paired_run_decision/v1
99- not-evidence boundary
100
101Artifact expectations:
102
103- paired_run_decision/v1 with per-task input digests, explicit criteria, baseline and variant exposure, attempted-run and per-dispatch time budgets, signed observed_at receipt provenance, and a scoped Pareto outcome
104
105Safety rules:
106
107- Do not claim an executor is better from anecdotes, brand names, or unobserved runs.
108- Do not send secrets, credentials, private data, or production tasks into evaluation without explicit authority.
109- Keep benchmark design, observed run evidence, scoring, and executor selection separate.
110- A judge score is never correctness: it licenses no claim that the output is right, tested, reviewed, or shippable, and a model scoring its own output is the weakest evidence class - labelled as such, never reported as verification.
111- A signed local Hermes-child receipt proves that OMH recorded a process-sealed confirmed local dispatch event; it does not prove executor internals or protect evidence from the owning OS user.
112
113## Runtime Evidence
114
115Preferred harness for this skill: `agent-evaluation`.
116
117```sh
118omh runtime record --skill agent-evaluation --harness agent-evaluation --status started
119```
120
121Record observed delegation results; otherwise return `not_available` or `not_observed`.
122Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
123- Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.
124Preserve workflow intent and stop conditions; verify before claiming completion.
125
126Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.
127
128Shared product, compatibility, topology, memory, harness, and execution rules: `omh-routing/references/skill-common-rail.md`. Load it when applicable; otherwise name an unavailable capability.