Shipping A PR
Use when finished work needs to ship as a pull request, or when creating, syncing...
Install
npx skills add JetBrains/thinkrail --skill shipping-a-pr -g -a claude-code -y- Repository
- JetBrains/thinkrail7k
- Category
- Git and review
- Updated
- 3d ago
- License
- Apache-2.0
- Context cost
- Lightabout 1,011 tokens
- Runs scripts
- No, instructions only
What it does
Use when finished work needs to ship as a pull request, or when creating, syncing, updating metadata, checking status, monitoring CI, or addressing review comments on a PR. Not for reviewing a PR you are not shipping.
Shipping a PR
The PR lifecycle: ship the workspace's finished work, maintain PR metadata, and keep the PR healthy when requested. One workflow, six phases as sibling docs, enter at the phase the ask names.
Completion modes
- Snapshot mode is the default for creating, syncing, or updating a PR and for one-time status requests. Take one fresh checks and merge-state snapshot, report pending/failing/indeterminate state as observed, and stop without polling or fixing unrelated state. A push never upgrades the mode by itself.
- Wait mode requires an explicit remote-completion ask: monitor or watch checks, investigate CI, wait until green, or make the PR merge-ready. Done means every configured check is green, the head is current with its base, and GitHub reports an affirmative merge state; a requested draft is reported as draft, never merge-ready. A repo with no CI is reported as exactly that, never silently green.
Observed, never assumed (applies to every phase)
Git and GitHub state is concurrent and mutable: the base moves, CI lags, mergeability is computed lazily, and this workflow's own steps dirty the tree they just checked. Four rules hold at every step of every phase:
