linear_ticket_2_pr

This command should keep routing, scope judgment, and stop/go decisions at the orchestrator level. Child sessions should do bounded work only: read/update Linear state, persist an artifact, research feasibility, plan, implement, verify, commit, generate the PR description, and use bash/gh tooling to push and create the PR.

The goal is to end in one of these grounded states:

• stopped early because no Linear ticket reference was provided
• stopped early because the ticket is not actionable enough and a precise question was posted on Linear
• stopped early because feasibility research surfaced blocking ambiguity and a precise question was posted on Linear
• completed through verified implementation, commit, PR creation, and Linear update with the PR link

<workflow_contract>

1. Follow all 9 steps in order.
2. Use todowrite starting in Step 2 and keep exactly one task in_progress at a time.
3. Treat <userMessage> as loose natural language. In this first pass, support no modifiers or flags.
4. Require a Linear ticket key, Linear URL, or other identifiable Linear issue reference. If none is present, ask the user for one and stop.
5. Do not create or switch branches. Assume the user already started this command on the correct branch.
6. At every major stage, return control to the orchestrator for the next DAG decision. Child sessions execute bounded work; they do not autonomously continue into later stages.
7. Before downstream codebase work, delegate full ticket intake, corpus export, and artifact-grounding handoff to a bounded Linear-capable child session. That delegated intake/export must:
   • resolve the ticket, read the full ticket description, and paginate comments until the complete corpus is captured
   • record explicit pagination-completion evidence, including how many comment pages were fetched and the terminal has_more=false result
   • ensure the ticket is In Progress if it is not already
   • persist the full corpus using the shared ticket-corpus artifact contract (stable filename + schema marker + snapshot disclaimer)
   • run thoughts_sync immediately after writing the corpus artifact
   • return artifact metadata to the orchestrator, including the saved artifact path, exact current status, pagination-completion evidence, and enough ticket identifiers to continue the workflow groundedly
8. Use a two-layer gate before planning or implementation:
   • first a task-clarity gate
   • then a feasibility-reconnaissance gate when codebase context is still needed
9. If code changes are made, require appropriate verification before claiming completion. At minimum run just check and just test unless a stronger or more targeted command set is clearly warranted.
10. The commit and PR phase must respect the agent-reset caveat: use commit, then re-enter a bash-capable session for the actual git commit/push execution and initial PR creation or update, then use describe_pr, then use bash/gh tooling for any final PR update if needed.
11. Linear updates are required when stopping for insufficient scope and when a PR is created. Set the ticket to In Progress at the start; at the end, use judgment about any obvious next status, but do not invent statuses.
12. The ticket-artifact validation stage gets one bounded refresh/fix retry. If the artifact still fails validation after that retry, stop and report the exact validation failure instead of looping. </workflow_contract>

<step_1>

Step 1: Resolve the Target Ticket

1. Parse <userMessage> as loose natural language.
2. Accept any of these as sufficient ticket references:
   • a Linear issue key such as ENG-123
   • a Linear issue URL
   • another identifiable Linear issue reference that a Linear child session can resolve responsibly
3. In this first pass, do not interpret modifiers, flags, or autonomy toggles from the input.
4. If no Linear ticket reference is present, ask the user to provide one and stop.
5. If multiple plausible tickets are referenced and one is not clearly primary, ask one concise clarification question and stop.