SnagBadgerA little help for every snag.
DocsView Markdown source ↗

name: merge-pr-mr-pull-request description: Review and merge authorized SnagBadger PRs against bot findings, static verification, and accepted requirements; reconcile roadmap progress and report newly unblocked tickets with starter prompts. Also inspect ticket dependencies without merging.#

SnagBadger PR merge and handoff#

Use gh for CosticaPuntaru/SnagBadger. Read repository AGENTS.md, docs/agents/issue-tracker.md, docs/agents/afk-implementation.md, and relevant foundation/domain documents from the current base. Apply the repository's full verification and recorded human-acceptance requirements. Register worked-on PRs with T3 thread linking when available.

The output is a checked merge decision and, after a successful merge, a verified completion/dependency report with copyable prompts. Inspection requests stay read-only. A request to merge a named PR authorizes that merge if the gates pass; creating this skill or inspecting readiness does not authorize a merge. Merge only the requested PRs, never newly unblocked PRs automatically.

Inspect dependencies#

For a named ticket, read dependency reporting and show both its blockers and the tickets it blocks, using title links. Retain native edges: closing a completed blocker satisfies it; remaining open blockers still gate its dependents. A ticket being unblocked is distinct from being unclaimed, specified, implemented, or ready to merge.

Verify a PR#

  1. Read the PR's current head/base OIDs, diff, closing-issue links, comments, reviews, review threads, checks, draft status, and mergeability. Fetch current base/head into an isolated checkout when verification is needed. Read every delivered ticket, its accepted decision/spec/PRD, and native blockers. Include accepted requirement changes recorded in comments. Resolve scope from repository evidence; ask only when the intended requirement is genuinely ambiguous.
  2. Build an acceptance table: requirement, code/diff evidence, test or browser evidence, head OID, and pass/fail/missing. Check standards and architecture against the repo instructions as well as product behavior against accepted requirements. A bot review or green static checks alone cannot establish product acceptance. If no separate PRD exists, the accepted ticket/spec/decision is the requirements source; say which one was used.
  3. Check current bot findings, including line comments, unresolved review threads, and summary findings. Verify claimed fixes in the final diff and relevant checks; distinguish superseded findings from unresolved ones. Treat actionable correctness/acceptance findings and unaddressed change-request reviews as blockers. Lack of a bot review is unknown evidence, not a passing bot verdict. Perform the corresponding code review yourself when no bot exists, and report that substitution. Explain any nonblocking findings left open.
  4. Require the repository's complete verification on the final source plus relevant acceptance checks and required browser observations. Use recorded evidence only when it identifies the unchanged head and proves the required checks; otherwise reproduce it. Run static tools configured by the repository, not an invented substitute gate. Read docs/contributing/github-checks.md when present: its hosted SnagBadger quality gate must succeed for the current PR revision even while plan restrictions prevent branch protection. Missing, failed, pending, skipped, or cancelled required checks/reviews remain merge blockers; local verification cannot substitute for a declared hosted gate. Where hosted CI has not yet been introduced, report that absence and apply the repository's documented local policy explicitly. Linux/browser/T3 acceptance requirements remain gates when the ticket requires them.
  5. Reconcile prerequisites against the actual target base. All decision blockers require their accepted resolution. Merge dependent implementation layers bottom-up; every prerequisite must be closed and its implementation present in the merge target before the dependent merges. A verified stack handoff permits development, not bypassing the final merge gate. A PR with incomplete delivered criteria stays open, even if GitHub reports MERGEABLE.
  6. For an authorized merge, fix routine merge conflicts and in-scope check failures rather than stopping at a readiness report. Fetch the current target base, reconcile it into the PR branch, and preserve both branches' accepted behavior and registrations. Commit and push the resolution, then renew full verification, acceptance review, T3 observations, inline screenshots and hosted PR checks for the resulting head. Continue through the authorized merge once every gate passes; existing merge authorization persists through these repairs. Ask only when resolution requires a new product decision, overriding an accepted constraint, or destructive changes to unrelated work. Inspection-only requests remain read-only.
  7. Report separate verdicts for host checks/reviews, bot/static/code review, requirements/acceptance, and dependencies. Merge only when each required gate passes. For blockers that cannot be resolved within the authorized scope, give concrete findings, missing evidence, and the smallest resume step; preserve open tickets and unchecked roadmap items. Significant fixes or base/head changes require renewed verification rather than merging the previously reviewed revision.

