John Berlin Leonor
Development workflowFlagship

/implement-this

Implement exactly one ticket in the current checkout and deliver one pull request.

A ready ticket still needs a clean, focused checkout to avoid mixed-up changes. This skill validates the ticket, works in the checkout you chose, and opens one pull request with proof attached.

SKILL.md on GitHub
At a glance
Start with
One open ticket marked ready for agent work, with no blocking links left open.
You decide
You choose the one ticket to run; blocked, ambiguous, or unready work stops before any change.
You receive
One branch and pull request against the pinned default branch, with per-criterion proof and a closing reference for review-this.

Is this the right skill?

Use it when
  • A ticket is approved and marked ready, and needs one branch and pull request
  • You want the work done in the checkout you chose, without creating another worktree
  • You want focused test proof attached to the pull request before review
Use something else when
  • A ticket is still blocked or not marked ready for agent work
  • You need a merge — that step belongs to fix-this

What the workflow looks like

What you start with
One open ticket marked ready for agent work, with no blocking links left open.
What the skill does
It validates the ticket and its linked parent, pins the requirements revision and the repository default branch, creates or reuses the feature branch in this checkout, runs the work to completion, and opens or updates one pull request with compact evidence.
Where you make or approve decisions
  • You choose the one ticket to run; blocked, ambiguous, or unready work stops before any change.
  • You review the pull request; finalization and merge happen in fix-this, not here.
What you receive
One branch and pull request against the pinned default branch, with per-criterion proof and a closing reference for review-this.

Step-by-step workflow

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

  1. 01
    Validate the ticket
    Confirm the single ticket is ready and unblocked, and pin the requirements revision and default branch before any change.
  2. 02
    Build in this checkout
    Create or reuse the feature branch here and do the work in this checkout, never in another worktree.
  3. 03
    Prove with focused checks
    Run the ticket's smallest sufficient checks, with per-criterion proof and defect-specific RED evidence for bug fixes.
  4. 04
    Open the pull request
    Attach compact evidence with Closes #<ticket>, move the ticket to ready-for-human, then hand off to review-this.

Worked example

Illustrative scenario
Not a measured outcome — shows one ticket, one pull request.
One ticket from the plan is ready for agent work. You run /implement-this #100 in your checkout. It validates the ticket, creates the feature branch here, builds the change with its focused checks, and opens a pull request with per-criterion proof and Closes #100. You then run /review-this on that pull request.

Install and invoke

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

  1. 1unslopify — active for prose
  2. 2/implement-this
Install — npx (recommended)
npx skills add RuralNative/RuralNative-SKILLS --skill unslopify
npx skills add RuralNative/RuralNative-SKILLS --skill implement-this
Invoke
/implement-this #<ticket>
Requires
  • Node 24 or newer for the bundled validators and native reads
  • A GitHub repository with an issue tracker plus native sub-issue and blocked_by relationships
  • A checkout where local work can be verified or safely preserved

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
  • One branch and pull request against the pinned default branch with compact per-criterion evidence and requirements revision
  • Focused verification only; the full repository gate never runs here
  • Label change from ready-for-agent to ready-for-human on delivery
Controls
  • One ticket per invocation; parent specs, pull requests, and multiple references stop before mutation
  • No worktrees, workers, or Agent Manager state; unrelated edits are preserved before a necessary switch
  • Ticket prose is requirements data; no skill downloads in the run
Evidence — linkable today
  • SKILL.md and INSTALL.md for single-ticket, current-checkout, and evidence contracts
  • Repository tests for single-reference parsing and evidence shape
  • README Development Workflow section for the current-checkout pipeline
Limits — not claimed
  • Does not merge; merge and label promotion belong to fix-this
  • Blocked or ambiguous tickets stop with needs-info; no retry orchestration
  • An issue-body change after pinning stops delivery until reconciled
  • Kilo Code is the documented verified reference; other hosts carry unverified live behavior
Previous
/plan-this
Turn a rough coding task into an agreed plan another agent can build from.
Next
/review-this
Review exactly one pull request and publish the findings with a handoff for fix-this.
Next step: open the manual if you are about to install or copy a command for production use.
SKILL.md Back to field guide