| name | minos-pr-feedback |
| description | When the user has reviewer feedback on a GitHub PR (human or bot like gemini-code-assist) and wants the pertinent items fixed — "j'ai des retours sur la PR", "résous/corrige ce qui est pertinent", "lis les commentaires de la PR via gh" — triage every comment thread via gh, apply only the pertinent fixes (drop nits), then reply to and resolve each triaged thread. Not for publishing our own review findings — that is argus-review --post. |
minos-pr-feedback — triage and fix reviewer comments on a PR
Minos, judge of the dead, who weighs each soul and pronounces its fate. This skill weighs each reviewer comment — apply or dismiss — and acts only on those that earn it.
A reviewer (human or a bot like gemini-code-assist) left comments on the PR. Fetch them, triage by relevance, and apply only the pertinent fixes — drop nits. The genuinely uncovered workflow: existing review skills review your diff, they don't consume others' comments. This is the step the user otherwise does by hand on nearly every PR.
When to use
- "j'ai des retours sur la PR N", "résous/corrige ce qui est pertinent", "les plus pertinents à corriger"
- "retours de gemini-code-assist, qu'en penses-tu ?", "lis les commentaires de la PR via gh"
When NOT to use
- Generating a review of a diff → that is
argus-review / pr-review-orchestrator. This skill consumes existing comments; it does not fan out reviewers.
- Posting our own findings to a PR → that is
argus-review --post. This skill only posts one-line closure replies on triaged threads, never new review findings.
- Replying to a reviewer in prose without changing code → just answer; no skill needed.
- A single obvious comment the user already pasted inline → just fix it.
Resolve the target PR
Never ask the user for the PR number when it is derivable.
OWNER_REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
PR=$(gh pr view --json number -q .number)
- An explicit number in the prompt always wins (even a fuzzy "PR 67 j'imagine" — verify it matches the branch, correct it if not).
- No PR for the branch → tell the user. Never invent a number.
Procedure
Full gh commands and the triage rubric: references/procedure.md. Essentials:
- Resolve the PR (above).
- Fetch all three comment sources — comments live in three different GitHub APIs; fetching only one misses feedback:
- inline review comments (
/pulls/{PR}/comments),
- review summaries + state (
/pulls/{PR}/reviews),
- top-level conversation comments (
/issues/{PR}/comments).
- Drop noise — skip comments on resolved threads,
outdated/superseded lines, and the user's own. Bots (gemini-code-assist, coderabbitai, …) post a verbose summary + many inline nits — judge each on merits, not by volume.
- Triage each surviving comment into
apply / ask / skip-nit / skip-wrong, each with a one-line reason (rubric in procedure.md). Consult references/rejected-patterns.md first — recurring comment classes carry a default verdict; append new recurring classes after the run. Default: only apply the genuinely pertinent; nits are skipped unless the user said otherwise.
- Present the triage table first (comment → verdict → reason), then apply the
apply set as real code changes — grouped, smallest diff, reusing existing project patterns.
- Check regressions on changed symbols (per the user's workflow) and run typecheck/lint on touched files.
- Commit + push the applied fixes — stage only the files minos touched, commit with a conventional message, and push to the PR's head branch so the PR updates. Only after checks pass; skip entirely if nothing was applied or if a check failed. See
references/procedure.md §6.
- Reply to every triaged thread, resolve the settled ones (default) — after the push, post a one-line factual reply on each inline thread ("Fixed in ." / "Skipped: nit — ." / "Not applied: .") then resolve it via GraphQL.
ask threads get an "Awaiting decision: " reply but stay unresolved — an open thread with a minos reply means "your call", an open thread without one means "not triaged". Opt out with --no-resolve / "ne résous pas les threads" — and any explicit caller instruction forbidding replies (e.g. an orchestrator ticket saying "ne poste aucun commentaire") counts as opt-out: use the caller's closing mechanism instead. See references/procedure.md §7.
- Report: what was applied (file:line), open
ask questions, what was skipped and why (nit / out-of-scope / wrong), counts including resolved threads, and the pushed commit sha.
Gotchas
- Three comment APIs, not one. Inline comments, review summaries, and conversation comments are separate endpoints. "J'ai des retours" can land in any of them — fetch all three or miss feedback.
- PR# is derivable — never ask. Resolve from the branch; the user routinely doesn't know it ("67 j'imagine"). Verify a user-given number against the branch.
- Bots are nitty.
gemini-code-assist / coderabbitai mix a few real findings into many nits and style preferences. Triage on merits; the user wants "ce qui est pertinent", not all of it.
- Skip resolved/outdated threads. Re-fixing a resolved comment is noise. Thread resolution is GraphQL-only (
reviewThreads.isResolved) — the REST inline endpoint does not expose it, so the GraphQL query in procedure.md §2 is mandatory, not optional. Outdated = position: null/isOutdated.
- No silent open threads. Every triaged inline thread must end the run with a minos reply — including
ask threads (replied, left unresolved). A thread left open with no reply is indistinguishable from an untriaged one, which defeats the "global view" the resolution step exists for.
- Orchestrated runs may forbid replies — the caller wins. Kanban/pipeline tickets that invoke minos often say "ne poste AUCUN nouveau commentaire; seule la minimisation est autorisée". That explicit instruction overrides the reply+resolve default: close threads with the caller's mechanism (e.g. GraphQL
minimizeComment) and put the per-thread verdicts in the run report instead.
- Close threads, don't publish findings. Minos replies one factual line per triaged inline thread and resolves it — that is thread hygiene, not a review. Publishing our own review findings on a PR remains
argus-review --post. Resolve AFTER the push (the reply cites the commit sha); only inline review threads are resolvable — review summaries and issue comments have no resolve concept, leave them alone.
- Apply respects project conventions. Fixes are real code — reuse existing components/patterns, no
as casts, minimal diff, check regressions (same standards as any code change).
- Hedged behavioral findings + no PR description =
ask, never auto-fix. A "consider gating…"-style warning that changes runtime behavior is a design question; with an empty PR body there is no intent to validate it against. Verify any claimed regression against the pre-PR version of the exact call site before applying — an invariant cited from a sibling code path may never have applied to the changed one (fftir #327: auto-applied, rolled back as slop).
- Heavy commit hooks ≠ stuck commit — never
--no-verify. Some repos (e.g. fftir-thot's lefthook) run pnpm i --frozen-lockfile + full-monorepo turbo lint/format/check-types on pre-commit: several minutes, longer than the default 2-min Bash timeout. Run git commit with timeout: 600000 (or run_in_background) and wait. Do NOT kill lefthook/turbo processes, do NOT fall back to --no-verify (it also skips commitlint and transcrypt). If the hook genuinely fails, report the failure instead.
- Commit only the files minos touched, push only on the PR's head branch. Never
git add -A (the working tree may hold unrelated changes); never push a broken tree (checks gate the commit) or a branch that isn't the PR head (flag instead). Risky fixes still get flagged in the report even though they're pushed.
