Development workflowFlagship

/fix-this

Finalize one reviewed pull request: apply the findings, verify locally, merge, and close out the ticket.

A published review still needs someone to apply it. This skill consumes the validated review handoff, applies every blocking and advisory finding, resolves supported conflicts, verifies locally, squash-merges, and completes ticket bookkeeping.

SKILL.md on GitHub

At a glance

Start with: One pull request with a published review carrying a valid handoff, named by its pull-request number or same-repository URL.
You decide: You choose the single pull request to finalize; issue numbers never resolve here, and ambiguous or stale handoffs stop before any change.
You receive: A squash-merged pull request with updated evidence, a closed implementation ticket, promoted eligible dependents, and an explicit record of any incomplete bookkeeping.

Is this the right skill?

Use it when

A pull request has a published review with a valid handoff and needs its findings applied
Merge conflicts need a supported resolution inside the reviewed scope
The ticket, dependents, and parent need closing after a confirmed merge

Use something else when

No valid review handoff exists yet — run review-this first
You want a new review verdict or a CI-gated merge — this skill never generates another verdict or waits on CI

What the workflow looks like

What you start with: One pull request with a published review carrying a valid handoff, named by its pull-request number or same-repository URL.
What the skill does: It validates the handoff against current requirements and policy, applies all findings, merges the current base when needed, runs mandatory local verification, updates evidence, squash-merges with the verified head, and closes out the ticket and eligible dependents.
Where you make or approve decisions: You choose the single pull request to finalize; issue numbers never resolve here, and ambiguous or stale handoffs stop before any change.
GitHub branch protection stays authoritative: a rejected merge is reported as a restriction, never overridden.
What you receive: A squash-merged pull request with updated evidence, a closed implementation ticket, promoted eligible dependents, and an explicit record of any incomplete bookkeeping.

Step-by-step workflow

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

01
Resolve and validate
Parse exactly one pull-request reference and validate the latest review handoff against current requirements and policy.
02
Apply every finding
Address blocking and advisory findings, resolve supported conflicts, and record each disposition with its verification.
03
Verify locally
Run the ticket's focused checks plus the repository's local verification on the resulting head.
04
Merge and close out
Squash-merge with the verified head, confirm the merge, then close the ticket and promote eligible dependents.

Worked example

Illustrative scenario

Not a measured outcome — shows the finalize contract.

The hub pull request has a published review with a valid handoff. You run /fix-this on the pull request number from the reviewed checkout. It applies every finding, runs local verification, squash-merges with the verified head, closes the ticket, and promotes the next eligible dependent.

Install and invoke

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

Install — npx (recommended)

npx skills add RuralNative/RuralNative-SKILLS --skill unslopify

npx skills add RuralNative/RuralNative-SKILLS --skill review-this

npx skills add RuralNative/RuralNative-SKILLS --skill fix-this

Invoke

/fix-this #<pr>

/fix-this <pr-url>

Requires

Node 24 or newer for the bundled evidence and progress checks plus the merge transport
One open non-draft pull request against the pinned default branch, or a merged one resuming bookkeeping through a reconciled checkpoint

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

Applied findings with per-finding dispositions and verification receipts
Updated implementation evidence validated as current on the resulting head
Squash merge with confirmed merge receipt, ticket closure, and dependent and parent promotion
A compact progress checkpoint resumed across interruptions without repeating verified work

Controls

One pull request per invocation; never force-pushes, rebases published history, or bypasses branch protection
No new review verdict, no CI wait or CI merge gate, no automatic next ticket
Changed requirements or policy stop; old findings are never trusted for unknown work
A merged pull request with unfinished labels or closure is reported as merged with bookkeeping incomplete

Evidence — linkable today

SKILL.md for handoff validation, verification, merge, and bookkeeping contracts
INSTALL.md for the shared review-handoff contract with review-this
Repository tests for target resolution, handoff validation, and progress reconciliation

Limits — not claimed

Does not plan, implement fresh tickets, or review code
Never clears needs-info or other unresolved human decisions to authorize delivery
Closed-unmerged pull requests never count as delivered
Kilo Code is the documented verified reference; other hosts carry unverified live behavior

/review-this

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

/document-for-agents

Give coding agents a current map of where work belongs and why.

Next step: open the manual if you are about to install or copy a command for production use.

SKILL.md Back to field guide