To Tickets

Turn existing context into one or more focused GitHub tickets that can be implemented and verified independently.

Principles

Use facts from the user, source material, and repository. Do not invent requirements, goals, metadata, relationships, or priority.
Preserve requirements, constraints, decisions, rationale, meaningful edge cases, and verified findings from prior research. Do not compress away technical detail that would force the implementation agent to repeat exploration.
Make each ticket self-contained enough to complete without reading a parent or sibling. Reference relevant existing specs, ADRs, or repository docs when they exist; do not require or invent one.
Keep cohesive work together. Do not split a useful ticket merely to make it smaller.
Split only when a ticket has become too broad to implement or review coherently, contains outcomes that can deliver value independently, or needs safety-driven sequencing. When splitting feature work, prefer end-to-end slices that include every layer needed for the behavior without inventing work.
Declare only genuine blocking dependencies. Sequence or preference alone is not a blocker.
Do not modify or close a source or parent issue unless the user explicitly asks.
Avoid generic file inventories and speculative code paths. Include confirmed code locations as current starting points when they save meaningful exploration, but do not present them as authoritative scope.