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 agentmods add skills/jetbrains/thinkrail/brainstormingnpx skills add JetBrains/thinkrail --skill brainstorminggit 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/brainstorming)<a href="https://agentmods.dev/skills/jetbrains/thinkrail/brainstorming"><img src="https://agentmods.dev/badge/skills/jetbrains/thinkrail/brainstorming.svg" alt="Measured on agentmods" height="20"></a>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 | $0.00065 | $0.01279 |
| Opus 5 | $0.00032 | $0.00639 |
| Sonnet 5 | $0.00013 | $0.00256 |
| Haiku 4.5 | $0.00006 | $0.00128 |
Grade A, and why
brainstorming 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 4d 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 — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Brainstorming
Brainstorm before you build
- Before starting any creative or feature work — a new feature, added functionality, a behavioral change, a nontrivial design decision — stop and run this workflow before writing implementation code.
- The aim: turn the request into a validated design, recorded as a spec-graph
task-spec, that the user has explicitly approved — not a guess you implement and hope lands. - Never implement during brainstorming. If you catch yourself opening a source file to make a change before the design is approved, stop.
Anti-pattern: "this is too small to need this"
Every request goes through this, however small it looks. A one-line config change and a new subsystem both benefit from a few minutes of "what does the user actually want and why" — that is where wrong assumptions get caught cheaply. Scale the depth to the task; never skip the workflow entirely.
The workflow
- Orient. Use the spec-graph skill's tools first —
spec_grep/spec_get/spec_graph— to find what the project already says about the area; read code second, to confirm details. - Scope check. If the request bundles multiple independent features or subsystems, say so and brainstorm them one at a time (or in parallel sub-sessions, the user's call) — don't blend unrelated decisions into one task-spec.
- Open a task-spec. As soon as you understand roughly what's being asked,
spec_createatask-specat.thinkrail/context/TASK-<slug>.md(id, title, status: draft, parent: the nearest relevant module) to hold the design as it develops..thinkrail/context/is the workspace's gitignored scratch dir (host-seeded, zero git footprint) yet stays scannable by the spec tools — the home for every temp doc, never committed. This file is the one artifact — update it live as decisions land; don't also keep a separate scratch doc. This works even in a project with no existing spec graph: atask-speconly needs frontmatteridandtypeto be a valid spec, no pre-existing graph required — don't skip this step just because nothing else in the project is specced yet. - Clarify. Ask what you need via
ask_user_question, composing rounds per the asking-user-questions concept skill — read it before the first round. Resolve a full round, update the task-spec with what you learned, and only open a new round if the answers raised a genuinely new question. Per that concept's degradation norms, skipped questions or a host with no UI are not blockers: record your best-guess assumptions in the task-spec, explicitly marked unconfirmed, and continue. - Propose approaches. Once the ask is clear, write 2-3 approaches into the task-spec with
trade-offs and a recommendation. When approaches are easiest to compare side by side, ask via a
single-select
ask_user_questionwith each approach as an option (label = approach name, description = its trade-off) instead of prose alone. - Present the design. Write it into the task-spec in sections scaled to their complexity; confirm with the user as each section lands, not only at the end.
- Self-review. Before asking for final sign-off, reread the task-spec for: placeholders/TBDs, sections that contradict each other, scope that's actually multiple task-specs, and ambiguous requirements — fix what you find, don't just flag it.
- Promote. When the design settles a boundary, contract, or decision that belongs in a durable
spec, fold it into the relevant module's
SPEC.mdnow —spec_createfor a new module,spec_updatefor its frontmatter (draft → active as it firms up),editfor prose. Runspec_validateafter structural changes. - Final review, then build. Ask the user to review the (now-promoted) design once more. Once approved, implement directly against it — there is no separate plan-writing step here. Before handing off, self-review the implementation diff the way step 7 reviewed the spec: no silent lint/type suppressions (a gate error is a design signal — question the flagged state or dependency before guarding it; any genuinely-needed suppression gets explicit user sign-off first), no nontrivial derivation duplicated across files (centralize it), no rationale left as code comments (near-zero comments: decisions and invariants go to the owning spec per the writing-specs bar; only lint directives and rare one-line hazard notes survive), and when the change replaced a pattern, sweep the repo for remnants of the old one. Keep the task-spec and the durable specs honest as the code lands, and retire the task-spec once the work itself is done, not merely once the design was promoted.
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.
- 4d ago First seen · 76 lines · 65 tokens per session scan A 0b41801cc92b
brainstorming is a skill published in the GitHub repository JetBrains/thinkrail (412 stars, last pushed today), licensed Apache-2.0. It adds 65 tokens to every session and 1,279 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
goal-oriented
MUST use for ANY user request. This is a rigid requirement that applies to all tasks and conversations.
planning
MUST use after prompt-enhancer. Create implementation plan with MECE decomposition, dependency analysis, risk assessment, and mandatory plan-review.
mvp-first
Use when user requests complex systems involving multiple modules or subsystems - like 'build a XX system', 'design XX architecture', or 'implement XX with multiple features'. Triggers to prevent over-engineering before validating core assumptions.
ddd-tactical-design
Use when implementing domain logic, designing aggregates, entities, value objects, repositories, domain services, domain model design, ensuring data consistency, or when user mentions 'aggregate design', 'aggregate root', 'entity vs value object', 'domain event', 'repository pattern', 'domain service', 'data…
prompt-enhancer
MUST use before task execution. Clarify vague requirements, explore solutions, and ensure full understanding.
swot-analysis
Use when analyzing strengths/weaknesses/opportunities/threats, strategic planning, decision-making support, problem diagnosis, or when user mentions 'SWOT', '优劣势分析', '战略分析', '机会威胁', '态势分析', '战略规划', '竞品分析', '技术选型', '方案对比', '风险评估', '项目立项', '决策支持'.