Agent skill · software engineering · paperclipai
prepare-paperclip-pr
Prepare a Paperclip branch for PR with commits, template body, and checks.
Why this skill is useful
Adds a detailed, domain-specific workflow for preparing pull requests in the Paperclip repository that the AI wouldn't reliably generate on its own.
What it needs
About 2k tokens when loaded. Last updated 2026-08-07. 75,771 stars on the source repository.
What this skill does
Prepare Paperclip PR The standard Paperclip procedure for turning branch work into a reviewed, green pull request against paperclipai/paperclip master. Apply it once per PR (if a task splits a branch into several PRs, run the whole procedure for each one). 0. Preconditions — worktree safety Do all PR work in a git worktree on a dedicated branch. The main ~/paperclip checkout typically runs the live Paperclip server — never check out branches there. If you are already on a worktree/branch, verify it (git rev-parse --git-dir, git branch --show-current) and proceed. If the main checkout is unexpectedly off master, fix that first without losing work (usually: move that branch's work into a worktree). Confirm which remote/ref you are targeting (normally master on the paperclipai/paperclip repo; the task may name a specific remote such as origin or public-gh). 1. Commit everything — lose no work Make logical commits of all uncommitted changes before anything else. Do not stash and forget; do not leave files behind. If commits are missing, make them. Commit messages must end with exactly: Co-Authored-By: Paperclip <noreply@paperclip.ing> 2. Get changes cleanly on top of master Fetch the target remote and rebase (or otherwise replay) your branch on top of the target master so the PR has no merge conflicts. Re-verify after rebase: build/tests relevant to the change still pass at whatever depth the task warrants. 3. Guardrails checklist (every PR) Never commit pnpm-lock.yaml — the repo has actions that manage it. If it is already in a commit, rewrite/drop that change before pushing. Never change .github/workflows/ unless the underlying commit was explicitly about that and the task calls it out. No design screenshots / wireframe images committed to the repo unless they are genuinely part of the work product. Migrations: numbered incrementally with no conflicts against master. If master moved and took your number, renumber on top. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills paperclipai/prepare-paperclip-pr