pr-perfectlisted

Create a GitHub PR with an engineered description that matches the team's established format — numbered problem-fix sections, technical tables, file-by-file breakdowns, commit lists, and verification checklists. Use this skill whenever the user asks to create a PR, ship code, prepare a merge request, write a PR description, or says anything like "ship to boss", "pr perfect", "make a PR", "prepare PR for merge", "create pull request", "engineer the PR", "PR description", or "ready to push". Also trigger when the user has finished a batch of work and says things like "let's wrap this up", "time to merge", "push this to main", or "get this ready for review". The skill handles everything: commit analysis, description generation, branch creation, and PR submission via gh CLI.
OthmanAdi/pr-perfect · ★ 2 · Code & Development · score 70

Install: claude install-skill OthmanAdi/pr-perfect

# Ship to Boss Create PRs that serve as briefing documents — detailed enough for both humans and coding agents to review, verify, and merge with confidence. ## Arguments The skill accepts free-form `ARGUMENTS` at invocation. Only one flag needs special handling: | Flag | Aliases | Effect | |---|---|---| | `--no-branch` | `--local-only`, `--no-pr`, `--draft-only` | **Skip branch creation, push, and `gh pr create` entirely.** Write the engineered description to `PR_DESCRIPTION.md` at the repo root and stop. Use this when the user commits directly to `main` and wants the description text only — e.g. to paste into a PR opened manually, attach to a changelog, or hand off to someone else to create the PR. | Detection: treat the flag as present if any of its aliases appears as a whole token in `ARGUMENTS` (case-insensitive). When present, **Step 4 is replaced** by the Local-only variant below — everything else (Steps 1–3) runs identically. ## Why This Format Matters The PR description is not just documentation. The reviewer (and their coding agent) uses it to verify changes make sense, spot conflicts, and confirm nothing breaks. Every table, every file listing, every verification bullet exists so the reviewer can cross-reference the description against the actual diff. A vague PR description forces the reviewer to reverse-engineer intent from raw code — that's slow and error-prone. ## Workflow Execute these steps in order. Do not skip any step. ### Step 1: Forensic Commit