JetBrains/thinkrail is a desktop and mobile client that embeds the pi coding agent inside an interface for editing code and managing development workspaces. Developers use it to work on Git repositories through separate worktrees, a Monaco editor, terminals, Git views, specifications, and concurrent agent sessions. The catalogue entries are skills and instructions for its agent-based development workflow.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add JetBrains/thinkrail --skill shipping-a-prgit clone --depth 1 https://github.com/JetBrains/thinkrailWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/jetbrains/thinkrail/shipping-a-pr)<a href="https://agentmods.dev/skills/jetbrains/thinkrail/shipping-a-pr"><img src="https://agentmods.dev/badge/skills/jetbrains/thinkrail/shipping-a-pr.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00057 | $0.00753 |
| Opus 5 | $0.00028 | $0.00377 |
| Sonnet 5 | $0.00011 | $0.00151 |
| Haiku 4.5 | $0.00006 | $0.00075 |
Grade A, and why
shipping-a-pr scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 9d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Shipping a PR
The PR lifecycle: ship the workspace's finished work as a pull request and keep that PR healthy until it is mergeable. One workflow, five phases as sibling docs — enter at the phase the ask names.
The done bar (applies to every phase)
A PR is done when every check it has is green — a repo with no CI is reported as exactly
that, never silently treated as green — and the user has the link plus its current state; never at
"PR opened", "pushed", or "comment replied". Every phase below therefore ends in checks.md,
which declares this workflow's terminal state.
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. Three rules hold at every step of every phase:
- Verify at the point of action. An irreversible step — push,
gh pr create,gh pr edit, replying to a thread, declaring done — re-checks the exact state it consumes immediately before running. A gate passed earlier does not survive the mutations made since it passed. - Fetch, don't remember. Remote state is read fresh and completely at the moment it's needed:
the current body before editing it,
--paginateon every listing,git fetchbefore reasoning about the base. - Indeterminate is not affirmative. A pending or still-computing answer (an
UNKNOWNmerge state, queued checks) is polled until it resolves; done is declared only from observed affirmative state, never from the absence of a bad signal.
Classify the ask
| The ask | Phase doc |
|---|---|
| Create a PR — the work is finished | creating.md |
| Bring the PR up to date / resolve conflicts with its base | syncing.md |
| Add or refresh screenshots on a PR | screenshots.md |
| Monitor CI / investigate or fix failing checks | checks.md |
| Address review comments | review-comments.md |
Read and follow the selected phase doc — the gates and mechanics live only there; never run a phase from this spine's summary. A compound ask ("rebase, verify, and create a PR") is one flow: start at the earliest phase named; the docs chain forward on their own. If the work itself isn't finished — the ask bundles new design or implementation before the ship — that part is not this workflow's; route it per choosing-a-workflow first and come back here when it lands.
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 9d ago First seen · 63 lines · 57 tokens per session scan A fba5e6274c2d
shipping-a-pr is a skill published in the GitHub repository JetBrains/thinkrail (427 stars, last pushed today), licensed Apache-2.0. It adds 57 tokens to every session and 753 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
commit
Atomic git commit with conventional message. Use when the user says "commit", "save my changes", "commit this", or wants to create a git commit. Stages specific files, writes a conventional commit message with body explaining non-obvious decisions. Never uses git add -A.
vigilante-issue-implementation
Implement a GitHub issue end-to-end when Vigilante dispatches work for a watched repository. Use the provided worktree, respect repository instructions, comment on the issue as work progresses, and report failures back to GitHub.
vigilante-issue-implementation-on-bazel-monorepo
Implement a GitHub issue end-to-end when Vigilante dispatches work for a Bazel-based monorepo. Use the provided worktree, respect repository instructions, comment on the issue as work progresses, and report failures back to GitHub.
vigilante-issue-implementation-on-monorepo
Implement a GitHub issue end-to-end when Vigilante dispatches work for a watched monorepo. Use the provided worktree, respect repository instructions, comment on the issue as work progresses, and report failures back to GitHub.
vigilante-issue-implementation-on-go
Implement a GitHub issue end-to-end when Vigilante dispatches work for a Go repository with idiomatic tooling and security guidance.
vigilante-issue-implementation-on-ruby
Implement a GitHub issue end-to-end when Vigilante dispatches work for a Ruby repository with Bundler, test, lint, and security guidance.