sdk: Skill for Claude Code

Linear One-Shot

Surfaces one-shottable Linear tickets — small, well-defined, safe for an AI agent to implement in a single autonomous run — and scopes them into an executable brief so anyone can pick one up and run an agent on it.

Two operations:

• Triage — scan a backlog, classify each ticket (candidate / needs-qualify / reject), report. "triage one-shots", "find easy tickets in repo_app".
• Qualify — take one ticket, read its code, produce a scoped brief + a ready / needs-human verdict. "qualify WAN-326".

A third stage, execute, is a documented hand-off (see the end) — this skill does not write code.

Default posture is read-only. Triage and qualify report in chat. Every Linear write (labels, comments) is opt-in and only happens after you explicitly confirm a shown draft — never silently.

Step 0 — Preflight

• Linear MCP — required. You need Linear tools (list_issues, get_issue, list_issue_labels, and for writes save_issue / save_comment / create_issue_label). If they are not available, STOP and tell the user: "This skill needs the Linear connector, which isn't available in this session. Add it in your Claude connectors / MCP setup (Settings → Connectors → Linear, or claude mcp add the Linear server), then re-run." Do not proceed without it.
• GitHub CLI (gh) — optional. Only used by qualify to read a ticket's files when you are not inside a checkout of that ticket's repo. If gh auth status fails, qualify still works from inside the relevant repo; out-of-repo it degrades to "I can't read the code — run me from inside the repo, or authenticate gh."

Then route by intent: a backlog/triage request → Operation A; a single ticket id ("qualify WAN-123") → Operation B.

Operation A — Triage

1. Pick one repo. The executor that will eventually implement these tickets runs in a single repo, so triage is per-repo. Default to repo_app (label) unless the user names another (repo_sdk, repo_cli, repo_website). Confirm the repo if ambiguous.
2. List the backlog. list_issues with team: Product, state: backlog (and/or unstarted), the chosen repo_* label, includeArchived: false. Page through if needed. Large lists may exceed the tool's output budget — if so, classify in batches.
3. Read enough to judge. Linear truncates long descriptions in list results. For any ticket that looks like a plausible candidate, fetch the full description with get_issue before deciding — a hidden line ("needs a migration", "new copy") flips the verdict. Do not green-light a ticket whose description you only half-read.
4. Score every ticket with the Rubric (below). Bucket into ✅ candidate / 🟡 needs-qualify / ❌ reject. Bias hard toward reject — a missed candidate costs nothing; a false candidate burns an agent run and erodes trust.
5. Report in chat: a one-line summary with counts, then three grouped tables (ticket id, title, one-line rationale citing the specific flag, confidence). It is a completely valid and honest result for a backlog to return zero candidates — say so plainly; never manufacture candidates to fill the table.
6. (Optional) Apply — only on explicit request, e.g. "tag the candidates". Show the exact labels/comments you will write and ask: "Apply these to Linear? (oneshot:candidate + a one-line rationale comment on each)". On approval: ensure the label group exists (see Writes), then save_issue to add oneshot:candidate and save_comment for the rationale. Confirm each as it lands. Nothing is written before approval.