Opus PR review + apply¶

Two-phase workflow: review with Opus 5.5, then apply — ask on every product/judgment doubt.

Triggers¶

« review la PR avec Opus 5.5 » / « Opus 5.5 »
« fais une review Opus et prends-la en compte »
« opus review + apply »

Phase 1 — Review (Opus 5.5)¶

Resolve PR context:
gh pr view --json number,url,title,baseRefName,headRefName
Base default: develop (or PR baseRefName)
Diff: git diff origin/<base>...HEAD (+ --stat)
Launch a Task subagent with model claude-opus-5-5-high (or claude-opus-5-5-max if the user asks for max).
Prompt the subagent to:
Read the full PR diff and the current versions of touched files
Load relevant conventions (api / front / test rules for the touched area)
Before writing the report, list every product/judgment doubt in the diff (scratch list). Parité ancien skill : each line that would have been a separate bullet under ### Questions for author (comportement, « est-ce voulu », scope, métrique, ops) → one numbered point à trancher below — never merged into one block, never dropped because you prefer one answer.
Return only the structure below (French for all prose; English for identifiers in backticks)
Self-contained items: each nit and each point à trancher understandable without opening the diff. Stay concise (bullets, not paragraphs).

### Verdict
APPROVE | REQUEST_CHANGES | COMMENT

### Blockers et importants
One item per finding (severity `blocker` or `important` only).

- **Sévérité**: blocker | important
- **Fichier**: path
- **Titre**: short
- **Pourquoi**: what breaks or risks (money, contract, prod, determinism) — 1–3 sentences, name the scenario
- **Suggestion**: concrete fix

### Nits
Only `nit` severity. **Do not** mix with blockers/importants.

Each nit MUST include all four lines (one short sentence each unless noted):

- **Où**: `path` + function/component/line area
- **Constat**: factual — convention, naming, structure (cite pattern elsewhere if useful)
- **Pourquoi le signaler**: consequence if ignored — not bare « style »
- **Correction**: one line (or « ignorable si … »)

Cap nits at ~5 unless the user asked for exhaustive style pass.

### Points à trancher (N = nombre de #### ci-dessous — le mettre dans ce titre)
Un sujet distinct = un `#### 1. …`, `#### 2. …`, etc. **Plusieurs points sont normaux** sur une PR métier ; **un seul point** alors que le scratch list (step 3) a 2+ doutes = erreur.

Ne pas fusionner (ex. règle de calcul + UX + scope script = 3 numéros). Ne pas déplacer ces sujets vers Blockers/importants, nits, Synthèse ou Questions pour raccourcir.

**Format tradeoff** (vrai A/B) — par point :

- **Sujet**
- **Ce que fait la PR**
- **Option A** / **Option B** : chacune + **effet** (user, ledger, cron, dashboard, support). Option B peut être status quo / ne pas merger cette partie.
- **Si on ship sans trancher**
- **Recommandation** (optional)

**Format confirmation** (ex-questions auteur, pas deux impls détaillées) — par point :

- **Sujet**
- **Ce que fait la PR**
- **Ce qui est ambigu** : lecture alternative possible
- **Si on ship sans trancher**
- **Ce qu’il faut décider** : confirmer / revert partiel / aligner sur règle X

Pas de faux Option B ; utiliser **format confirmation** quand il n’y a pas deux designs crédibles mais l’intention doit être validée.

Phase 2 « Always ask before applying » : chaque puce **pertinente pour cette PR** → son propre numéro (tradeoff ou confirmation).

### Questions pour l'auteur
Infos **externes** au diff (ticket, flag prod, calendrier). **Aucun** choix de comportement — ceux-là sont des Points à trancher.

### Synthèse
3–5 bullets : verdict, must-fix, rappel du **nombre** de points à trancher (pas leur fusion en une phrase).

Cap ~12 for blockers + importants + nits only. Points à trancher : hors cap.
Digest for the user (parent agent — do not summarize away):
Verdict + blockers/importants (titles unless full review requested)
Tous les #### 1. … #### N. sous ### Points à trancher (N) — copie intégrale, formats tradeoff ou confirmation
Nits recommandés en 4 lignes ; autres en « Nits optionnels » une ligne
Questions externes Do not apply yet if the user only asked for a review.

Phase 2 — Apply¶

If the user asked to take the review into account (or says « applique » after the digest):

Apply without asking¶

Clear bugs / broken wiring
Missing guards that the lib should own (e.g. negative money inputs)
Dead fields / unused params introduced by the PR
Exit codes / logging that hide failures
Unit tests that lock the reviewed behavior
Pure renames that match existing naming rules
Nits whose Correction is unambiguous and does not change behavior

Always ask before applying¶

Use every numbered point from Phase 1. Also ask before:

Product / ops semantics (floor per row vs per aggregate, allowlist policy)
Tradeoffs that change who gets leftover cents over time (tie-break rotation vs stable bias)
Scope expansion (rewrite another module “while we’re here”)
Metric definition changes that alter dashboards/ops reading
Anything where two reasonable suggestions conflict

When asking: reuse Option A/B or Ce qu’il faut décider from the review; add recommendation if missing.

After applies¶

Run the focused tests / tsc / biome for touched packages
Commit + push on the PR branch (follow repo git rules / user approval norms for the session)
Reply with: what landed, what stayed open, links to commits

Anti-patterns¶

Do not silently pick a product option “to move forward”
Do not re-run a full Opus review after a small apply pass unless asked
Do not expand into unrelated refactors from nits
Do not use a weaker model for Phase 1 when the user asked for Opus 5.5
Do not write nits without Constat + Pourquoi le signaler
Do not write points à trancher as bare « est-ce voulu? » without Ce que fait la PR + Si on ship sans trancher
Do not drop or merge judgment doubts to keep a single point à trancher
Do not use « move to Blockers or drop » for gray product areas — use format confirmation
Do not collapse the digest to one point while the subagent listed N ≥ 2