How to use the GitHub PR Workflow agent skill: step by step

What the skill makes the agent do

Once installed, the agent follows a checklist for opening and maintaining a GitHub pull request. It tidies the branch and commits, writes a short imperative title under 70 characters, and fills in a structured body with four sections: Summary, Implementation notes, Verification and Risk and rollback.

It also guides how to add screenshots for UI changes and how to reply to reviewer comments, push fixes and re-request review. The skill is guidance only. It does not run anything itself.

• Branch hygiene: rebase or merge from the target base, squash WIP commits and remove debug prints and untracked TODO markers.
• Title: lead with the user-visible change and follow any issue prefix convention the repo uses.
• Body: Summary, Implementation notes, Verification and Risk and rollback. Risk and rollback can be skipped only for clearly trivial PRs such as typos or docs.
• Review: reply to every comment, push fixes as new commits during review and re-request review after pushing.

Install the skill from the ZIP

Download the skill ZIP from this page and unzip it. Put the resulting folder in one of two places. For a personal skill available across your projects, use ~/.claude/skills/. For a skill that only applies to one project, use .claude/skills/ inside that project.

If you use the Claude apps instead, open Settings, go to Capabilities and upload the skill under Skills.

• Personal install: ~/.claude/skills/
• Project install: .claude/skills/ in the project root
• Claude apps: Settings → Capabilities → Skills, then upload

Trigger the skill with natural requests

You do not need a special command. Ask the agent in plain language about the pull request task you are doing. The skill is written for three situations: opening a PR for a functionally complete change, responding to review comments, and bringing an older PR back into shape with stale conflicts, a missing description or missing verification.

Give the agent the context it needs, such as the base branch and what the change does, so the title and body can be specific.

• "Prepare a PR for this feature branch against main."
• "Write the PR title and body for these commits."
• "Reply to the review comments on my open PR and push fixes."
• "This PR has been open two days and has conflicts. Bring it back into shape."

What to check in the output

The agent should produce a title and body that match the template, and it should list the exact commands or steps it ran for verification. Check that the verification section is based on what actually happened. The skill asks for real commands and real screenshots rather than general claims, so any gaps should be filled in by you before you submit.

For UI work, the skill asks for screenshots of the golden path and one edge case, with dark and light mode tagged if the project supports both. For migrations it asks for a dry-run plan and reversal steps. For performance changes it asks for a before and after measurement.

• Verification lists commands or steps actually run, not vague claims.
• UI changes include screenshots of the main path and one edge case.
• Migrations include a dry-run plan and reversal steps.
• Performance changes include a before and after measurement.

Safety notes: scripts and network

This skill runs no scripts and uses no network access. It does not call the GitHub API. It is a text checklist, so the agent's normal access to git and GitHub is what does the work. You still need git installed, a GitHub account and access to the target repository.

Because the skill is only guidance, review anything the agent pushes or posts on your behalf, especially replies to reviewers and force-pushes.

• Runs scripts: no
• Uses network: no
• Requires git, a GitHub account and access to the repository

Tips for better results

Finish the change before asking for a PR. The skill says draft PRs that bounce on review create noise, so treat it as a tool for ready-to-review work. During review, push fixes as new commits and avoid amending or force-pushing unless the reviewer agrees.

• Name the base branch and any issue key so the agent can follow your prefix convention.
• Note deliberate test skips in your request so they appear in the PR body.
• Ask the agent to update the title and body if scope changed mid-review.
• Delete the branch after merge unless it is a long-lived integration branch.