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/thoughtbot/rails-consultant/challengenpx skills add thoughtbot/rails-consultant --skill challengegit clone --depth 1 https://github.com/thoughtbot/rails-consultantWrote 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/thoughtbot/rails-consultant/challenge)<a href="https://agentmods.dev/skills/thoughtbot/rails-consultant/challenge"><img src="https://agentmods.dev/badge/skills/thoughtbot/rails-consultant/challenge.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.1 | $0.00028 | $0.00613 |
| Opus 5 | $0.00014 | $0.00307 |
| Sonnet 5 | $0.00006 | $0.00123 |
| Haiku 4.5 | $0.00003 | $0.00061 |
Grade A, and why
challenge 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 6d 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 — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Behavior
This is a conversation, not an audit. Do not produce structured output. Do not list findings upfront. Start by understanding what they actually believe — then follow the thread with one question at a time.
If you already have context — from a prior skill, from the conversation, or from something specific the user said — name the assumption you want to pressure-test and why. Then go straight to questioning. Do not ask them to restate what you already know.
If you do not have context, ask one plain question to surface the assumption before proceeding.
Ask one question at a time, following the gaps in their reasoning. The goal is to make them interrogate the assumption themselves before you weigh in. Good questions to reach for:
On origin:
- "Where did this belief come from — your own experience, a previous project, something you read, or something someone told you?"
- "Is this a Rails convention, or did you choose it consciously?"
- "Have you actually tested this, or is it untested instinct?"
On necessity:
- "What's the underlying need — if you strip away the solution, what problem must be solved?"
- "Is this the simplest thing that could work, or are you solving for complexity that doesn't exist yet?" (Beck / XP)
- "Are you building for now, or for a future that might not arrive?" (YAGNI)
On validity:
- "Under what conditions would this assumption be wrong?"
- "What evidence would change your mind?"
- "Is this cargo-culting — doing it because it's familiar — or is there a real reason?"
On alternatives:
- "What's the simplest alternative you haven't seriously considered?"
- "If you couldn't do it this way, what would you do?"
- "What does Rails already give you that makes this unnecessary?" (convention over configuration)
Have opinions. When an assumption is weak, say so and say why.
When the assumption has been turned over enough — either they've found the weakness themselves, or it's clear they won't without a push — give your verdict directly. Is the assumption valid, partially valid, or worth rejecting? Name the underlying need, name the better path if there is one, and say why.
Close with:
"Did you already suspect this assumption was wrong — or did you genuinely believe it until now?"
Wait for their answer. Respond with one short paragraph: what their answer reveals about how they form and hold assumptions under pressure, and whether they're more likely to inherit bad decisions or make them consciously.
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.
- 6d ago First seen · 54 lines · 28 tokens per session scan A 875e0dbf4a00
challenge is a skill published in the GitHub repository thoughtbot/rails-consultant (24 stars, last pushed 1mo ago), licensed MIT. It adds 28 tokens to every session and 613 once invoked, about $0.0001 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
recursive-decomposition
Handle tasks that exceed the context window by decomposing them: size and filter the input, chunk it, run recursive sub-agents on independent parts, verify on small windows, and synthesise programmatically, following the Recursive Language Models (RLM) research by Zhang, Kraska and Khattab (2025). Use when a task…
swarm
Run a multi-agent audit of a codebase by spawning specialized parallel subagents (security, performance, tests, architecture, dead-code), then synthesize their findings into a single prioritized action plan. Use this whenever the user runs /swarm, asks to "audit the repo," "review this codebase," "find issues across…
tools-unity-behavior-designer
Behavior Designer patterns for AI behavior trees including task creation, shared variables, conditionals, and debugging.
tools-unity-gameplay-ability-system
Gameplay Ability System patterns for abilities, effects, attributes, and tags including recursion safety and lifecycle management.
eng-unity-mobile-optimization
Mobile-specific Unity optimization patterns for memory, battery, thermal, and performance.
tools-unity-flowcanvas
FlowCanvas visual scripting patterns for abilities, custom nodes, and graph execution.