agentsclimarketplace

Performance goal

Skill mrzhangguoguo/oh-my-workbuddy/skills/performance-goal

Run an evaluator-gated performance optimization loop with durable WorkBuddy artifacts and safe handoffs. Use when the user wants measurable performance/optimization work (latency, throughput, memory) driven by a pass/fail benchmark rather than a one-off review. Triggers: 'optimize performance', 'reduce latency', 'performance goal', 'benchmark-driven optimization'.From its SKILL.md

Install
npx -y skills add mrzhangguoguo/oh-my-workbuddy --skill performance-goal

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.5 KB, 689 tokens by cl100k_base, as published. Nobody here has run it

Ported from oh-my-codex performance-goal. OMX runtime conventions ($macro invocation, omx CLI, .omx/ state directory) are replaced with WorkBuddy idioms (Skill tool, Agent tool, task list, .workbuddy/memory).

Performance Goal Workflow

Use this skill when the user asks to optimize performance and wants a goal-oriented loop with a measurable pass/fail contract, not a one-off review.

Contract

  • WorkBuddy owns durable workflow state under .omw/performance-goal/<slug>.md.
  • No optimization work may start until an evaluator command and a pass/fail contract exist.
  • Do not declare the goal complete until the evaluator has a passing checkpoint and a completion audit proves the objective is met.
  • Shell commands never mutate hidden runtime goal state — they run the evaluator and write evidence artifacts.

Setup (no omx CLI)

  1. Create a context snapshot in .omw/performance-goal/<slug>.md containing:
    • objective: the measurable target (e.g. "reduce CLI startup p95 latency by 20%").
    • evaluator_command: the command that produces the benchmark (e.g. npm run perf:startup).
    • evaluator_contract: the PASS definition (e.g. "p95 latency improves >=20% AND regression tests pass").
    • status: created.
  2. Record the same in the task list via TaskCreate (one task per phase: start, optimize, checkpoint, complete).

If no workflow exists yet, do step 1 before any optimization.

Agent Loop

  1. Read the snapshot at .omw/performance-goal/<slug>.md; if absent, run the Setup step.
  2. Follow the handoff:
    • Work only against the declared evaluator contract.
    • Optimize in small, reversible patches.
    • Run the evaluator and related regression tests.
    • Record each result as a checkpoint in the snapshot (pass / fail / blocked) with evidence text.
  3. Optimize in small reversible patches; run the evaluator and regression tests after each.
  4. Record every checkpoint (pass/fail/blocked) in the snapshot with evidence.
  5. Complete only when a pass checkpoint exists and no required work remains.

Completion Gate

A performance goal is incomplete unless the snapshot contains a last_validation.status of pass matching the evaluator contract, plus a completion audit that maps the objective to concrete evidence (benchmark output + test results). Passing ordinary tests alone is not sufficient unless they are the declared evaluator contract.

Completion audit checklist

  • objective restated as deliverables/success criteria.
  • evaluator_command output read and confirmed to PASS per evaluator_contract.
  • Regression tests read and confirmed green.
  • Every requirement from the objective mapped to evidence in the snapshot.
  • Snapshot status set to complete and task list updated.

Lifecycle: created starts the goal, pass checkpoint marks validated progress, complete is set only after the audit passes. Update the task list (TaskUpdate) at each transition instead of shelling out to any runtime CLI.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Keep looking

Skills are one crate of 326,851. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.