github-pr-review: add a follow-up phase so the reviewer answers replies in threads it opened

Aperta
  • Qualcosa non va?
#21 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
github, shell
Ambito
devtools, documentation

Direzione di ricerca

Start with github-pr-review/SKILL.md and trace its documented phases through Submit; the acceptance criteria name the required Phase 6 behavior and reply endpoint. Check the engine dependency, rossoctl/automation#135, and scripts/vendor-engine.sh before changing the vendored scanner and fixer. Done means the skill documents follow-up replies and the never-resolve rule, the vendored bundle matches the supporting release, and the workflow answers each author reply once without re-reviewing unchanged code.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

github-pr-review/SKILL.md describes a strictly one-shot pipeline — Phase 1 Gather, Phase 2 Analyze, Phase 3 Checklist, Phase 4 Draft, Phase 5 Submit — and stops at "post the review". There is no phase for the conversation that follows, so even with a capable engine the documented workflow tells the agent its job ends at submit. Today the bot answers replies to its inline comments only if a human explicitly asks it to in Slack.

Context: llm-d-incubation/llm-d-fast-model-actuation#828, where the bot opened two inline comments, the author replied to both two days later, and the bot stayed silent until prompted in Slack. Team position in that channel: RepoMan should stay engaged in the comment threads it opens, generally, not just for one review.

Proposed change

  • Add a Phase 6: Follow-up conversation after Submit — detect author replies to bot-authored inline comments and answer them. Post via POST /repos/{owner}/{repo}/pulls/{pull_number}/comments/{comment_id}/replies.
  • State the guardrail in the skill: the agent may reply, but must never resolve threads. clawgenti is refused ResolveReviewThread by design — a human decides whether an agent's comment is resolved or even worth fixing. Where a thread looks settled, say so in a reply and leave the Resolve click to a human.
  • Reply quality bar: answer the specific point; concede plainly when the author is right; do not restate the original finding; no praise or filler; keep it to a short paragraph. A reply is not a review — do not stamp <!-- reviewed: <sha> --> on it, and do not re-review unchanged code.
  • Document the dedupe marker if the engine adopts one for replies (e.g. an invisible <!-- replied: <comment_id> -->), so a fresh machine does not answer the same reply twice.
  • Re-vendor the engine (scripts/vendor-engine.sh) once the engine change lands: the plugin ships the scanner/fixer scripts, so repoman's copy has to be refreshed for the skill to work as documented.
  • The standalone copy in rossoctl/agent-skills is already divergent (it lacks the footer line); resync is tracked by #5 — no separate change needed there.

Dependencies

  • Engine and state-machine work: rossoctl/automation#135. This issue covers the skill/workflow half and the vendoring step; it should not be closed until the bundle ships a working Phase 6.

Acceptance criteria

  • github-pr-review/SKILL.md documents the follow-up phase, the reply endpoint, the never-resolve rule, and the reply quality bar.
  • Vendored pr-review-scanner.sh / pr-review-fixer.sh in this repo match the automation release that implements the phase (_vendor.json SHA bumped).
  • A reviewer following the skill, given a PR where the author replied to an inline comment, answers it once and does not re-review unchanged code.
Lingua principale
Shell
Stelle
7
Fork
1
Merge medio
3g 23h
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rossoctl/repoman

Tutte le issue di rossoctl/repoman

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.