| name | grillmester-to-issues |
| description | Use only after the user explicitly selects To Issues to break an approved plan or specification into independently useful GitHub issues with native blocking edges. |
To Issues
OpenCode v1: Backticked grillmester-* names below are skill IDs, not slash commands. Load them with the native skill tool. Slash commands are direct user entry points only.
Break a plan, spec, or conversation into GitHub issues — tracer-bullet
vertical slices that remain understandable and useful on their own.
Start only after the user has explicitly selected grillmester-to-issues in the current
conversation. Relevance or a prior recommendation is not selection.
Establish tracker context from consumer-owned instructions, issue templates,
contributor documentation, and read-only GitHub metadata before tracker use.
A dedicated adapter file is optional; its absence must not block drafting.
Stop before publishing only when the target repository, authorization boundary,
or a required operation or metadata value remains unresolved.
Process
1. Gather context
Work from whatever is already in the conversation context. If the user passes a reference (a spec path, an issue number or URL) as an argument, fetch it and read its full body and comments.
2. Explore the codebase (optional)
If you have not already explored the codebase, do so to understand the current
state of the code. Issue titles and descriptions should use the project's
domain glossary vocabulary and respect ADRs in the area you're touching.
Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy, then make the easy change."
3. Draft vertical slices
Break the work into tracer bullet issues.
- Each slice cuts a narrow but COMPLETE path through every layer (schema, API, UI, tests) — vertical, NOT a horizontal slice of one layer
- A completed slice is demoable or verifiable on its own
- Each slice is sized to fit in a single fresh context window
- Any prefactoring should be done first
Give each issue its blocking edges — the other issues that must complete
before it can start. An issue with no blockers can start immediately.
Wide refactors are the exception to vertical slicing. A wide refactor is
one mechanical change — rename a column, retype a shared symbol — whose blast
radius fans across the whole codebase, so a single edit breaks thousands of
call sites at once and no vertical slice can land green. Don't force it into a
tracer bullet; sequence it as expand–contract. First expand: add the new
form beside the old so nothing breaks. Then migrate the call sites over in
batches sized by blast radius (per package, per directory), each batch its own
issue blocked by the expand, keeping CI green batch to batch because the old
form still exists. Finally contract: delete the old form once no caller
remains, in an issue blocked by every migrate batch. When even the batches
can't stay green alone, keep the sequence but let them share an integration
branch that all block a final integrate-and-verify issue — green is promised
only there.
4. Quiz the user
Present the proposed breakdown as a numbered list. For each issue, show:
- Title: plain-language outcome, understandable without opening the issue
- Blocked by: which other issues (if any) must complete first
- In short: who or what benefits, what changes, and why it matters
- Implementation brief: the decisive technical context, proof, and scope
Ask the user:
- Does the granularity feel right? (too coarse / too fine)
- Are the blocking edges correct — does each issue only depend on issues that genuinely gate it?
- Should any issues be merged or split further?
Iterate until the user approves the breakdown. Approval of its shape is not
authorization to mutate the tracker: present the exact issues, metadata, and
relationships and obtain explicit authorization for those writes.
5. Publish the issues to GitHub
After authorization, publish one issue per slice in dependency order
(blockers first) so later relationships can reference real identifiers. Use the
tracker's native parent and blocking relationships. Apply only labels and issue
types established by consumer evidence or live metadata; never approximate a
missing relationship or label in prose.
Read the created issues, project state, and native relationships back after
writing. Report a
partial failure instead of silently continuing with a malformed graph.
Work the frontier: any issue whose blockers are all done. For a purely
linear chain that means top to bottom.
Do NOT close or otherwise modify a parent issue unless that mutation was
included in the authorized set.
Use a functional title that names the observable change rather than the
implementation mechanism. Start the body for humans who do not know the code:
## In short
<one or two sentences: who or what benefits, what changes, and why it matters>
What to build
<the end-to-end behaviour this issue makes work, not a layer-by-layer walkthrough>
Acceptance criteria
Implementation context and proof
<relevant current state, constraints, risks, test seams, and evidence>
Out of scope
Use a user story only when a real actor and value become clearer in that form.
Do not force technical work into “As a …” prose. Put the technical brief after
the human-readable opening. Preserve the evidence, constraints, test seams,
and non-goals an implementer or agent needs; remove only detail that would go
stale or prescribe an unchosen implementation.
Present tracker metadata alongside the draft: issue type, labels, project and
initial status, parent, blockers, and assignee when applicable. Store parent,
blocking, and project state in native metadata rather than body prose.
Keep parent and blocking state in native tracker relationships, not duplicated
body sections. Add dependency prose only when a non-obvious rationale will
help the implementer; it never carries graph state.
Avoid speculative paths, exhaustive file inventories, and snippets that merely
prescribe an implementation. Retain verified current anchors such as a symbol,
path, failing test, query, or command when they are evidence or the clearest
test seam. If a prototype produced a snippet that encodes a decision more
precisely than prose can (state machine, reducer, schema, type shape), inline
only its decision-rich parts and identify it as prototype output.
