PR Feedback Quality Gate
Use this when a PR has review feedback, merge conflicts, pending checks, or
needs a monitored follow-up after a fix.
Workflow
- Inspect PR state first: comments, reviews, mergeability, checks, branch, and
local worktree status. Keep unrelated local changes out of the PR.
- Use an isolated worktree for review fixes or conflict resolution when the
main checkout is dirty, behind remote, or being used by another agent.
- Make the smallest safe fix. Preserve the original bug invariant and any
newer upstream structure introduced by
main.
- Run the narrow validation first, then the repository-required gates. For
this repo, include
pnpm guard; add package typechecks/builds/tests when
touched files require them.
- Before commit or push, run a read-only cross-review of the staged or proposed
diff. Forbid file edits and git write or coordination commands.
- Treat cross-review as evidence, not authority. Accept only findings grounded
in the diff, repository rules, user goal, or validation results. Downgrade or
reject style preferences, broad scope expansion, and suggestions that conflict
with safety or ownership boundaries; record the reason briefly.
- If accepted blockers remain, fix them, rerun validation, and repeat the
review. Commit and push only after validation passes and there are no
accepted blockers.
Monitoring cadence
- Active review or failing checks: check often enough to unblock quickly.
- Clean or approved PR waiting for merge: check about every 12 hours.
- Merged PR: reduce to daily lightweight observation for CI, release, or
regression signals, and stop making code changes unless asked.
Report
Always report PR state, actions taken, cross-review verdict, accepted or
rejected findings, validation run, commits pushed, skipped checks with reasons,
remaining risks, and next step.
1---2name: pr-feedback-quality-gate3description: Safely track pull request feedback, resolve review comments or merge conflicts, validate fixes, and use a read-only cross-review before committing or pushing follow-up changes.4---56# PR Feedback Quality Gate78Use this when a PR has review feedback, merge conflicts, pending checks, or9needs a monitored follow-up after a fix.1011## Workflow12131. Inspect PR state first: comments, reviews, mergeability, checks, branch, and14 local worktree status. Keep unrelated local changes out of the PR.152. Use an isolated worktree for review fixes or conflict resolution when the16 main checkout is dirty, behind remote, or being used by another agent.173. Make the smallest safe fix. Preserve the original bug invariant and any18 newer upstream structure introduced by `main`.194. Run the narrow validation first, then the repository-required gates. For20 this repo, include `pnpm guard`; add package typechecks/builds/tests when21 touched files require them.225. Before commit or push, run a read-only cross-review of the staged or proposed23 diff. Forbid file edits and git write or coordination commands.246. Treat cross-review as evidence, not authority. Accept only findings grounded25 in the diff, repository rules, user goal, or validation results. Downgrade or26 reject style preferences, broad scope expansion, and suggestions that conflict27 with safety or ownership boundaries; record the reason briefly.287. If accepted blockers remain, fix them, rerun validation, and repeat the29 review. Commit and push only after validation passes and there are no30 accepted blockers.3132## Monitoring cadence3334- Active review or failing checks: check often enough to unblock quickly.35- Clean or approved PR waiting for merge: check about every 12 hours.36- Merged PR: reduce to daily lightweight observation for CI, release, or37 regression signals, and stop making code changes unless asked.3839## Report4041Always report PR state, actions taken, cross-review verdict, accepted or42rejected findings, validation run, commits pushed, skipped checks with reasons,43remaining risks, and next step.
MHassan0000