John Berlin Leonor
Development workflowFlagship

/plan-this

Turn a rough coding task into an agreed plan another agent can build from.

A rough task is hard to split and easy to misread. This skill reads the repo, asks only about choices the repo cannot answer, then shows a plan and ticket breakdown for approval before anything is published.

SKILL.md on GitHub
At a glance
Start with
A task described in your own words, plus access to the repo and its open issues.
You decide
You settle product choices such as scope, constraints, and trade-offs the repo cannot answer.
You receive
A published parent spec and the fewest coherent tickets, each with acceptance checks, affected seams, and blocking links.

Is this the right skill?

Use it when
  • The work has several parts and you want agreement on scope before coding starts
  • The task is risky or shared and needs written acceptance checks
  • A rough idea needs to become tickets another agent can pick up
Use something else when
  • The change is small and easy to reverse without a shared plan
  • You want code written now — this skill plans only and writes no ticket code

What the workflow looks like

What you start with
A task described in your own words, plus access to the repo and its open issues.
What the skill does
It drafts the intended outcome, asks only for decisions that change product behavior, scope, cost, risk, or a hard-to-undo action, then prepares a parent spec and the fewest coherent tickets with acceptance checks.
Where you make or approve decisions
  • You settle product choices such as scope, constraints, and trade-offs the repo cannot answer.
  • You approve the plan and ticket list before anything is published to GitHub.
What you receive
A published parent spec and the fewest coherent tickets, each with acceptance checks, affected seams, and blocking links.

Step-by-step workflow

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

  1. 01
    State the goal
    Draft what done looks like, who it helps, and what is out of scope, using facts already in the repo.
  2. 02
    Compare options if needed
    When the shape is unclear, lay out different paths with value and risk, then update the goal.
  3. 03
    Settle open choices
    Ask only about decisions the repo cannot answer that change behavior, scope, cost, or risk, and record what you approve.
  4. 04
    Draft the spec and tickets
    Write single-line acceptance checks with local IDs, name affected seams, size the fewest coherent tickets, and record each split boundary.
  5. 05
    Review and publish
    Show the plan and ticket list. Nothing is published until you say so.

Worked example

Illustrative scenario
Not a measured outcome — one example of how the workflow is meant to be used.
Task: “Add a skills field guide to the portfolio.” You run /plan-this with that task. It drafts the goal, asks only about the one hard choice (where the guide lives), then shows a parent spec with AC-1…AC-6 and one ticket per separately verifiable behavior, plus the boundary reason for each split. You approve; only then does it publish the spec and tickets. Coding starts later.

Install and invoke

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

  1. 1grill-with-docs
  2. 2grilling — loaded by grill-with-docs
  3. 3domain-modeling — loaded by grill-with-docs
  4. 4to-spec
  5. 5to-tickets
  6. 6unslopify — keep active throughout
  7. 7/plan-this
Install — npx (recommended)
npx skills add mattpocock/skills --skill grill-with-docs
npx skills add mattpocock/skills --skill grilling
npx skills add mattpocock/skills --skill domain-modeling
npx skills add mattpocock/skills --skill to-spec
npx skills add mattpocock/skills --skill to-tickets
npx skills add RuralNative/RuralNative-SKILLS --skill unslopify
npx skills add RuralNative/RuralNative-SKILLS --skill plan-this
Invoke
/plan-this <task>
Requires
  • Node 24 or newer for the bundled read-only validators
  • A GitHub repository with an issue tracker for the parent spec and tickets

Kilo Code is the documented verified reference. Other hosts use native invocation with unchanged stages, but live host checks are not verified; on OpenCode, pass the task text in a separate message because slash-argument forwarding is unsupported.

Technical safeguards and limits

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

Outputs
  • GitHub parent specification issue with no claimable label
  • Child tickets with affected seams, single-line acceptance criteria, blockers, overlap notes, and risk class (ordinary or high-risk)
  • Approval preview: intent capsule, spec outline, ticket graph, and boundary reasons
Controls
  • No workers, worktrees, or managed capacity; parallel work uses user-managed checkouts with overlap notes
  • Orientation sets resolve at runtime from affected seams; length alone never rejects a ticket, and cache-gap approval may substitute or narrow sources
  • Coherence-first sizing: small task stays one ticket; splits only at separately verifiable behavior, true blockers, or independent release and risk boundaries
Evidence — linkable today
  • Repository README and SKILL.md for the install and invocation contract
  • ADRs for coherence-first sizing and runtime-resolved orientation
  • Repository tests for orientation shape validation
Limits — not claimed
  • Planning-only: it never edits ticket code or creates implementation branches
  • No skill downloads are performed from issue text
  • Quality improvement is the design goal, not an independently measured result
  • Kilo Code is the documented verified reference; other hosts carry unverified live behavior and OpenCode argument limits
Start
You are at the first guide.
Next
/implement-this
Implement exactly one ticket in the current checkout and deliver one pull request.
Next step: open the manual if you are about to install or copy a command for production use.
SKILL.md Back to field guide