From claude-resources
Pull request creation and response discipline. Use when opening a PR with `gh pr create`, responding to review comments, selecting a merge strategy (squash / merge commit / rebase), marking a draft PR ready, or updating a PR description after the branch changes. Trigger on phrases like "open a PR", "create the pull request", "respond to review comments", "merge this PR", "mark ready", or "which merge strategy?". Part of the opt-in `ops-skills` plugin — requires `ops_enabled=true` in session context; if disabled, report the intended action as a follow-up instead of running it. Pair with core/git-workflow §5 for the body content you put inside the PR.
npx claudepluginhub deandum/claude-resources --plugin go-skillsThis skill uses the workspace's default tool permissions.
Creating a PR is an announcement: "here is work I want merged." It triggers CI, notifies reviewers, and starts a conversation. This skill covers the mechanics — creation, template selection, review response, merge decision. For the content of a good PR description, see `core/git-workflow` §5.
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.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides agent creation for Claude Code plugins with file templates, frontmatter specs (name, description, model), triggering examples, system prompts, and best practices.
Creating a PR is an announcement: "here is work I want merged." It triggers CI, notifies reviewers, and starts a conversation. This skill covers the mechanics — creation, template selection, review response, merge decision. For the content of a good PR description, see core/git-workflow §5.
gh pr createops_enabled=false — do not create PRs, report the intended PR as a follow-upops/git-remote)Before gh pr create:
main, but some repos use develop or similarIf the repo has a PR template (.github/pull_request_template.md), gh pr create will load it. Do not blank it out. Fill every section the template requests. Empty templates are a contributor smell.
If there is no template, the PR body should still cover:
Use a draft PR when:
Mark it ready for review (gh pr ready) only when you would be comfortable with it merging as-is.
When a reviewer leaves a comment, each kind gets a specific response:
<sha>") and resolve the threadNever close a thread without acknowledgment. Never ignore a Critical comment. Never merge with unresolved Critical threads.
Three common options:
| Strategy | Use when | Avoid when |
|---|---|---|
| Squash | Many small "wip" commits on the feature branch | You would lose meaningful history by squashing |
| Merge commit | Feature branch has coherent history worth keeping | A single logical change that should be one commit |
| Rebase and merge | Linear-history policy; commits are all clean | Shared branch where rebase would break references |
Match the repo's convention first. Only diverge with team agreement.
gh pr merge --delete-branch or manually)| Shortcut | Reality |
|---|---|
"I'll just gh pr create --title 'fix'." | Lazy titles become lazy merge commits. Invest 30 seconds. |
| "The template is optional." | The template is the team's communication contract. Fill it. |
| "I'll respond to review comments later." | Review freshness decays fast. Respond within the day or unassign. |
| "I disagree with the nitpick but it's not worth arguing." | Then just do it. Silent disagreement wastes both people's time. |
| "Squash is always safe." | Squash loses bisect-useful history when a branch has meaningful intermediate commits. |
gh pr merge --admin used to bypass review requirements (bypass is a last resort, not a default)ops_enabled=true confirmed in session context before any PR-creation commandops_enabled=false: the PR is reported as a follow-up, not created