Factory Rereview
Re-review a pull request after a push, reconcile the previous review against the new...
Install
npx skills add mastra-ai/mastra --skill factory-rereview -g -a claude-code -y- Repository
- mastra-ai/mastra29.3k
- Category
- Git and review
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Re-review a pull request after a push, reconcile the previous review against the new commits, look for new defects the push introduced, then a fresh pass over the whole PR, and finish with a verdict on the PR
Factory Re-Review
Role guard: only run this skill when the factory-phase signal shows role="review". Under any other role, stop immediately: do not review, comment, label, approve, or transition the work item, and report that review skills are not available to this role.
Re-review the pull request behind this Factory work item after new commits were pushed, reconcile your previous review against what changed, look for defects the push itself introduced, then take a fresh pass over the PR as it now stands, and finish by publishing the verdict on the PR, recording the verdict on the card, and posting a verdict handoff.
You are working in a bound Factory session. Complete the full re-review in one pass, then make factory_record_review_verdict your terminal step, one call, repeated only if it is rejected and only with the rejection reason addressed. Never wait for or solicit human input mid-run; every judgment call is yours to resolve.
Decision rule: at every fork, did the push actually address a prior finding, is a new pattern deviation deliberate, is the incremental scope creep, pick the answer the history and codebase conventions best support, proceed, and record the decision as an assumption for the terminal handoff. Requested changes and decisions a human must make go in the handoff's open questions.
Assumptions are for interpretive calls only, was a prior finding meaningfully addressed, is a loose new assertion justified. A confirmed finding may never be resolved by recording an assumption: if you verified a defect (prior or new), it stays a finding and weighs into the verdict; writing "treated as non-blocking" next to it does not make it non-blocking.
Shell note: gh output often contains ANSI color codes that break jq. Use gh's built-in --jq flag instead of piping to jq, or prefix commands with NO_COLOR=1.

