akathecoder Triage PR Feedback
Given a GitHub pull request URL, evaluate every unresolved human or Copilot review finding against the diff, codebase, tests, and originating requirements. Independently establish whether the suggested issue is real before acting on it. Classify each finding as important, maybe, or rejected; fix only important and maybe findings. Treat resolved threads as prior decisions and leave them untouched.
Leave all code changes uncommitted and do not push.
Resolve every .agents/projects/ path from the repository root; never read or write
project artifacts in a global agent-installation directory.
Process
Identify the active project and read its context, links, spec, ticket references, and relevant ADRs. Fetch the pull request, its diff, review summaries, inline review threads, existing replies, and current thread-resolution state through available GitHub tooling. Include only findings authored by a human reviewer or GitHub Copilot. Exclude GitHub Actions, check runs, workflow output, and automated reports, including Sonar, Snyk, and OX.
Ignore every resolved thread. Done when every unresolved eligible review finding is listed with its author, location or review source, and existing discussion; no GitHub Actions or automated report finding is included.
Evaluate each finding independently. Reproduce or trace its claimed behavior through the diff, affected code, tests, and originating requirements; use the smallest focused check that can confirm or disprove it. Do not rely on the review author's confidence, status, or reasoning as proof. Classify the result as:
- Important: a confirmed correctness, security, data-loss, or material behavioral issue that requires a change before merge.
- Maybe: a supported maintainability, testing, or lower-risk issue where the proposed change is proportionate and safe to make now.
- Rejected: a false positive, irrelevant, already-addressed, duplicate, unsupported, or disproportionate finding.
Done when every finding has an evidence-based classification, including the specific code, test, requirement, or focused check that supports it.
For important and maybe findings only, make the smallest correct fix using
tddat the established seam where appropriate. Make no code change for rejected findings. Follow the main implementation quality bar: run focused tests and typechecking regularly, the full relevant test suite at the end, and the repository's coverage tooling for changed code. Target 100% changed-code coverage and require at least 95%, unless the user or repository explicitly opts out. Invokecode-reviewfor the aggregate fixes, address confirmed findings, and rerun affected verification before replying to review threads. Do not commit or push any change. If an important or maybe finding cannot be fixed safely without a decision from the user, explain the blocker and leave its thread unresolved for the user.Done when each important or maybe finding is fixed, meets the main-flow test and coverage bar, and passes final code review; each rejected finding has no code change; and each genuinely blocked important or maybe finding is explicitly left for user action.
Reply at the finding's native GitHub review surface. State its classification. For an important or maybe finding, state the concise fix and verification performed. For a rejected finding, state the evidence-based reason and that no code change was made. End every GitHub reply with the exact line:
Written by CursorResolve the thread after posting an important, maybe, or rejected response. A review summary without a resolvable inline thread receives a reply on the closest available review or pull-request discussion surface; record that no thread-resolution operation was available.
Done when every decided finding has its reply and is resolved where GitHub supports resolution.
Write
.agents/projects/<project>/pr-feedback.mdwith each finding, its eligible review source, classification, evidence, fix and verification where applicable, reply URL, and resolution state. Update project context and links with the PR URL and remaining blocked feedback. Summarize the uncommitted changes and any unresolved blockers to the user.Done when project artifacts and the final report account for every review finding and the working tree remains uncommitted and unpushed.