to-issues
by mattpocockto-issues turns a plan, spec, or PRD into independently-grabbable issue-tracker tickets using tracer-bullet vertical slices. Use the to-issues skill when you need execution-ready breakdowns, clear sequencing, and AFK vs HITL issue separation for issue tracking.
This skill scores 72/100, which means it is list-worthy for directory users who want a focused workflow for turning a plan, spec, or PRD into tracker issues. The repository gives a clear trigger, a real step-by-step process, and concrete guidance on vertical-slice issue breakdowns, but users should expect some setup and workflow assumptions to be handled elsewhere.
- Clear use case and trigger: convert a plan, spec, or PRD into issues using tracer-bullet vertical slices.
- Operational guidance is specific: it explains gathering context, exploring the codebase, and drafting slices with HITL vs AFK distinctions.
- Substantive content with no placeholder markers and a reasonably developed SKILL.md body, suggesting a real workflow rather than a stub.
- It assumes the issue tracker and triage label vocabulary are already provided, so first-time use may require extra setup.
- No scripts, references, or support files are included, so agents must rely mainly on the prose instructions and conversation context.
Overview of to-issues skill
What to-issues does
to-issues turns a plan, spec, or PRD into issue-tracker tickets that can be worked one by one. The to-issues skill is built for tracer-bullet vertical slices, so each issue should represent a thin end-to-end path rather than a big horizontal chunk of one layer.
Who should use it
Use to-issues if you need implementation tickets that are actually ready to execute, especially for product work, refactors, migrations, or feature delivery. It is a strong fit when you want the issue tracker to reflect real sequencing, dependencies, and ownership rather than a loose backlog.
What makes it different
The main value of the to-issues skill is its slice discipline: it prefers independently-grabbable issues that cross schema, API, UI, and tests where relevant. It also distinguishes AFK slices from HITL slices, which helps you separate mergeable work from items that need human review or a decision.
How to Use to-issues skill
Install and setup
Install the to-issues skill with npx skills add mattpocock/skills --skill to-issues. Before using it, make sure your issue tracker, labels, and triage vocabulary are already available to the agent; the skill assumes that setup exists and explicitly notes that you may need /setup-matt-pocock-skills if it does not.
Give it the right input
For best to-issues usage, provide the source material you want broken down: a short plan, a spec, a PRD, or a linked issue with comments. If you are referencing an existing ticket, include the issue number, URL, or path so the agent can fetch the full body and comments instead of guessing from a title.
Suggested workflow
Start from the current conversation context, then have the skill gather any missing context, inspect the codebase if needed, and draft tracer-bullet slices. A good to-issues guide approach is to ask for issues that are:
- narrow but complete end to end
- named with the project’s own glossary
- ordered by real dependency, not by file structure
- marked AFK when they can merge without human input
Files and cues to read first
When evaluating or extending to-issues, begin with SKILL.md, since the repository currently has no supporting README.md, AGENTS.md, or auxiliary rule files. The practical signal is in the process text and vertical-slice rules, so focus on the process section rather than looking for hidden scripts or extra configuration.
to-issues skill FAQ
Is to-issues for Issue Tracking only?
Mostly, yes. to-issues is specifically geared toward issue tracking and work breakdown, not general brainstorming or roadmap writing. If you need release notes, architecture docs, or task lists that are not meant for an issue tracker, a generic prompt may be a better fit.
What should I provide before using it?
The best inputs are a clear plan, a current-state codebase context, and any tracker conventions that matter, such as labels or triage rules. Without that, to-issues can still draft issues, but you will get weaker titles, less accurate sequencing, and more risk of mismatched scope.
Is it beginner-friendly?
Yes, if you can describe the work clearly. The skill does the hard part of converting a larger goal into execution-ready slices, but beginners still benefit from giving one concrete objective and asking for issues in the project’s own terminology.
When should I not use it?
Do not use to-issues when you only need a quick todo list, when the work is too ambiguous to slice, or when no issue tracker exists. It is also a poor fit if you want one large ticket instead of several independently deliverable issues.
How to Improve to-issues skill
Provide stronger source material
The best way to improve to-issues results is to give the skill a crisp source of truth: a PRD section, a design note, or the exact issue you want decomposed. Include constraints that affect implementation, such as rollout requirements, affected areas of the app, or any ADRs the work must respect.
Ask for slice quality, not just count
A common failure mode is getting tickets that are too broad, too layered, or too dependent on each other. Ask for to-issues output that prioritizes end-to-end slices, keeps each ticket demoable, and separates AFK work from HITL decisions so the queue stays actionable.
Iterate on titles, scope, and ordering
After the first pass, refine the issue titles to match the team’s vocabulary and tighten any ticket that still feels horizontal. If the breakdown is close but not quite right, ask for a revision that adjusts dependency order, splits risky slices, or makes the acceptance criteria more concrete for the tracker you use.