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.

3 things to look at

19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
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 779 of the 1,178 authors here whose files we hold, read 2026-08-07

Document a rollback plan before deploymentin 41 of 779, across 22 files
Update the changelogin 21 of 779, across 19 files
Run the test suitein 20 of 779
Create an annotated git tagin 20 of 779
Clean up feature flags after full rolloutin 18 of 779, across 10 files
Verify deployment health after launchin 18 of 779, across 10 files
Test both feature flag statesin 17 of 779, across 9 files
Verify the working tree is cleanin 17 of 779
Make database migrations backward-compatiblein 16 of 779, across 8 files
Set up error monitoring before launchin 15 of 779, across 7 files
Monitor metrics at each rollout stagein 14 of 779, across 5 files
Create a GitHub releasein 14 of 779

Said here and by no other author read

fetch the plan doc and ticket before implementing
implement exactly what the spec says
strip unnecessary comments from touched files
make the lint and test suite pass
include a fixes ticket line in the PR description
show the diff summary and wait for explicit confirmation before pushing

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.