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/slicenpx 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.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.00034 | $0.02090 |
| Opus 5 | $0.00017 | $0.01045 |
| Sonnet 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 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 — 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.
- 4d ago First seen · 174 lines · 34 tokens per session scan A 4a62888ff567
slice is a skill published in the GitHub repository thoughtbot/rails-consultant (23 stars, last pushed 1mo ago), licensed MIT. It adds 34 tokens to every session and 2,090 once invoked, about $0.0002 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
kb-mastodon
Background knowledge about Mastodon, the dominant federated microblogging platform and de facto reference implementation for ActivityPub social networking. Covers Mastodon's JSON-LD @context structure (three-element array: activitystreams, security/v1, inline object defining toot: http://joinmastodon.org/ns# with…
create-epics
Translate approved GDDs + architecture into epics — one epic per architectural module. Defines scope, governing ADRs, engine risk, and untraced requirements. Does NOT break into stories — run /create-stories [epic-slug] after each epic is created.
soak-test
Generate a soak test protocol for extended play sessions. Defines what to observe, measure, and log during long play sessions to surface slow leaks, fatigue effects, and edge cases that only appear after sustained play. Primarily used in Polish and Release phases.
unity-platforms
Unity 6 platform targeting and build guide. Use when building for specific platforms, configuring build profiles, using platform scripting defines (#if UNITYIOS, #if UNITYANDROID), optimizing for mobile, WebGL, or consoles, working with Addressables/asset bundles, or choosing between IL2CPP and Mono. Based on Unity…
uw-unity-feature-scaffold
Create a complete feature module with folder structure, Assembly Definition (.asmdef), test assembly, and namespace. Use when adding a new feature, system, or module to a Unity project. Triggers on requests like "create a new feature", "scaffold a module", "add a combat system", "I need a health system", "set up…
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…