github-pr-creation
by fvadicamogithub-pr-creation helps turn a completed branch into a review-ready GitHub Pull Request. It validates branch flow, finds task docs, checks evidence, and drafts Conventional Commits-style titles and structured PR content. Use this github-pr-creation skill for Git Workflows when you need a disciplined PR draft, not a generic prompt. Not for merging existing PRs.
This skill scores 71/100, which means it is worth listing for users who want a more guided PR-creation workflow than a generic prompt. The repository shows a real operational procedure with branch confirmation, task-document discovery, Conventional Commits templating, and label suggestions, but the install decision should be tempered by some missing depth in the visible supporting materials and the presence of placeholder markers in the skill body.
- Strong triggerability: the description explicitly covers creating/opening PRs, checking readiness, and points to merge handling elsewhere.
- Operational workflow is concrete: it tells the agent to confirm target branch, inspect task docs across common tools, and use PR templates from references/pr_templates.md.
- Reusable leverage is evident: it includes Conventional Commits titles, checklist-oriented templates, and repo/file references that reduce guesswork during PR drafting.
- The visible support material is thin: only one reference file is present, with no scripts or additional resources to automate or validate the workflow.
- The skill body contains placeholder markers ('todo') and the excerpted content is truncated, so users may encounter incomplete guidance in some branches of the workflow.
Overview of github-pr-creation skill
What github-pr-creation does
The github-pr-creation skill helps turn a completed branch into a review-ready GitHub Pull Request with the right branch target, task context, and PR wording. It is built for people who need a disciplined github-pr-creation workflow, not just a generic “write me a PR description” prompt.
Who should use it
Use this github-pr-creation skill if you are preparing a feature, fix, hotfix, or release PR and want the draft to reflect repo conventions, task tracking, and commit history. It is especially useful when the target branch is not obvious, when requirements live in scattered spec files, or when you need Conventional Commits-style PR titles and structured templates.
What it is best at
The main value of github-pr-creation for Git Workflows is validation before writing. It checks current branch state, expects a confirmed target branch, searches for task docs, and helps shape a PR around actual work completed. That makes it stronger than a one-paragraph prompt when the PR needs to be aligned with branch policy, issue references, and template sections.
When it is not the right fit
Do not use this skill for merging an existing PR, backport automation, or unrelated GitHub maintenance. If you only need a quick title and you already know the exact diff, a simple prompt may be enough; the skill is more valuable when the workflow and evidence matter.
How to Use github-pr-creation skill
Install and read the right files
For github-pr-creation install, add the skill with npx skills add fvadicamo/dev-agent-skills --skill github-pr-creation. Then read SKILL.md first, followed by references/pr_templates.md. If you need more context, inspect any task or spec files the repository uses, such as .s2s/plans/*.md, .kiro/specs/*/tasks.md, .cursor/rules/*.md, .trae/rules/*.md, or docs/specs/.
Give the skill the inputs it actually needs
The github-pr-creation usage works best when you provide four things: the current branch, the intended target branch, what task or spec the PR satisfies, and any constraints such as tests run, docs changed, or migration notes. A weak request says “make a PR”; a stronger one says “I’m on feature/payment-retry, target develop, this closes task 2.3 from .s2s/plans/billing.md, tests passed, and I need a feature PR draft.”
Follow the workflow the skill expects
A good github-pr-creation guide starts by confirming the branch flow, then checking task documentation, then mapping the work to the correct PR template. Use the skill when you want it to generate a title like feat(scope): description, summarize what changed, and surface checklist items that match the branch type. For best results, let it inspect commits and task files before you ask it to write the final PR body.
Use template-aware prompting
When you prompt, mention the PR type and what evidence exists. For example: “Create a feature PR from feature/search-filter to develop. Use references/pr_templates.md, include the relevant task IDs, note that tests passed, and keep the description concise.” This helps github-pr-creation produce output that fits the repo’s template instead of inventing sections.
github-pr-creation skill FAQ
Is github-pr-creation only for GitHub PR text?
No. The github-pr-creation skill is for preparing a PR in a way that matches branch rules, task tracking, and review expectations. The text is the output, but the real job is deciding what the PR should say based on the branch and supporting evidence.
How is this different from a normal prompt?
A normal prompt can draft a PR, but github-pr-creation adds workflow discipline: confirm target branch, find task docs, and use repository-specific templates. That reduces guesswork when the branch history and requirements are more important than generic wording.
Can beginners use it?
Yes, if they can name their branch and know what they changed. Beginners get the most benefit when they copy the repo’s task or spec path into the prompt instead of asking for a PR from memory.
When should I choose something else?
If you need to merge an existing PR, use github-pr-merge instead. If your repo has no task docs or branch conventions and you only want a rough summary, a simpler draft prompt may be faster than a full github-pr-creation flow.
How to Improve github-pr-creation skill
Provide cleaner branch and task evidence
The best github-pr-creation results come from explicit branch names, linked tasks, and a short change summary. Include the exact target branch, any issue or task IDs, and the files or feature area touched so the skill can avoid vague PR language.
Tell it what changed and what was verified
If you want a stronger PR body, state whether you added tests, updated docs, changed migrations, or only refactored code. For example: “Added retry logic in src/payments/retry.ts, covered by unit tests, no schema changes” is much more useful than “fixed payment bug.”
Watch for common failure modes
The main failure mode is missing task context, which leads to generic PR text. Another is skipping the target-branch check, which can create a PR against the wrong base branch. A third is overclaiming completion; if a task is partially done, say so and list the gaps.
Iterate from draft to review-ready
Use the first github-pr-creation output as a draft, then tighten it with concrete details: task IDs, scope, test results, and release or rollback notes if needed. If the PR template asks for checklist items, keep only the items you can honestly verify. That is usually the fastest way to turn github-pr-creation usage into a cleaner, review-ready PR.
