Menu
Parse METRIC output lines, infer units, and track primary vs secondary metrics. Use when processing experiment output from autoresearch.sh.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when reviewing a completed implementation holistically - a finished branch, a completed plan step, or a diff before PR. Reviews every changed line against the implementation plan (if one exists) and high engineering standards across seven dimensions, verifies tests by deliberately breaking crucial code, and emits severity-classified findings with a PASS/FAIL verdict.
Use when performing a holistic code review of an implementation - routes to codex:rescue or falls back to a direct subagent, both running the house-style:holistic-review skill
ALWAYS use before any implementation work, review, or planning: designing, writing, editing, refactoring, debugging, reviewing, or generating source code, tests, scripts, config-as-code, or behavior-affecting files. This is a baseline engineering skill and should be invoked even when a more specific language, framework, testing, or database skill also applies.
Use when asked to write, draft, file, or open a GitHub issue - mandates exploring the relevant code to understand the whole problem space, reasoning any proposed solution, and structuring the issue with summary, what/why, references, nuances, open questions, and acceptance criteria. Adds professionalism and no-sensitive-info discipline for public repos.
Use when creating, editing, triaging, or cleaning up GitHub issues - a mechanical pass that verifies the title is accurate and current, labels/assignees/milestone are correct, and the body is valid, well-formed markdown, all via the gh CLI. Does not judge content quality.
Use when running Python, installing Python packages, creating virtualenvs, or executing Python CLI tools - mandates uv/uvx over direct python/pip/pipx/venv calls when uv is installed, and gives the drop-in command mappings
| name | metric-extraction |
| description | Parse METRIC output lines, infer units, and track primary vs secondary metrics. Use when processing experiment output from autoresearch.sh. |
| user-invocable | false |
Parses structured output from autoresearch.sh to extract primary and secondary metrics.
Each metric is a single line matching:
METRIC <name>=<value>
a-z, A-Z, 0-9, _), dots (.), or µ. Examples: total_µs, compile_ms, cache.hitsNaN, Infinity, and non-numeric values are silently ignored.METRIC are ignored (but may contain useful diagnostics).keep vs discard.METRIC lines. Tracked for tradeoff monitoring but don't affect keep/discard decisions.If the primary metric is missing from output, treat the run as a crash — the benchmark didn't produce the expected data.
Infer units from metric name suffixes for display and context:
| Suffix | Unit |
|---|---|
µs | µs (microseconds) |
_ms | ms (milliseconds) |
_s or _sec | s (seconds) |
_kb | kb (kilobytes) |
_mb | mb (megabytes) |
| (none matched) | (unitless) |
Units are informational — they don't affect computation.
Maintain a list of known secondary metrics discovered across the session. When a new metric name appears in output that hasn't been seen before, register it with its inferred unit. This allows consistent reporting even when scripts evolve during the loop.
When logging an experiment, record metrics as:
{
"metric": 14600,
"metrics": {
"compile_µs": 4100,
"render_µs": 9500,
"cache.hits": 42
}
}
metric: the primary metric's numeric value (top-level for easy querying)metrics: object of all secondary metric name→value pairsThe autoresearch.sh script should output whatever helps the agent make better decisions:
The script can be updated during the loop as you learn what signal matters. Add instrumentation when you need more data to decide where to focus next.