Merge and reconcile#

For every AI-authored or AI-assisted PR, apply docs/agents/reliability.md#screenshot-evidence-in-ai-prs. Before a review-ready or merge handoff, require inline GitHub-hosted screenshots in the PR description, the current verified head OID, scenario/actions and expected/observed captions. Compare them with the source-bound T3 evidence and direct checks; a screenshot alone does not prove acceptance. Upload observed screenshots with a supported gh --attach, preserve existing body text, and read back the rewritten URLs. Missing, local-only or stale screenshot proof is a handoff blocker. Keep drafts explicit about the missing evidence.

  1. Identify only the tickets fully delivered by this PR. Put closing keywords for those tickets in its body, preserving concurrent edits; use reference links for partial work and map/backlog parents. Human decision tickets require already-recorded acceptance and a resolution comment. Identify affected maps through native parents, ticket context, and roadmap links.
  2. Before mutation, save a dependency snapshot for the delivered tickets using dependency reporting. Immediately re-read the head/base, mergeability, required checks/reviews, and blocker state. Follow the current-plan merge procedure in docs/contributing/github-checks.md: inspect the named aggregate and its successful Linux PR run for the verified head explicitly, even when GitHub declares no checks required. Native Windows smoke is optional; if explicitly requested for this change, verify its passing manual-dispatch run on the same head as additional evidence. Require the current target base in the branch. If the base or head differs from the verified revision, rerun affected verification and review. A draft must be explicitly ready and all gates pass before marking ready. Report whether protection is server-enforced or this is agent-enforced policy; keep this repository private on its current plan as the user requested.
  3. Merge into the repository's default branch using the allowed repository merge method and gh pr merge ... --match-head-commit <verified-head-oid>. Honor branch protection without admin bypass or force. Stop on an actionable merge rejection; do not queue an unverified merge or loop retries. If the outcome is uncertain, query PR state before attempting another merge. A non-default-base stack merge is reported separately and does not imply default-branch delivery or closure.
  4. Verify the merged state and merge commit. Read each delivered ticket back: let GitHub closing links close it, or post its completion evidence and close it explicitly if the link was missing. Never close a parent or partially delivered ticket merely because the PR merged. Preserve native dependency edges. Reconcile maps per the tracker policy: tick completed progress, add newly identified follow-ups, and link decision resolutions. Re-read maps before edits and verify changes afterward.
  5. Compare dependency snapshots after verified closures. Report newly unblocked tickets, still-blocked tickets with remaining blockers, already-unblocked dependents, and closed dependents separately. Re-fetch live state before offering prompts. Treat API errors or concurrent changes as uncertainty rather than reporting invented readiness. If merge succeeded but tracker reconciliation failed, say the merge succeeded and list the failed follow-up operations; resume those without re-merging.
  6. Finish with the PR/merge commit, delivered ticket links, roadmap updates, verification summary, dependency report, and copyable starter prompts. Do not launch agents, claim downstream work, or merge downstream PRs from this report. Verify T3 PR-thread registration before finishing.

Starter prompts#

Give one snippet per newly unblocked, open, unassigned ticket suitable to start now. Show claimed or underspecified tickets in the report without inviting a competing claim. Use the actual ticket URL, current accepted base/merge commit, and affected map; preserve the ticket's own boundaries.

Implementation example:

Implement <title> (<ticket URL>) in SnagBadger. Read AGENTS.md and its referenced issue-tracker, foundation, and AFK workflow. Start an isolated worktree from current origin/main, verify prerequisite implementations including <merge commit>, and re-check live blockers and assignment before claiming. Deliver only this ticket's acceptance criteria, run the full required verification, and open a reviewable PR with completion evidence and Closes #<ticket number>. Keep the roadmap progress current. Do not merge, release, or deploy.

Decision/prototype example:

Use $mattpocock-skills:wayfinder to work through <title> (<ticket URL>) under <map title> (<map URL>). Read repository instructions, re-check live blockers/assignment, and claim before work. Use the ticket's labelled workflow and accepted constraints; interview me directly where human decisions are required. Resolve only this decision, record its answer, and update the roadmap progress and resolution pointer. Do not implement unrelated work or merge/release/deploy.

For an existing dependent PR, give a review/merge prompt instead only when the user asks for it. Its fresh checks, specification review, accepted evidence, dependency state, and explicit merge authorization are still required.