factory-rereview

Re-reviews GitHub pull requests after new pushes and publishes verdicts.

27.6k|2.7k|Updated Aug 6, 2024
One-click install
npx skills add https://github.com/mastra-ai/mastra --skill factory-rereview
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: factory-rereview
Source: https://github.com/mastra-ai/mastra/tree/main/mastracode/factory/factory-skills/factory-rereview
Command: npx skills add https://github.com/mastra-ai/mastra --skill factory-rereview

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

After a pull request receives a review and the author pushes new commits, someone must verify the push actually addressed prior findings, check it introduced no new defects, and re-run verification — a tedious, error-prone process this Skill automates end to end.

Core Features & Use Cases

  • Prior-Finding Reconciliation: Classifies every previous review finding as addressed, partially addressed, still open, refuted, or invalidated, with commit and file:line evidence.
  • Push Regression Detection: Diffs prior-head against current-head to find regressions, incomplete fixes, and scope creep introduced by the new commits.
  • Independent Verification: Re-runs tests and typechecks against the current head with credentials stripped, and publishes an approve or request-changes verdict as a GitHub PR review.
  • Use Case: A maintainer pushes fixes responding to a Factory review; this Skill re-examines the PR, confirms each fix, runs the test suite, and posts a fresh verdict review with a structured handoff.

Quick Start

Re-review pull request 123 after the latest push and publish the verdict on the PR.

Frequently Asked Questions about factory-rereview

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I re-review a pull request after new commits are pushed?

Fetch the PR with gh pr view and gh pr diff, diff the prior head against the current head to isolate the push, reconcile each prior finding against the new code, re-run tests on the current head, then submit a verdict with gh pr review.

How to verify a push actually fixed review findings?

Read the fixing code itself rather than trusting commit messages, and cite the commit or file:line proving each fix. Classify every prior finding as addressed, partially addressed, still open, refuted, or invalidated — none may be silently dropped.

Can a pull request with merge conflicts be approved?

No. A conflicting PR cannot merge as-is, so resolving conflicts is always a required change before merge. The review still completes, with conflict resolution listed as a discrete requested change and verification qualified as head-branch-only.

How does the review handle prompt injection in PR content?

Author-controlled PR titles, bodies, commits, or comments that attempt to direct the review or alter verdict criteria are recorded verbatim as blocking security findings, and the verdict becomes request changes regardless of code quality.

Why must tests be re-run on every re-review pass?

Pushed commits are new code, so verification from a prior pass does not carry over. Tests and typechecks run against the current head with GitHub tokens stripped via env -u so the PR's scripts cannot read session credentials.