What problem does this solve?
When using finishing-a-development-branch to create a GitHub PR, the skill does not explicitly tell the agent to check GitHub-supported PR template locations before drafting or opening the PR.
Many GitHub repositories treat these files as required process, not optional formatting. They often define required fields for testing evidence, issue links, rollout notes, risk assessment, reviewer context, contributor disclosure, or human review.
The failure mode is that the agent can complete development work correctly, reach the PR creation step, and then produce a PR body that violates the repository's GitHub contribution standards.
Proposed solution
Update finishing-a-development-branch so that the GitHub PR path checks GitHub-recognized PR template locations before creating the PR.
The skill should look for PR templates in GitHub-supported locations.
pull_request_template.mddocs/pull_request_template.md.github/pull_request_template.mdPULL_REQUEST_TEMPLATE/*.mddocs/PULL_REQUEST_TEMPLATE/*.md.github/PULL_REQUEST_TEMPLATE/*.md
The filename check should be case-insensitive. The skill should also accept GitHub-supported PR template extensions such as .md and .txt.
If a PR template exists, the agent should read it and use it as the PR body source. It should fill required sections with real information, not placeholders.
If multiple PR templates exist, the agent should stop and ask which one applies unless the target template is already known.
If required information is missing, the agent should stop and ask the human partner before opening the PR.
If no GitHub PR template the skill can fall back to a generic PR body.
What alternatives did you consider?
One alternative is to rely on each repository to mention this in agent instructions. That is weaker because the finishing skill is the point where the PR is actually prepared.
Another alternative is to keep the guidance forge-neutral and include files such as CLAUDE.md or AGENTS.md. That is broader, but it is not what this issue is asking for. This issue should be limited to GitHub-supported PR template.
Another alternative is to rely on GitHub's web UI to insert the template automatically. That does not cover CLI-created PRs or agents that draft the PR body before opening GitHub.
Is this appropriate for core Superpowers?
Yes.
This is a general GitHub workflow issue. It is not specific to this repository, a domain, or a team workflow. It would benefit any user finishing a development branch in a GitHub repository that uses PR templates.
Environment (required)
| Field |
Value |
| Superpowers version |
6.0.3 |
| Harness (Claude Code, Cursor, etc.) |
Claude Code |
| Harness version |
claude --version 2.1.186 (Claude Code) |
| Your model + version |
global.anthropic.claude-sonnet-4-6 |
| All plugins installed |
No additional plugins shown. superpowers-marketplace core skills enabled. |
Context
This came up while preparing an issue for obra/superpowers after noticing that finishing-a-development-branch does not explicitly direct agents to use GitHub PR template conventions.
This repository is a concrete example because it has strict PR requirements. The underlying issue is broader. Many GitHub repositories use PR templates as required contribution workflow.
What problem does this solve?
When using
finishing-a-development-branchto create a GitHub PR, the skill does not explicitly tell the agent to check GitHub-supported PR template locations before drafting or opening the PR.Many GitHub repositories treat these files as required process, not optional formatting. They often define required fields for testing evidence, issue links, rollout notes, risk assessment, reviewer context, contributor disclosure, or human review.
The failure mode is that the agent can complete development work correctly, reach the PR creation step, and then produce a PR body that violates the repository's GitHub contribution standards.
Proposed solution
Update
finishing-a-development-branchso that the GitHub PR path checks GitHub-recognized PR template locations before creating the PR.The skill should look for PR templates in GitHub-supported locations.
pull_request_template.mddocs/pull_request_template.md.github/pull_request_template.mdPULL_REQUEST_TEMPLATE/*.mddocs/PULL_REQUEST_TEMPLATE/*.md.github/PULL_REQUEST_TEMPLATE/*.mdThe filename check should be case-insensitive. The skill should also accept GitHub-supported PR template extensions such as
.mdand.txt.If a PR template exists, the agent should read it and use it as the PR body source. It should fill required sections with real information, not placeholders.
If multiple PR templates exist, the agent should stop and ask which one applies unless the target template is already known.
If required information is missing, the agent should stop and ask the human partner before opening the PR.
If no GitHub PR template the skill can fall back to a generic PR body.
What alternatives did you consider?
One alternative is to rely on each repository to mention this in agent instructions. That is weaker because the finishing skill is the point where the PR is actually prepared.
Another alternative is to keep the guidance forge-neutral and include files such as
CLAUDE.mdorAGENTS.md. That is broader, but it is not what this issue is asking for. This issue should be limited to GitHub-supported PR template.Another alternative is to rely on GitHub's web UI to insert the template automatically. That does not cover CLI-created PRs or agents that draft the PR body before opening GitHub.
Is this appropriate for core Superpowers?
Yes.
This is a general GitHub workflow issue. It is not specific to this repository, a domain, or a team workflow. It would benefit any user finishing a development branch in a GitHub repository that uses PR templates.
Environment (required)
claude --version2.1.186 (Claude Code)global.anthropic.claude-sonnet-4-6superpowers-marketplacecore skills enabled.Context
This came up while preparing an issue for
obra/superpowersafter noticing thatfinishing-a-development-branchdoes not explicitly direct agents to use GitHub PR template conventions.This repository is a concrete example because it has strict PR requirements. The underlying issue is broader. Many GitHub repositories use PR templates as required contribution workflow.