| name | file-pr |
| description | Commits and pushes the current in-scope work and opens a ready-for-review pull request with an outcome-focused title and explanation. Use for any request that the work should end in a PR, however hedged — "file the PR", "I think we might file a PR", "we can create a PR based on this", "let's PR it". |
File PR
The request authorizes one in-scope commit, one push, and one PR. Review the complete diff against the user's goal and exclude unrelated working-tree changes. Check whether the branch already has a PR; if it does, report it instead of creating or modifying anything.
Use a base branch specified by repository guidance or the user. Otherwise inspect the remote default branch and recent PRs; do not assume that every repository uses development.
Title
Write a concise, human-readable title that explains why the change matters. Follow the repository's title convention, but do not lead with a mechanical inventory of implementation details.
Bad — names the artifact without communicating why it matters:
add weekly Slack product report
Better — makes the outcome useful to the reader:
Send the team a weekly product health snapshot in Slack
Description
Open with the user's problem and its impact, then explain the solution. For a bug fix, include:
- what was wrong;
- the root cause;
- why the solution addresses the cause and is the right scope;
- a percentage confidence score with a brief reason.
For several fixes, organize the description by problem and give each meaningful fix the same context. Describe behavioral evidence when it explains why the solution is correct.
Bad — leads with an implementation and validation inventory:
## What changed
- add a production-only Monday 09:05 UTC cron
- report marketing, app, SEO, and blog visitors from PostHog
- report registrations, uploads, and public-tool usage from PostgreSQL
- add a preview-first manual report command and focused tests
## Validation
- lint and typecheck passed
- focused tests passed
- git diff check passed
Better — starts with the team problem, then explains the design and confidence:
Product activity is split between PostHog and PostgreSQL, so the team has no consistent weekly view of whether acquisition and product usage are moving together.
This adds one Monday Slack report for the previous complete UTC week. PostHog supplies visitor activity, PostgreSQL supplies registrations, uploads, and published documents, and a dedicated read-only PostHog token keeps reporting access separate from the public ingestion key. Production-only scheduling prevents duplicate reports while the preview path makes metric changes inspectable before sending.
Confidence: 95% — a production-backed preview returned the expected metrics and the complete report reached the intended Slack channel. The remaining risk is future drift in metric definitions, not delivery or scheduling.
Do not add a Verification, Testing, Checks, or CI section. Do not list test commands, lint, typecheck, regression suites, or CI results; CI already exposes that information.
Follow the repository's own description skeleton when its recent PRs show one (for example ## Problem / ## Solution / ## Confidence); never fall back to a ## What changed inventory.
Always write the body to a temp file and pass --body-file to gh pr create/gh pr edit; an inline --body gets mangled by the shell (backticks execute, newlines escape).
Create once
Open a ready-for-review PR so automated reviewers run. Create a draft only when the user explicitly requests one.
After creating the PR, do not push again, amend commits, edit the PR, post comments, or reply to reviews without a fresh instruction. If the user also asked to babysit it, continue with the babysit-pr skill.
