github-pr-workflow

Prepares GitHub pull requests with structured titles, bodies, verification evidence, and review replies.

Updated Mar 26, 2026
One-click install
npx skills add https://github.com/nabitllc/todero --skill github-pr-workflow-nabitllc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: github-pr-workflow
Source: https://github.com/nabitllc/todero/tree/main/packages/skills-catalog/catalog/bundled/software-development/github-pr-workflow
Command: npx skills add https://github.com/nabitllc/todero --skill github-pr-workflow-nabitllc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pull requests often stall because reviewers cannot understand what changed, why, or whether it works. This Skill standardizes how you prepare, describe, and defend a GitHub pull request so reviewers can approve it without follow-up clarifying questions. ## Core Features & Use Cases - Branch Hygiene: Guides rebasing, squashing WIP commits, and confirming tests, typecheck, and lint pass before opening the PR. - Structured PR Content: Enforces an imperative title under 70 characters and a body with Summary, Implementation notes, Verification, and Risk and rollback sections. - Review Management: Covers replying to every review comment, pushing fixes as new commits during active review, and re-requesting review explicitly. - Use Case: An engineer finishes a UI feature, uses this Skill to write the PR body with screenshots of the golden path and an edge case, responds to reviewer feedback with commit references, and merges with a clean checklist. ## Quick Start Use the github-pr-workflow skill to prepare my current feature branch as a pull request with a proper title, body, and verification notes.

Frequently Asked Questions about github-pr-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write a good GitHub pull request description?

Structure the PR body with Summary, Implementation notes, Verification, and Risk and rollback sections. Include the exact commands you ran, screenshots for UI changes, and revert steps so reviewers can approve without follow-up questions.

How should I respond to pull request review comments?

Reply to every comment, even with just "fixed in <commit-sha>", so reviewers are not left guessing. Push fixes as new commits during active review, and re-request review explicitly after pushing changes.

What makes a good pull request title on GitHub?

Use imperative mood under 70 characters, leading with the user-visible change rather than the file touched. Follow any issue prefix convention the repo uses, and omit trailing periods.

Should I squash commits before opening a pull request?

Squash WIP commits into reviewable units, preferring one commit per logical change. Do not force one commit per PR when the work is genuinely multi-step, and avoid amending during active review unless the reviewer agrees.

When should I not open a pull request yet?

Do not open a PR when the change is not functionally complete, since draft PRs that bounce on review create noise. Also confirm tests, typecheck, and lint pass locally before opening.