agentleFS
Sign inStart free
paultyngpaultyng/skill-issue/skills/ship-it/SKILL.md

ship-it

Skill8 starsChanged 3 months agoMITView on GitHub

End-to-end shipping workflow. Formats, lints, tests, creates a changelog entry, commits with conventional commits, pushes, updates PR description, and suggests reviewers. Use when the user says "ship it", "commit and push", "fmt lint test commit push", or similar shipping commands.

  • Commits and pushes

We split this skill into the rules it gives an agent

16 rules. 0 are common, 12 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 39 edited versions we read keep these.

  • 12

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run the full pre-commit pipeline, commit, push, and handle PR housekeeping.

    line 8
  2. Distinctive:

    Run verification per verify-when-complete.

    line 12
  3. Very specific:

    Review-status check (informational, non-blocking): If a .reviews/<date>/SUMMARY.md exists whose GIT_COMMIT_FULL metadata header matches the …

    line 14
  4. Very specific:

    Do not block on N > 0 — /ship-it runs because the user said so.

    line 20
  5. Distinctive:

    Check if the project has a changelog convention:

    line 24
  6. Very specific:

    If Taskfile.yaml has a changelog task, run task changelog and follow its output.

    line 26
  7. Distinctive:

    If a convention is found, create a terse entry following the existing format and patterns.

    line 30
  8. Distinctive:

    If no changelog convention exists, skip this step.

    line 31
  9. Distinctive:

    Always create a new commit.

    line 43
  10. Distinctive:

    If a PR exists for the current branch, update its title and description to reflect the current state:

    line 55
  11. Distinctive:

    If no PR exists, run create-pr to open one.

    line 63
  12. Distinctive:

    If a PR exists, query reviewer state and present suggestions:

    line 67
  13. Distinctive:

    If someone already reviewed, suggest re-requesting the same reviewer.

    line 79
  14. Distinctive:

    If a review is already requested, note who.

    line 80
  15. Very specific:

    If no reviewer yet, present GitHub's suggestedReviewers list.

    line 81
  16. Distinctive:

    Do not auto-assign. Present suggestions and let the user decide.

    line 83

“Common” is measured: kept by at least 6 in 10 of the 39 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Ship It

Run the full pre-commit pipeline, commit, push, and handle PR housekeeping.

1. Verify

Run verification per verify-when-complete. Stop if any step fails.

Review-status check (informational, non-blocking). If a .reviews/<date>/SUMMARY.md exists whose GIT_COMMIT_FULL metadata header matches the current HEAD SHA, count the rows under ## Findings — untracked and inside the <details> block for Findings — tracked, then print a single line:

Review status: <N> untracked / <M> tracked findings @ <short-sha> (<.reviews/path>)

Do not block on N > 0 — /ship-it runs because the user said so. The line is a sanity check, not a gate. If no matching SUMMARY.md exists, skip the line silently (don't run /review-all from here).

2. Changelog

Check if the project has a changelog convention:

  1. If Taskfile.yaml has a changelog task, run task changelog and follow its output.
  2. Otherwise, look for existing changelog entries:
    • Per-PR fragment directories like .changeset/ (JS/TS via @changesets/cli), .changes/ (Python via towncrier), or similar project-defined conventions
    • CHANGELOG.md at the repo root
  3. If a convention is found, create a terse entry following the existing format and patterns.
  4. If no changelog convention exists, skip this step.

3. Commit

Stage all changes and commit using Conventional Commits format:

<type>[optional scope]: <description>

Common types: feat, fix, refactor, test, docs, chore, ci, build.

Always create a new commit. Never amend.

Apply terse-output commit-message tone: imperative subject ≤72 chars, body explains why (the diff shows what), no "this commit does X" / "I" / "we" / "now". Keep the Co-Authored-By: Claude… attribution.

4. Push and PR

Push the current branch:

git push -u origin HEAD

If a PR exists for the current branch, update its title and description to reflect the current state:

gh pr edit --title "<title>" --body-file /tmp/pr-body.md

For PRs with diffs over ~20 files or ~500 lines, delegate body authoring to a subagent (model: sonnet per subagent-model-routing — PR-body authoring from a non-trivial diff requires real synthesis reasoning) per parallelize-subagents and subagent-prompt-contract: paste the commit list and git diff --stat inline, ask for a summary section + bullet list of notable changes capped at ~200 words, and have the subagent return with the four-state Status line. Main writes /tmp/pr-body.md from the summary. Small PRs stay inline.

If no PR exists, run create-pr to open one.

5. Suggest Reviewers

If a PR exists, query reviewer state and present suggestions:

gh api graphql -f query='
{ repository(owner:"OWNER", name:"REPO") { pullRequest(number:NUM) {
  reviewRequests(first:10) { nodes { requestedReviewer { ... on User { login } ... on Team { slug } } } }
  latestReviews(first:10) { nodes { author { login } state } }
  suggestedReviewers { reviewer { login } isAuthor isCommenter }
} } }'

Logic:

  • If someone already reviewed, suggest re-requesting the same reviewer.
  • If a review is already requested, note who.
  • If no reviewer yet, present GitHub's suggestedReviewers list.
  • For deeper git-history-based suggestions, use /analyze-knowledge. It fans out per-area analysis to subagents for PRs with >20 files, so keep the parent context clean.
  • Do not auto-assign. Present suggestions and let the user decide.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free