Ticket

Create a Linear issue from a free-form description.

This skill is the upstream pair of the ship / ship-autonomous skills: the issues it creates are the inputs they pick up and implement end-to-end. Draft tickets so they read well as inputs to those skills — clear scope, explicit acceptance criteria, and the plan-approval marker (see Step 3) when the user wants ship-autonomous to gate on a plan review before implementing.

Required tools

• Linear MCP — to list workspace metadata (teams, projects, labels, statuses) and create the issue. If unreachable, ask the user to reconnect.

Workflow

1. Read the description. If too thin to form a useful ticket (no problem statement, no scope), ask one short clarifying question. Otherwise proceed.

1. Probe the workspace via the Linear MCP:

- Pick the team that matches the current project directory — list teams and choose the one whose name / key / linked GitHub repo corresponds to the repo the skill is running in. If the match is ambiguous, ask the user once and remember it. - List that team's projects and labels. - Pre-select the project tied to the current repo if obvious.

1. Draft the ticket:

- Title — short, imperative, no trailing period (e.g. "Fix double-tap heart on profile grid"). - Description — markdown using this template (omit sections that don't apply):

```md ## Context

<why this matters / where it shows up>

## Current behavior

<what happens today, if it's a bug>

## Desired behavior

<what should happen>

## Acceptance criteria

- [ ] ...

## Notes

<links, edge cases, code snippets in fenced blocks> ```

- Labels — pick from existing labels only. Don't invent. - Priority — infer from language ("urgent", "blocker" → High; "nice to have" → Low). Default Medium. - Assignee — leave unassigned unless the user named one. - Plan-approval marker — if the user says implementation should require plan approval before code is written, append a clear line to the description: Plan first: please post a plan and wait for approval before implementing. The ship-autonomous skill scans the ticket for wording like this to decide whether to gate on a plan review.

1. Show the draft in chat with title, body, team, project, labels, priority. Wait for explicit approval. Edit and re-show on requested changes.

1. Create the issue via the Linear MCP. Then post the user's original request verbatim as the first comment on the new ticket — this preserves what the user asked for in their own words, separate from the polished description. Don't paraphrase, summarize, or trim it; copy the request exactly as the user wrote it (in a fenced quote block if it contains markdown that would render oddly). Report back the issue ID and URL.

Rules

• No AI attribution in the body.
• Labels and priorities must already exist in the workspace.
• File paths, errors, and stack traces go verbatim in ## Notes inside fenced code blocks.
• If the description names a parent or duplicate, set the relation on creation.