skills/pr-creator/SKILL.md
Creates GitHub pull requests with short, human-sounding descriptions. Adds a Linear issue ID prefix when available, keeps titles under 60 chars, and defaults to one short paragraph instead of generated summaries or test-plan sections. Restructures noisy commit history into reviewable order and adds reviewer guidance for large diffs. Also updates an existing open PR's title and description in place with gh pr edit instead of erroring. Use when "create a PR", "make a PR", "open a pull request", "PR this", "ship it", "update the PR description", "update the PR title", "make this PR easy to review", "polish this PR", "tidy the PR", "clean up commits", "restructure commits", or "split this PR". This skill edits the PR, not the code; to apply fixes to the diff itself use tidy. For reviewing a diff for bugs, use pr-reviewer. For monitoring a PR after creation, use pr-babysitter. For npm releases, use autoship.
npx skillsauth add mblode/agent-skills pr-creatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Write PR descriptions like a developer posting in Slack, not an AI summarizing a diff.
pr-reviewer), watching CI and review comments (use pr-babysitter), or cutting npm releases (use autoship).| File | Read When |
|------|-----------|
| references/pr-polish.md | Commits are noisy (fixup, WIP, "address review"), diff exceeds 500 lines, or user asks to polish, tidy, restructure, or split the PR |
Work through this checklist:
PR creation progress:
- [ ] Inspect: git status, git log origin/main..HEAD, git diff origin/main...HEAD
- [ ] Existing PR? gh pr view --json url,number,state (edit, not create, if one exists)
- [ ] Find the Linear ID (branch, commits, prompt, PR context); skip prefix if none
- [ ] Noisy commits or >500-line diff? Read references/pr-polish.md and restructure first
- [ ] Push with upstream: git push -u origin HEAD
- [ ] Draft title and body against the rules and anti-patterns below
- [ ] Check .github/PULL_REQUEST_TEMPLATE.md; fill its sections briefly if present
- [ ] New PR: gh pr create. Existing open PR: gh pr edit. Verify with gh pr view; return the URL
Do not ask the user to confirm the description before creating or updating; the point is speed.
ABC-123: Add auth flow. Without one: Add auth flow. Under 60 chars, no trailing period.Risk: line only for migrations, billing/auth/permission changes, irreversible writes, wide blast radius, or subtle behavior changes.Test plan section.ABC-123 is the real Linear ID)Title: ABC-123: Add auth flow with session management
Adds the auth flow needed for session-based login, including refresh, timeout handling, and a small error boundary for auth failures.
Title: PAY-482: Dedupe Stripe webhook retries
Stripe retries webhooks on timeout and our handler wasn't idempotent, so retried events created duplicate invoices. Now we record processed event IDs and skip repeats. Tested by replaying a captured retry sequence locally.
Risk: touches the billing write path.
Both carry the real why from the commits and then stop. Risk: earns its line in the second because the diff touches billing writes; the testing sentence is there only because a replay actually ran.
Probe for an existing PR first (gh pr view --json url,number,state; state == OPEN means edit, not create). The heredoc must be quoted (<<'EOF') and the branch needs an upstream: see Gotchas.
git push -u origin HEAD # skip if upstream already set
gh pr create --title "ABC-123: Add auth flow" --body "$(cat <<'EOF'
One short paragraph that explains what changed and why it matters.
EOF
)"
gh pr view --json url,title # evidence the PR exists; return the url
gh pr edit overwrites the title and body wholesale, so draft the full replacement, not a patch. Same rules and anti-patterns apply.
git push origin HEAD # push any local commits the PR doesn't have yet
gh pr edit --title "ABC-123: Add auth flow" --body "$(cat <<'EOF'
One short paragraph that explains what changed and why it matters.
EOF
)"
gh pr view --json url,title # confirm the update; return the url
gh pr create on a branch with no upstream hangs forever on an interactive "Where should we push?" prompt. Run git push -u origin HEAD first.<<'EOF'). Unquoted <<EOF lets the shell expand backticks and $vars in the body, corrupting the description or running commands.--body silently discards .github/PULL_REQUEST_TEMPLATE.md. If the template exists, fill its sections with short answers, and do not add sections it does not ask for.mblode/abc-123-add-auth gives ABC-123, uppercased). Never guess: Linear's GitHub integration links the PR to whatever ID the title contains.gh pr create from the default branch fails with "no commits between main and main". Check git branch --show-current first.gh pr create on a branch with an open PR fails with "a pull request for branch ... already exists". Check gh pr view first, then switch to gh pr edit.git diff shows only uncommitted changes, so on a committed branch it is empty and the description is written blind. Diff against the merge base: git diff origin/main...HEAD.pr-reviewer: run before creating to check the diff for bugs.pr-babysitter: hand off after creation to watch CI, conflicts, and review comments.autoship: npm release pipeline (changesets, version PR, publish); not this skill's job.development
Fans out four concurrent review agents over the current diff, then APPLIES fixes directly to the working tree and verifies the build. Mutates code; it does not produce a report. Covers reuse (duplicate logic, hand-rolled stdlib, reinvented platform features), quality (hacky patterns, React/TypeScript hygiene, over-memoisation, exhaustive-deps, `any`, dead code, `CLAUDE.md`/`AGENTS.md` violations), efficiency (unnecessary work, missed concurrency, hot-path bloat), and test discipline (bug fixes without a repro test, useless tests to delete, missing tests only when they prevent a named failure). Use when the user says "tidy this up", "simplify", "clean up this diff", "polish my changes", "check for duplication", or "any reuse opportunities?", i.e. when the intent is to have the changes made automatically. For a read-only report that lists findings without touching files, use `pr-reviewer` instead. This skill edits code; for the PR's title, description, or commit history, use `pr-creator`.
development
Decides what an interface should do before UI is built or audited: interaction choice, action scope and consequence, reachable states, resilience, and accessibility as task completion. Works from a brief, spec, mockup, intent, or existing UI. Use when asked "is this the right interaction", "design the flow", "what control should this use", "what should this action affect", "which states should this have", "make this resilient", or "what breaks here". For building or styling use ui-design; for built-code audits use ui-audit; for copy wording use copywriting.
development
Builds and stress-tests implementation plans in two modes. Create mode scans code and docs, asks one question at a time with a recommended answer, runs a blindspot pass when the user is new to the area, then writes a plan file. Review mode scores completeness, feasibility, scope, testability, risk, and assumptions, verifies checkable claims, and writes resolutions back until every dimension reaches 5/5. Use when asked to "create a plan", "plan this feature", "I want to build X", "grill me", "think this through", "blindspot pass", "unknown unknowns", "this is new to me", "review my plan", "rubber duck this", "stress test this plan", "is this plan ready", "get this plan to 5/5", "what am I missing", "verify this claim", "prove this plan", "fact-check this plan", or when the user explicitly wants a plan artifact before implementation. For code review use pr-reviewer; for architecture briefs use define-architecture.
tools
Audits the smallest relevant developer-facing surface of a library, CLI, SDK, or npm package across API contracts, errors, CLI behavior, public types, onboarding, and config. Uses candidate-first rule loading, bounded local evidence, and compact root-cause findings. Use when asked to "audit my CLI", "make this CLI agent-friendly", "is this API ergonomic", "review the developer experience", "improve these errors", "simplify first run", or "review my SDK". For end-user UI use ui-audit, for agentic-app trust use ax-audit, for docs prose use docs-writing, for README work use readme-creator, and for repo architecture use define-architecture. Inside a product that also ships a UI, this is the skill for the developer-facing half, so pick it when the complaint is about an import, command, error string, exported type, or config rather than a screen.