Ulw Perf

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, keep the loop and start from that baseline instead of profiling for a hot path.

Workflow Lane

• Current lane: Intent -> plan (oh-my-hermes, meta-router, deep-interview, context, plan, ralplan, adversarial-consensus, codebase-onboarding, +8 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`, `performance-goal`, `performance goal`, `latency`, `throughput`, `benchmark`, `성능 병목`, `메모리 누수`, `느려진 원인`, `성능 전반 점검`

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. A mid-run message is the latest steering for the active task, not automatically a replacement objective: it replaces the objective when the user says so and steers the current one otherwise.
• A follow-up that needs new authority, materially expands the scope, or changes external state not already authorized is described first and started only on the user's approval: the turn ends by naming that next action and asking whether to take it, as one question carrying the choices the user has, never by declaring what will not be done; persistence never broadens the authorized scope. A refused escalation is answered the same way, with a safer alternative inside the boundary or the authorization the boundary asks for — never a workaround or an indirect execution.
• The closing brief scales to the change: one or two sentences plus the observed validation for a simple change, more only when the complexity earns it. Lead with the result or decision, in the user's words; omit abandoned approaches unless they explain a tradeoff the reader needs; narrate no internal bookkeeping (todo transitions, waits). When the work stops at a boundary or at a decision the user owns, end with the next action offered as a question, and state what was left undone as the option it leaves open, never as a refusal. Required closing lines stay outside this scaling: the observed run summary, and any prepared-not-observed or unmerged work, are stated whatever the brief's length.