pull-request-workflow

What it does and when to use it

Prepare, review, or improve a GitHub pull request from a focused branch. Use when explaining changes, checking acceptance criteria, resolving review feedback, or preparing a merge-ready summary.

How it works

1. Goal
2. Workflow
3. Decision rules
4. Boundaries
5. Completion standard
6. Further reading

---
name: pull-request-workflow
description: "Prepare, review, or improve a GitHub pull request from a focused branch. Use when explaining changes, checking acceptance criteria, resolving review feedback, or preparing a merge-ready summary."
---

# Pull request workflow

## Goal

Make the proposed change easy to review and ensure its evidence and scope are clear.

## Workflow

1. Inspect branch, base, working tree, diff, project instructions, and linked issue or acceptance criteria.
2. Check the diff for scope, correctness, migration impact, security, tests, generated files, and documentation changes.
3. Resolve review comments against the actual code; preserve unrelated user edits and record any intentionally deferred feedback.
4. Prepare a concise summary with motivation, changes, verification performed, risks, and rollout or recovery notes.
5. Before merge or publication, confirm authorization, required checks, and repository policy.

## Decision rules

- Separate observed defects from style suggestions and explain priority.
- Keep a PR focused; split unrelated work when doing so does not lose necessary integration context.
- Report checks as passed only when the corresponding run and target commit are visible.

## Boundaries

- Do not merge, publish, close, or send notifications without explicit authorization.
- Do not force-push or rewrite shared history unless directly authorized.

## Completion standard

Return the requested artifact or findings with enough evidence for a reviewer to understand what changed, what was checked, and what remains uncertain. Distinguish observed facts, inferred risks, and unverified assumptions. Keep the scope tied to the user's request.

## Further reading

- [Field guide](references/field-guide.md) — use for task-specific review questions and edge cases.
- [Source and rights notes](references/source-notes.md) — use when maintaining this package or reviewing its provenance.

Versions

The database has no other skills named pull-request-workflow.

Database snapshot: 13.11.2026 · package version 0170fd6e4376 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

• 96git-pr-prep
  Prepares a Pull Request by staging changes, verifying against acceptance criteria, and creating the PR via GH CLI. Use this skill when a feature is complete and ready for review.
• 100prepare-for-review
  Prepare, open, update, or request review for an affiliate-mcp pull request. Use when asked to create a PR, make a PR review-ready, update a PR body, request maintainer review, or check whether a branch is ready for review.
• 100review-pr
  Review a pull request for code quality and security issues. Use when the user wants to review a PR, check PR code changes, or audit a pull request. Triggers on: "review PR", "review pull request", "check this PR", "the `review-pr` skill".
• 90pull-request
  How to run a pull request to the point where it can be merged — resolving every review conversation, checking every workflow run rather than the summary, and confirming the merge result is what CI actually tested. Load this whenever you open, update, review, or merge a PR,…
• 100review-github-pr
  Review a GitHub pull request by summarizing its diff and key design decisions. Use when the user wants to review a PR, understand changes in a branch, or get a code review summary. Trigger keywords - review PR, review pull request, summarize PR, summarize diff, code review,…
• 100code-review
  Use this skill when asked to review code changes — a pull request, a branch, a commit range, or the current diff — for correctness, security, and maintainability before they merge. Triggers: user says "review", "code review", "review this PR", "review my changes", "look over the…