Stats
Actions
Tags
From Flagrare
Opens a pull request that follows repo conventions: reads the PR template, contextualizes changes, links tracker tickets, and writes testing notes. Use when code is ready to ship and you want a review-ready PR.
How this skill is triggered — by the user, by Claude, or both
Slash command
/flagrare:open-prThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create a pull request that reads like a human wrote it.
Create a pull request that reads like a human wrote it.
The goal is a PR description that a reviewer can scan in 30 seconds and understand: what changed, why, and how to verify it works. No file-by-file enumerations. No bullet-point dumps of every touched line. Context and narrative.
Gather the raw material:
git log --oneline $(git merge-base HEAD main)..HEAD
git diff --stat $(git merge-base HEAD main)..HEAD
git diff $(git merge-base HEAD main)..HEAD
Also check the branch name for a ticket key (e.g., SKU-478/fix-menu-disabled).
cat .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null || cat .github/pull_request_template.md 2>/dev/null
If no template exists, use a minimal structure: title, description, testing notes. But most repos have one, and following it exactly is non-negotiable. The template is the contract between author and reviewer.
If a ticket key was found (branch name, commit messages, or user-provided):
/flagrare:intake Step 0.If a design link (Figma, etc.) appears in the ticket, note it in the PR for visual reference.
Fill the template section by section. For each section, the principle is the same: write like you're explaining this to a teammate over coffee, not generating a report.
Title: Short, imperative. Under 70 characters. Prefixed with ticket key if the repo convention does that.
Description sections:
What changed (product perspective): One paragraph. What does the user/partner/admin experience differently after this merges? Not "changed line 47 of MenuSelector" but "newly created menus now appear active in the selector instead of incorrectly showing as disabled."
What changed (code perspective): Brief technical summary. Which decision did you make and why? Mention the approach, not every file. "Switched the disabled-state derivation from published to enabled in the dropdown component, since published is ClassPass-controlled and shouldn't affect partner-facing status."
Testing: How you verified this works. Be specific: "Ran the full SkuItems test suite (398 tests passing). Added 4 new test cases covering the enabled/published separation." If you tested in a browser or dev environment, say so.
Checklist items: Check off what applies, leave unchecked what doesn't. Don't delete template items (reviewers use them as a reference).
git push -u origin HEAD
gh pr create --title "<title>" --body "$(cat <<'EOF'
<filled template>
EOF
)"
If the branch already has a remote and a PR exists, update it instead:
gh pr edit <number> --body "$(cat <<'EOF'
<filled template>
EOF
)"
Show the user the PR URL and a brief summary of what was submitted. Don't reprint the entire body.
These principles make the difference between a PR that gets reviewed in 5 minutes and one that sits for days:
git status for uncommitted work.main, master, develop).[implementation complete]
|
v
/flagrare:wrap-up <- quality gate
|
v
/flagrare:open-pr <- THIS SKILL
|
v
[reviewer picks it up]
npx claudepluginhub flagrare/agent-skills --plugin flagrareProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.