Ultraperf
This is a Hermes-native ultraperf workflow skill.
Why This Exists
ultraperf exists because most performance work starts unlocalized: something is slow, leaking, or expensive and nobody knows where. It forces measurement before edits, one hypothesis at a time, executor-owned changes, and a regression budget, so an optimization loop cannot end in unverified claims.
Do Not Use When
- Metric, baseline, budget, and benchmark command are already declared for one measurable goal; use
performance-goal.
- The ask is to judge code quality, structure, or correctness rather than measured cost; use
code-review.
- The ask is to score model or agent output quality on a task suite; use
agent-evaluation.
- The request is a settings-only change, one bounded edit that is explicitly low-risk and has a direct owner and verification path, or one already-identified slow query or hotspot fix; handle it directly instead of opening a performance loop.
Examples
Good example:
- Prompt: $ultraperf checkout feels slow and the worker memory keeps climbing - find where and fix it
- Expected behavior: Audit the baseline, name the evaluator command, rank hot-path hypotheses, hand the smallest reversible fix to the selected executor, re-measure, and state the budget delta.
- Why: The problem is real but unlocalized across more than one domain.
Bad example:
- Prompt: $ultraperf make the recommender p95 under 200ms; baseline 340ms, benchmark is 'make bench'
- Expected behavior: Route to
performance-goal, which owns a declared metric/baseline/budget/benchmark goal.
- Why: A single declared measurable goal does not need a discovery loop.
Completion Checklist
- Baseline, workload, environment, and evaluator command are recorded before any edit is proposed.
- Each accepted fix names the measured hot path, the reversible change, and its owner.
- Re-measured deltas cite observed evidence; unmeasured steps stay not_observed.
- The regression budget and the gate that enforces it are stated with the tolerance.
Recovery Notes
- If no evaluator command exists, stop the loop and produce one before touching code.
- If the re-measure does not move, revert the change and re-rank hypotheses instead of stacking fixes.
- If the goal turns out to be one declared metric with a budget, hand off to
performance-goal.
Workflow Lane
- Current lane: Intent -> plan (
oh-my-hermes, meta-router, deep-interview, context, plan, ralplan, adversarial-consensus, codebase-onboarding, +9 more) - clarify, plan, ship, or loop goals.
- 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 performance problems are suspected but not yet localized, or when several cost hotspots across domains need a measured inspect-and-fix loop.
Strong routing signals: `ultraperf`, `$ultraperf`, `ulw-perf`, `performance audit`, `performance bottleneck`, `find the bottleneck`, `profile the hot path`, `memory leak investigation`, `token cost hotspot`, `storage footprint audit`, `rendering jank`, `model inference hotspot`, `slow ci pipeline`, `query performance audit`, `성능 병목`, `메모리 누수`, `느려진 원인`, `성능 전반 점검`
Catalog Metadata
Category: optimization
Phase: measured-optimization-loop
Hermes role: tracker
Quality tier: measurement-gated
Reasoning demand: heavy
Quality bar:
- Record a baseline and name the evaluator command before proposing any optimization edit.
- Attack only a hot path shown by a measurement or profile; never micro-optimize unmeasured code.
- Keep every fix the smallest reversible change and route code edits to the selected executor.
- Re-measure after each change and report deltas only from observed evidence.
- Never present a restart, cache flush, or resource bump as a leak fix; prove causation by revert-verify.
- Set the regression budget as baseline x (1 + tolerance) and name the CI gate that enforces it.
- A mid-run user message is an interjection, not a stop: answer it briefly and, in the same reply, continue the run — re-read the phase todo when one is active and dispatch or advance the next pending step, or name the armed wait it is waiting on -- handle, bound completion signal, deadline -- instead of re-reading status. Only the user's explicit stop or cancel, or the engine's own completion gate, ends the run; when the interjection changes scope, say so and update the declared plan or todo instead of silently abandoning it.
Handoff policy:
Hermes owns the audit, baseline, hypothesis, budget, and status; every optimization code edit becomes a selected executor/runtime handoff and returns as observed re-measurement.
Required inputs:
- symptom or suspected slow surface
- workload or reproduction
- runnable evaluator or measurement command
- acceptable tolerance
Expected outputs:
- baseline record
- ranked hot-path hypotheses
- smallest reversible fix handoff
- re-measured delta
- regression budget and gate
Artifact expectations:
- baseline measurement record
- final profile or benchmark evidence
- budget delta with tolerance
Safety rules:
- Do not claim a profile, benchmark, measurement, or CI budget gate ran without observed evidence.
- Do not begin optimization edits before an evaluator command and its pass/fail contract exist.
- Ask for the workload, environment, and acceptable tolerance before declaring a budget.
Runtime Evidence
Preferred harness for this skill: goal-execution.
omh runtime record --skill ultraperf --harness goal-execution --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: ulw-perf3description: [omh] Ultraperf - find where a system is actually slow, leaking, or expensive across runtime, memory, token cost, storage, rendering, inference, CI, and query domains, then fix one measured hot path at a time behind a regression budget. Use when the user says: ultraperf, ulw-perf, performance audit, performance bottleneck, find the bottleneck, profile the hot path, memory leak investigation, token cost hotspot.4---5
6# Ultraperf
7
8This is a Hermes-native `ultraperf` workflow skill.
9
10## Why This Exists
11
12`ultraperf` exists because most performance work starts unlocalized: something is slow, leaking, or expensive and nobody knows where. It forces measurement before edits, one hypothesis at a time, executor-owned changes, and a regression budget, so an optimization loop cannot end in unverified claims.
13
14## Do Not Use When
15
16- Metric, baseline, budget, and benchmark command are already declared for one measurable goal; use `performance-goal`.
17- The ask is to judge code quality, structure, or correctness rather than measured cost; use `code-review`.
18- The ask is to score model or agent output quality on a task suite; use `agent-evaluation`.
19- The request is a settings-only change, one bounded edit that is explicitly low-risk and has a direct owner and verification path, or one already-identified slow query or hotspot fix; handle it directly instead of opening a performance loop.
20
21## Examples
22
23Good example:
24
25- Prompt: $ultraperf checkout feels slow and the worker memory keeps climbing - find where and fix it
26- Expected behavior: Audit the baseline, name the evaluator command, rank hot-path hypotheses, hand the smallest reversible fix to the selected executor, re-measure, and state the budget delta.
27- Why: The problem is real but unlocalized across more than one domain.
28
29Bad example:
30
31- Prompt: $ultraperf make the recommender p95 under 200ms; baseline 340ms, benchmark is 'make bench'
32- Expected behavior: Route to `performance-goal`, which owns a declared metric/baseline/budget/benchmark goal.
33- Why: A single declared measurable goal does not need a discovery loop.
34
35## Completion Checklist
36
37- Baseline, workload, environment, and evaluator command are recorded before any edit is proposed.
38- Each accepted fix names the measured hot path, the reversible change, and its owner.
39- Re-measured deltas cite observed evidence; unmeasured steps stay not_observed.
40- The regression budget and the gate that enforces it are stated with the tolerance.
41
42## Recovery Notes
43
44- If no evaluator command exists, stop the loop and produce one before touching code.
45- If the re-measure does not move, revert the change and re-rank hypotheses instead of stacking fixes.
46- If the goal turns out to be one declared metric with a budget, hand off to `performance-goal`.
47
48## Workflow Lane
49
50- Current lane: **Intent -> plan** (`oh-my-hermes`, `meta-router`, `deep-interview`, `context`, `plan`, `ralplan`, `adversarial-consensus`, `codebase-onboarding`, `+9 more`) - clarify, plan, ship, or loop goals.
51- If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
52- Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.
53
54## Use When
55
56Use when performance problems are suspected but not yet localized, or when several cost hotspots across domains need a measured inspect-and-fix loop.
57
58 Strong routing signals: `ultraperf`, `$ultraperf`, `ulw-perf`, `performance audit`, `performance bottleneck`, `find the bottleneck`, `profile the hot path`, `memory leak investigation`, `token cost hotspot`, `storage footprint audit`, `rendering jank`, `model inference hotspot`, `slow ci pipeline`, `query performance audit`, `성능 병목`, `메모리 누수`, `느려진 원인`, `성능 전반 점검`
59
60## Catalog Metadata
61
62Category: `optimization`
63Phase: `measured-optimization-loop`
64Hermes role: `tracker`
65Quality tier: `measurement-gated`
66Reasoning demand: `heavy`
67
68Quality bar:
69
70- Record a baseline and name the evaluator command before proposing any optimization edit.
71- Attack only a hot path shown by a measurement or profile; never micro-optimize unmeasured code.
72- Keep every fix the smallest reversible change and route code edits to the selected executor.
73- Re-measure after each change and report deltas only from observed evidence.
74- Never present a restart, cache flush, or resource bump as a leak fix; prove causation by revert-verify.
75- Set the regression budget as baseline x (1 + tolerance) and name the CI gate that enforces it.
76- A mid-run user message is an interjection, not a stop: answer it briefly and, in the same reply, continue the run — re-read the phase todo when one is active and dispatch or advance the next pending step, or name the armed wait it is waiting on -- handle, bound completion signal, deadline -- instead of re-reading status. Only the user's explicit stop or cancel, or the engine's own completion gate, ends the run; when the interjection changes scope, say so and update the declared plan or todo instead of silently abandoning it.
77
78Handoff policy:
79
80Hermes owns the audit, baseline, hypothesis, budget, and status; every optimization code edit becomes a selected executor/runtime handoff and returns as observed re-measurement.
81
82Required inputs:
83
84- symptom or suspected slow surface
85- workload or reproduction
86- runnable evaluator or measurement command
87- acceptable tolerance
88
89Expected outputs:
90
91- baseline record
92- ranked hot-path hypotheses
93- smallest reversible fix handoff
94- re-measured delta
95- regression budget and gate
96
97Artifact expectations:
98
99- baseline measurement record
100- final profile or benchmark evidence
101- budget delta with tolerance
102
103Safety rules:
104
105- Do not claim a profile, benchmark, measurement, or CI budget gate ran without observed evidence.
106- Do not begin optimization edits before an evaluator command and its pass/fail contract exist.
107- Ask for the workload, environment, and acceptable tolerance before declaring a budget.
108
109## Runtime Evidence
110
111Preferred harness for this skill: `goal-execution`.
112
113```sh
114omh runtime record --skill ultraperf --harness goal-execution --status started
115```
116
117Record observed delegation results; otherwise return `not_available` or `not_observed`.
118Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
119- Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.
120Preserve workflow intent and stop conditions; verify before claiming completion.
121
122Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.
123
124Shared product, compatibility, topology, memory, harness, and execution rules: `omh-routing/references/skill-common-rail.md`. Load it when applicable; otherwise name an unavailable capability.
rlaope