To Tickets

Turn approved work into focused GitHub tickets. Each ticket is the only thing its implementer reads, so it must contain the whole task, what "done" means, and when to stop and ask.

Invoking this skill authorizes drafts only. Write nothing to GitHub until the user approves the drafts in step 4.

Rules

• Use only what the user, the source material, and the repository tell you. Do not invent requirements, priorities, labels, relationships, or approval steps.
• Carry over decisions, constraints, rationale, edge cases, and research findings in enough detail that the implementer need not rediscover them. Keep specific constraints specific: "no pill-shaped buttons" stays as written rather than becoming "avoid a generic look".
• Mention confirmed code locations as starting points, not as scope.
• Leave out instructions like "think carefully" or "be thorough".
• Do not edit or close the source or parent issue unless the user asks.

1. Gather context

Read the source material and the code needed to make the tickets accurate. Ask only when the answer would change what a ticket requires, how the work is split, or its order.

Take the target repository as HOST/OWNER/REPO from the user or the local remote, and use that host for every GitHub read and write.