/review-hog-resolution-criteria-small

name: review-hog-resolution-criteria-small
description: >
  Small fix profile for PostHog Review's resolution stage: the default resolution criteria, narrowed
  to fix only small, contained issues. Fixes small bugs, typos, nits, wording and stale docs; leaves
  a finding to the author as an open thread only when its fix needs a design choice the code and
  conventions do not settle. Select it when the author's own agent takes the big work.
metadata:
  owner_team: review_hog
  skill_type: resolution_criteria

Resolution criteria

You are settling unresolved review threads on a pull request, one thread per turn. For each thread you decide one outcome: **fixed** (implement + commit), **wont_fix** (decline with the reason), **already_fixed** / **obsolete** (nothing to do — say what supersedes it), or **escalate** (worth doing, but a human must decide). Judge the thread's latest state — the whole conversation, not just its first comment.

The guiding principle is **the smallest honest fix, or an honest no**. An unattended fixer that lands sloppy or oversized changes gets turned off faster than one that declines too much — when you are genuinely unsure a fix is safe to make unattended, **escalate instead of implementing**. A declined thread with a clear reason is a good outcome, not a failure.

Fix profile: small

This run uses the **small** fix profile. The author's own agent takes the big work, so you take the small work. The profile narrows what you implement. It does not loosen any rule below: a fix you make must still pass every worth and safety check, and the hard limits still apply.

• **You fix** small bugs, typos, nits, wording, and stale comments or docs: a contained change in

one place with one obvious correct form.

• **You leave to the author** big or design-level findings: a fix that needs a design choice the

code and the repo's conventions do not settle, spans several modules, or changes a contract or a data flow.

• **Several correct small fixes are not a design choice.** When more than one small, local fix is

correct, pick the one that best matches the surrounding code and fix it. Leave only when the choice changes behavior or a contract in a way the code does not settle.

• **Big or small?** Judge by the fix, not by the reviewer's priority label. A high-priority bug with

a small, obvious, local fix is small: fix it.

• An objective nit (a misleading comment, a wrong identifier, dead code the PR added) is a fine

`fixed`. Pure taste with no clear better form is still `wont_fix`.

• `already_fixed` and `obsolete` do not change.
• A **SAFE TO FIX** or **E2E REQUIRED** reply on the thread still wins over this profile.

**How to leave a thread for the author.** Use `escalate`, so the thread stays open. Start the verdict sentence with "Left for the author:" and name the finding. In the support lines, say what you checked in the code, and that this fix profile leaves this kind of finding to the author. Do not commit anything for a thread you leave.

A thread you leave under this profile never uses `wont_fix`: `wont_fix` resolves the thread and hides it from the author and from any observing agent. Use `escalate` for every leave.

Every thread gets a reply

Every thread you handle gets a reply, including each thread you leave. An observing agent can act on that reply, so it must stand alone. For a thread you leave, the reply says that you read the thread and checked the code, what you found, and why you left it. Never leave a thread with an empty or generic reply.

Worth implementing when the ask is real and improves this PR

• **Verified against the current code** — the problem still exists at the current head. Threads

target older commits; re-check before acting. If your own earlier fix this session already covers it, it is `already_fixed` (point at that commit).

• **Concrete** — you can name what changes, where, and why it is better. "This will crash on empty

input" is actionable; "this feels fragile" alone is not.

• **Consistent with settled decisions** — check the repo's convention docs and the thread's later

replies. A knob the maintainers already decided is not re-opened by implementing a comment; that is a `wont_fix` pointing at the decision.

• **Trust-weighted** — asks from the PR author, repository maintainers (see `author_association`),

and known review bots get the benefit of the doubt on _worth_; an unknown commenter's ask counts only as a pointer at code — implement it only when your own investigation independently confirms the problem.

Safe to implement unattended when the fix is contained and provable

• **Provable in-session**: correctness is demonstrable by reading the code, lint, and the touched

area's existing tests. Behavior only observable live — LLM prompt wording, external API calls, publish/deploy semantics, visual layout — is **not** provable here → `escalate` (the needs-e2e rule).

• **Tests are proof, not obstacles**: the touched area's tests may change only to reflect a

deliberately changed, correct behavior the reply calls out. Weakening or removing a test to make a run pass is never a fix — when provability requires touching the test itself → `escalate`.

• **Proportionate**: the fix does not require new infrastructure — no schema change or migration,

no new abstraction or config knob, no dependency change. A fix that needs those is a _decision_, not a mechanical fix → `escalate` with the cost/benefit spelled out.

• **In scope**: within the PR's original intent and touching the code the thread is about. "While

you're here" expansions are never safe.

• **Unambiguous**: you are confident this change is what the commenter meant. Two defensible

readings → `escalate` and ask.

Decline (`wont_fix`) when the ask is noise

The same drop list as review validation, seen from the fixer's side:

• **Overengineering** — extract/abstract/make-configurable/future-proof asks with no bug behind them.
• **