PerformanceMonitor: Skill for Claude Code

Lane orders

One lane works one issue, or a few small related ones, in its own worktree. An issue too big for one lane still gets ONE branch and ONE PR: its lanes share the issue branch (see "Worktree and branch"). The coordinator reviews each PR, arms auto-merge and splices the CHANGELOG. These orders apply alongside the user's token guardrails, which win on conflict.

The coordinator fills these per wave, in every brief:

• <LANE>, <ISSUES>, <DEADLINE>;
• <RIG_PORT>, <RIG_DIR>, <PG_RUNTIME_ZIP>;
• <CHANGELOG_BUFFER_DIR>.

If your brief leaves one unfilled, don't invent a value. Skip the step that needs it and say so in the PR body.

Isolated worktrees live under .claude/worktrees/ inside the repo, so a repo-scanning test must not exclude that path.

For the coordinator

Before dispatch:

• Rank the queue and get the OK the guardrails require.
• Post every ruling on its issue and put it in the first prompt.
• Pre-approve any store migration by name. Every other lane stops and reports instead.
• Fast-forward the main checkout's local dev. A lane agent loads this skill from that checkout, and a stale checkout can lack it.

At dispatch:

• Dispatch each lane as a lane agent (Claude Code: subagent_type: "lane") where the harness defines that type. It runs on the default tier (Sonnet) in its own worktree, with this skill loaded and a context watchdog attached. Where the type does not exist, use a general agent on the default tier with worktree isolation (Claude Code: isolation: "worktree"). Put these orders in its brief.
• A lane that fixes review findings also runs on the default tier. The top tier reviews, and the default tier fixes what the review found.
• Give each lane its own rig port.
• Set a wall-clock check at each lane's deadline; don't wait on notifications.
• Measure a field number before a plan depends on it. A design built on a derived figure (a lag, a row count, a timing) gets that figure measured first, read-only, by whoever has access to the field. #6254's plan went through seven revisions on a lag figure nobody had measured; a one-hour measurement answered it.
• Stack or serialize PRs that touch the same files instead of running them in parallel. Each parallel PR on the same files needed a conflict fix and another full CI run.
• Give browser and click-through checks their own small lane, apart from the code change. Screenshots and page reads fill a lane's context fast.
• Size each lane to finish under 200k. A lane's context grows about 1.9k tokens per call from a 24-40k base, so 200k is about 80-90 calls. A lane that converts three tools uses 100-117 calls. A lane with two twin pairs (two tools on both products) uses 103-167 calls and peaks at 214-242k. Give a lane that converts tools one twin pair, or two tools on one product.
• Check that the effort level took effect: grep a lane transcript for "effort":. An effort: set in the agent file does not always apply, and a lane can then run at the seat's level.
• Every head clause about a status must keep its condition's scope: "none collected in the window" is not "nothing collected yet". Leave no state out.
• Paste into the brief the few lines a lane needs (an example, a ruling) instead of pointing it at a PR or file. A pointer costs every lane a read of 8-10k characters to find one example.
• Label each issue the lane takes in-progress (gh issue edit <n> --add-label in-progress), so the board shows it as taken; remove the label when the issue closes or the work stops.
• Before dispatching several lanes for one issue, create its issue branch (git -C <repo> push origin origin/dev:refs/heads/fix/<issue>-<slug>) and name it in every brief, with the lane that writes the PR summary and the CHANGELOG entry. Open a separate PR only for a part that must ship before the rest; an issue that is really several issues is split into issues first. Reviews of an issue PR built in waves: one round per wave on that wave's commits only, plus one final round on the whole PR.