John Berlin Leonor
Development workflowFlagship

/review-this

Review exactly one pull request and publish the findings with a handoff for fix-this.

A pull request can look done while missing the agreed checks. This skill resolves exactly one pull request, runs one local Standards-plus-Spec pass, publishes the review with a validated handoff, and stops.

SKILL.md on GitHub
At a glance
Start with
One open pull request with a native closing reference to its ticket, current head and base revisions, and implementation evidence.
You decide
You choose the single target; parent specs, ambiguous mappings, and multiple targets stop before any write.
You receive
A published review with verified inline findings and one validated handoff that fix-this consumes. Nothing is fixed or merged here.

Is this the right skill?

Use it when
  • A ticket has an open pull request with a ticket link and test proof
  • You want one local review for project rules and one for the agreed requirements
  • You need the findings published so fix-this can finalize them
Use something else when
  • The pull request has no ticket link or the plan changed since the work started — it will stop and ask for the missing piece
  • The pull request comes from an untrusted fork — it runs a read-only review with no push or merge

What the workflow looks like

What you start with
One open pull request with a native closing reference to its ticket, current head and base revisions, and implementation evidence.
What the skill does
It aligns a clean checkout to the pull-request head, resolves governing policy from the pinned base, reports Standards and Spec separately, and publishes the review plus one validated handoff block for fix-this.
Where you make or approve decisions
  • You choose the single target; parent specs, ambiguous mappings, and multiple targets stop before any write.
  • You see which findings block finalization and which are advisory, with each blocking claim tied to a rule, criterion, or reproduced failure.
What you receive
A published review with verified inline findings and one validated handoff that fix-this consumes. Nothing is fixed or merged here.

Step-by-step workflow

Follow the steps in order. Each step ends at a point you can pause and check.

  1. 01
    Resolve the target
    Accept exactly one open pull request, or one issue resolving to exactly one, and pin head, base, and requirements revisions.
  2. 02
    Prepare the checkout
    Preserve local work in a verified snapshot, then align a clean checkout to the pinned head commit.
  3. 03
    Review in one pass
    Run one Standards-plus-Spec pass on the pinned revisions and validate every finding.
  4. 04
    Publish and stop
    Publish the pinned review with its validated handoff, then direct finalization to fix-this.

Worked example

Illustrative scenario
Not a measured outcome — shows the single-PR contract.
A pull request for the hub page is open with a ticket link and test proof. You run /review-this on the pull request from the matching checkout. It pins head, base, and requirements revisions, runs one Standards-plus-Spec pass, and publishes the review with a validated handoff. You then run /fix-this on that pull request to apply the findings.

Install and invoke

Install the prerequisites first, then this skill. Skill downloads never happen from issue text.

  1. 1unslopify — active for prose
  2. 2/review-this
Install — npx (recommended)
npx skills add RuralNative/RuralNative-SKILLS --skill unslopify
npx skills add RuralNative/RuralNative-SKILLS --skill review-this
Invoke
/review-this #<pr>
/review-this <pr-url>
Requires
  • Node 24 or newer for the bounded preparation and publication helpers plus read-only checks
  • One open pull request against the pinned default branch with a native closing link and evidence

Kilo Code is the documented verified reference. Other hosts use native invocation with unchanged stages, but live host checks are not verified; on OpenCode, supply the target outside slash-command arguments.

Technical safeguards and limits

Reference detail. The workflow above is enough to start; read on when you need exact controls and proof.

Outputs
  • Published review with Standards and Spec checklists pinned to head, base, and requirements revision
  • One validated review-handoff block that fix-this consumes
  • Reuse of the published review by a later run when every key is unchanged
Controls
  • One pull request per invocation; parent specs and ambiguous targets stop before any write
  • No cloud review, workers, worktrees, or Agent Manager state
  • Optional REVIEW.md supplies extra project rules without relaxing safety boundaries; policy resolves from the pinned base
  • Severity cites an invariant, policy line, acceptance criterion, or observed failure — otherwise advisory
Evidence — linkable today
  • SKILL.md for single-target, publication-only, and handoff contracts
  • INSTALL.md for preparation, recovery, and install-check behavior
  • Repository tests for target resolution and review composition
Limits — not claimed
  • Never applies source fixes, commits, pushes, merges, updates labels, promotes dependents, or closes tickets
  • The only pull-request body write is the scoped evidence-repair helper replacing one validated region with provenance
  • A changed issue body that breaks the pinned revision stops review with needs-info until reconciled
  • Pending CI publishes the pinned review and stops; a later run reuses it when every key is unchanged
  • Kilo Code is the documented verified reference; other hosts carry unverified live behavior
Previous
/implement-this
Implement exactly one ticket in the current checkout and deliver one pull request.
Next
/fix-this
Finalize one reviewed pull request: apply the findings, verify locally, merge, and close out the ticket.
Next step: open the manual if you are about to install or copy a command for production use.
SKILL.md Back to field guide