to-ticketslisted

# To Tickets Break a plan, spec, or conversation into a set of **tickets**: tracer-bullet vertical slices, each declaring the tickets that **block** it. ## Tracker Publish to the project's issue tracker when this session can reach one: an issue-tracker MCP server or a tracker CLI the host has connected (`gh issue` for GitHub Issues counts). Take the identifiers it needs (assignee, team or project, and the issue key prefix) from the project map in `AGENTS.md`, or ask the user once; never guess or hardcode them. No tracker reachable: publish local files under `docs/plans/<feature-slug>/` instead (step 5). `docs/plans/` is working state, not documentation: the first time you create it in a project, ask whether it should be committed or added to `.gitignore`. ## Process ### 1. Gather context Work from whatever is already in the conversation context. If the user passes a reference as an argument, fetch it and read its full body and comments: an issue ID or URL through the tracker, a spec path (e.g. `docs/plans/<feature-slug>/spec.md`) by reading the file. ### 2. Explore the codebase (optional) If you have not already explored the codebase, do so to understand the current state of the code. Ticket titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching (the project map in `AGENTS.md` says where both live). Look for opportunities to prefactor the code to make the implementation easier. "Make the change easy,