Tempo Harness

Appearance

optimise-code ​

optimise-code

optimisewriteshands-on

Use this when: a hot path is slow or heavy

Problem it solves — Code gets slow or heavy in the hot paths. This makes an existing implementation faster or leaner without changing what it does.

Optimise code (perf & efficiency) ​

Find the real wins, not micro-noise. Every finding names the cost, cites the line, and proposes the fix — and nothing is applied until you pick it.

The lenses — this is the skill ​

The value is spotting the costly pattern and estimating the win, not listing every theoretical tweak. For the changed code (then, on confirm, the wider repo):

  • Database — N+1s (missing eager loads), queries inside loops, over-fetching columns, missing indexes on filtered/sorted columns, count() vs loaded collections. (Lean on .claude/rules/database.md + laravel-best-practices.)
  • Recompute vs cache — expensive work repeated per request/job that could be cached or computed once (the "reason once, serve many" principle). Time estimates already cache to Todoist labels — mirror that instinct.
  • External calls — unbatched/looped calls to Todoist / Anthropic / Google; fetch-in-loop; missing bulk endpoints; prompts carrying more context than needed.
  • Algorithmic / payload — O(n²) over collections, repeated re-sorting, large payloads or prompt context that could be trimmed.

Skip premature micro-optimisation: if it isn't on a hot path or a real N+1, say so rather than padding the list.

Scope — diff first, then offer the codebase ​

  1. PR diff first — git diff <base>.... Surface opportunities in the changed code, AskUserQuestion which to apply, apply only the confirmed.
  2. Then offer the wider scan — ask whether to sweep the whole codebase for the same patterns. That's bigger and riskier, so it's a separate explicit confirm; default to diff-only unless you opt in.

Output ​

A table: opportunity · file:line · estimated win (why it's costly) · the fix. Then confirm which to apply. Apply only the confirmed; re-run the affected tests after. A clean diff is a valid result — say "nothing worth changing" and stop.

Where it sits ​

  • Not qa-code (does it follow our rules) or check-reasoning (is the decision sound) or /code-review (correctness) — this is speed/efficiency. Overlaps /simplify, but that's readability; this is cost.
  • In check-everything it belongs to Work, and naturally runs after qa-code (optimise the settled, conformant code).

How this gets triggered ​

Invoke directly — "can this be faster?", "any N+1s / optimisations?". The suggest-skills.sh hook can nudge it after a green composer ci:check alongside qa-code.