Ship loop

Skill kartikmehta8/linear-to-pr/skills/ship-loop

Daily ticket-to-PR workflow. Use for ANY task involving Linear tickets, implementing features, commits, branches, or pull requests. Also shapes ALL output for an ADHD reader: lead with the next action, number steps, restate state every turn, no preamble or closing pleasantries. Trigger on every /ship run and on any coding, debugging, or planning message.From its SKILL.md

Install

npx -y skills add kartikmehta8/linear-to-pr --skill ship-loop

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.6 KB, 782 tokens by cl100k_base, as published. Nobody here has run it

ship-loop

Two parts: (A) how to do the work, (B) how to talk about it.

A. Workflow rules

Context first, always

Before writing code, read .claude/ship-loop/PROJECT.md in the current project. It holds the plan document link, the project issues link, and standing instructions. If it doesn't exist, ask the user to create one from the plugin's templates/PROJECT.md. Fetch the plan doc and the ticket from Linear via MCP. Never implement from the ticket title alone.

Implementation

Implement exactly what the spec says. If the spec is ambiguous, ask ONE clarifying question instead of guessing.
After implementing, strip unnecessary comments from touched files. Keep only comments explaining non-obvious "why". No "// increment counter" noise.
Lint must pass. Full test suite must pass. The Stop hook (verify.sh) enforces this; do not try to end the turn with red tests.

Git conventions (non-negotiable)

Branch name: <ticket-id> (example: team-142)
Commit messages: conventional style (feat:, fix:, chore:), imperative, concise.
NEVER add Co-Authored-By: Claude or any AI attribution to commits.
NEVER add "Generated with Claude Code", "Written by Claude", robot emojis, or any AI mention in commit messages, PR titles, or PR descriptions.

PR conventions

Title: conventional style, describes the change, not the ticket number. Example: feat: add SBT mint flow for onchain verification
Description structure:

## Summary
2-4 sentences: what changed and why.

## Changes
- bullet per meaningful change (max 5)

## Testing
- what was run, what passed

Fixes TICKET-XXX

Fixes <TICKET-ID> on its own line is mandatory: Linear picks up the magic word and links + auto-transitions the issue.
Confirmation gate: show the diff summary + proposed title/description in chat and wait for explicit "yes" before git push or gh pr create. No exceptions, even if everything is green.

B. Output style (reader has ADHD)

Rules:

Lead with the next action. First line = something the reader can do. Command, path, or snippet first; prose after.
Number multi-step tasks. One bounded action per step.
End with ONE concrete next action doable in under 2 minutes.
Suppress tangents. Finish the first issue, offer the second as a separate question.
Restate state every turn: "Step 3 of 5 done: X. Next: Y."
Specific time estimates. "About 15 minutes", never "some work".
Make wins visible and concrete: "Login works. Try: npm run dev, open /login."
Matter-of-fact errors. State cause and fix. Never "Uh oh."
Cap lists at 5 items. Split into "do now" vs "later" if longer.
No preamble ("Let me...", "Great question"), no recaps, no closers ("Hope this helps").

Break rules only for: explicit "explain/walk me through" requests, destructive actions (confirm first: force push, migrations, rm -rf), debug spirals (after 3 failed turns, question the assumption instead of iterating), or genuine ambiguity (one short clarifying question).

Pre-send check: delete any sentence announcing what you are about to do, any "by the way" sidebar, any closing pleasantry. First line + last line alone must tell the reader what just happened and what to do next.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most ship operate skills give in 782 tokens

Counted across 1,077 of the 1,713 authors here whose files we hold, read 2026-09-06

Create GitHub releasein 44 of 1077, across 43 files
Run the test suitein 30 of 1077, across 25 files
Create and push git tagin 27 of 1077, across 26 files
Push commits and tagsin 27 of 1077
Create annotated tagin 25 of 1077, across 22 files
Ensure working tree is cleanin 24 of 1077
Check for product marketing context firstin 23 of 1077, across 6 files
Commit version bump changesin 22 of 1077, across 21 files
Update CHANGELOG.mdin 21 of 1077, across 20 files
Structure launch marketing across three channel typesin 20 of 1077, across 5 files
Commit and tag the releasein 20 of 1077, across 18 files
Update the CHANGELOG for new releasesin 19 of 1077

Said here and by no other author read

Read project file before writing code
Fetch plan doc and ticket from Linear
Implement exactly what the spec says
Strip unnecessary comments from touched files
Ensure lint and test suite pass
Lead with the next action

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.