Tempo Harness

Appearance

build-pr-feedback ​

build-pr-feedback

buildwriteshands-on

Use this when: you want one review nit applied everywhere it occurs

Problem it solves — A single 'I don't like X here' is really a general principle. This infers the principle behind one flagged example, finds every other instance across the change, fixes them on confirm, and captures the rule as a learning so it sticks.

Build PR feedback ​

You flag one or two examples of a thing you don't like — but the real ask is the principle behind them, applied everywhere. This skill closes that gap: generalise the snag, sweep for every instance, fix on confirm, then widen.

Generalise correctly — this is the skill ​

A spot-flag is the symptom; the principle is the target. Infer the principle and state it back in one line before touching anything. Get it wrong and you "fix" the wrong thing across the whole repo, so:

  • read the comment and the flagged code in context — what's the actual objection? (a naming smell? a missing guard? an arch violation? a convention?)
  • state the principle plainly: "You flagged X here; I read this as: <principle>."
  • if the generalisation is genuinely ambiguous (it could mean two different things), confirm the principle with the user (AskUserQuestion) before sweeping. One question now beats a wrong sweep.

Workflow — generalise → PR → codebase, gated at each step ​

  1. Infer + state the principle (above). Confirm it if ambiguous.
  2. Sweep the PR. Find every instance of the principle across the PR's changed files (git diff <base>..., codegraph/grep). Include the originally-flagged ones.
  3. Present all instances — flagged + found — with file:line and the fix each needs. AskUserQuestion (multi-select) which to apply. Apply only the confirmed.
  4. Offer the wider scope. Ask whether to apply the principle across the whole codebase, not just the diff. This is bigger and riskier, so it's a separate explicit confirm: sweep the repo, present the new instances, let the user pick, apply only those. Default to PR-only unless they opt in. The codebase sweep may fan out per docs/agents/orchestration.md — parallel read-only Explore scouts (the stated principle as the brief, one area each), hit lists merged per docs/agents/deterministic-merge.md; the fixes stay in-thread behind the confirm.
  5. Roll it back into the system — always do this, even for a one-line chat gripe. A principle worth applying broadly is a convention worth recording — so end by running find-learnings (surface-then-confirm): capture it as a learning, and if it's a standing rule, graduate it into .claude/rules/ (and, if it's mechanically checkable, flag it as a candidate qa-code lens / harness:check check). This is the compounding step — next time the rule catches it before you have to. This is the closing step that makes feedback self-correcting; skipping it is the bug (don't hand-apply the fixes and walk away — that's how the principle fails to stick).
  6. (Optional) Reply on the thread. If this came from a PR review, offer to post a short summary of what was applied and resolve the thread — posting to GitHub is outward, so confirm before posting.

Where it sits ​

  • Not qa-code — that checks the diff against rules we've already written down; this generalises an ad-hoc concern you raised that may not be a documented rule yet (step 5 is how it becomes one).
  • Not check-reasoning (red-teams a decision). This applies a stylistic/structural principle broadly.
  • It writes code, so every scope (PR, then codebase) is surface-then-confirm; nothing is applied unprompted.

How this gets triggered ​

Invoke when actioning any flagged feedback — a PR review comment, or a snag the user raises in chat ("you keep defaulting to arrays", "I don't like this pattern"). "Apply this everywhere" / "action my review comment". If you're watching a PR (subscribe_pr_activity), a new review comment is the natural cue. Not hook-fired — you decide a flag is worth generalising. Reach for this skill rather than hand-applying a one-off fix: the hand-apply path skips the learning-capture (step 5) that makes the principle stick.