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 thoughtbot/rails-consultant --skill slicegit 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/slice)<a href="https://agentmods.dev/skills/thoughtbot/rails-consultant/slice"><img src="https://agentmods.dev/badge/skills/thoughtbot/rails-consultant/slice/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/thoughtbot/rails-consultant/slice"><img src="https://agentmods.dev/badge/skills/thoughtbot/rails-consultant/slice.svg" alt="Reviewed on agentmods" width="80" 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.00034 | $0.02090 |
| Opus 5.5 | $0.00014 | $0.00836 |
| Sonnet 5.5 | $0.00007 | $0.00418 |
| Haiku 4.5 | $0.00003 | $0.00209 |
Grade A, and why
slice 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 1mo 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 — 174 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Phase 1: Understand the Work
If no feature is specified, open with:
"What are you building? Describe the feature or capability — big or small."
Wait for their answer before proceeding.
Once the feature is known, ask three things — conversationally, not as a form:
"Before we slice this, I need to understand it. Three things:
Who is this for — specifically? Not 'users', but which person, in which moment, with which need.
What does done look like? When this ships, what can that person do that they can't do today?
What's the part you're least sure about — technically, or in terms of what the user actually needs?"
Wait for their answers. Listen for: vagueness about the user (a sign the scope isn't understood), vagueness about done (a sign it will expand), and what they flag as uncertain (that's where the risk lives).
If their answers are vague, ask one follow-up before moving on. Do not proceed to slicing on work you don't understand.
Ground it in the codebase — when there is one
Slices invented in the abstract ignore reality. In an existing app, the right cut depends on what's already there: half of it may exist already, the layers it touches may already have the abstractions it needs, and the edge cases worth putting in acceptance criteria are the ones this domain actually has, not the ones you can imagine.
Skip this step entirely when it doesn't apply:
- The conversation already carries a codebase map. If you arrived here from
/feature-dev, its Phase 2 has already done this work — use what it found and move on. Never explore the same ground twice. - There's nothing to explore. Greenfield work, a brand-new app, or a feature that touches no existing behavior. Same for a product-shaped conversation where no repo is in play.
Otherwise, match the effort to the feature. For a small change in familiar territory, a few targeted reads inline are enough. For anything spanning layers or touching code you don't know, launch 2–3 general-purpose subagents in parallel (via the Agent tool) — give each the brief in references/slice-explorer.md plus a different angle to cover:
What ships with it
4 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.
- 1mo ago First seen · 174 lines · 34 tokens per session scan A 4a62888ff567
slice is a skill published in the GitHub repository thoughtbot/rails-consultant (26 stars, last pushed 1mo ago), licensed MIT. It adds 34 tokens to every session and 2,090 once invoked, about $0.0001 per session on Opus 5.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
csift
Reads, searches and counts Claude Code session transcripts (the .jsonl files under /.claude/projects, subagents too) with the csift command-line tool, and ships hooks that re-inject compacted turns or record pending questions. Use when asked what a past or running session said, did, edited, spent or is doing now; when…
recursive-decomposition
Decompose dense codebase-wide, multi-document, PDF, and aggregation work even when the input fits the context window, following Recursive Language Models (Zhang, Kraska, Khattab, 2025). Use when the user asks to analyse all files, a whole repo, all docs, large PDFs, or to aggregate or multi-hop across scattered…
flows
This skill should be used when designing CrewAI Flows with typed state management, deterministic routing, and event-driven orchestration. Use it for flow architecture, state transitions, control primitives, and production deployment.
core-build
This skill should be used when designing CrewAI crews with YAML-first architecture. Use it to create crews, configure agents and tasks, select processes, and generate validation-ready outputs.
tools-expert
This skill should be used when selecting CrewAI built-in tools, composing agent toolchains, or creating production-ready custom tools with BaseTool or @tool, including schema validation, dependency management, caching, async support, and testing.
orchestration-governance
Governance skill for orchestrating CrewAI specialists with strict ownership, skill boundaries, and execution permissions.