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 feature-devgit 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/feature-dev)<a href="https://agentmods.dev/skills/thoughtbot/rails-consultant/feature-dev"><img src="https://agentmods.dev/badge/skills/thoughtbot/rails-consultant/feature-dev/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/feature-dev"><img src="https://agentmods.dev/badge/skills/thoughtbot/rails-consultant/feature-dev.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Rogue Agent · line 79 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
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.00083 | $0.03911 |
| Opus 5.5 | $0.00033 | $0.01564 |
| Sonnet 5.5 | $0.00017 | $0.00782 |
| Haiku 4.5 | $0.00008 | $0.00391 |
Grade A, and why
feature-dev 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 — 170 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Feature Development
You are helping a developer take one feature slice from a rough idea to reviewed, committed code. This is not autonomous coding — it's a guided workflow that borrows its backbone from systematic feature development but threads four disciplines through it: slicing to define the work, TDD to build it, code review to harden it, and a clean commit to land it.
The workflow's whole reason for existing is to resist the pull toward premature code. Each phase earns the right to the next: you don't slice until you understand the feature, you don't build until the slice is sharp, you don't consider it done until the diff has been reviewed, and you don't commit until it's green. Hold that line — the value is in the sequence, not any single step.
Scope discipline: this workflow refines and builds exactly one slice. If the work is actually an epic — several independently shippable pieces — you'll surface that during framing and help the user pick the single slice to build now. Building more than one slice in a pass defeats the point; the payoff is a tight loop of shape → build → review on a small, real increment.
Leanness discipline: a small slice does not guarantee a small diff. Slicing controls what ships; it does nothing to stop the implementation from bloating with speculative abstractions, options nothing uses yet, defensive branches no test demands, or gold-plating. Those are a separate failure mode, and this workflow fights them separately. The target is a production-code diff under ~300 lines (excluding comments and blank lines; test code does not count against this ceiling, though bloated tests are their own smell). Treat that number as a design constraint you carry from Phase 3 onward, not a gate you discover at the end.
Use TodoWrite to track the phases so the user can see where they are.
Phase 1: Frame the work
Goal: understand what the user wants to build, and confirm it's a single slice before investing in anything else.
What ships with it
2 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 · 170 lines · 83 tokens per session scan A a9d394ff2ffd
feature-dev is a skill published in the GitHub repository thoughtbot/rails-consultant (26 stars, last pushed 1mo ago), licensed MIT. It adds 83 tokens to every session and 3,911 once invoked, about $0.0003 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
abd-test
ABD Testing agent: auto-detects the test framework, writes tests matching project style, runs the suite, and records a test artifact.
generate-tasks
Phase 3 of 5 — slices the ARCH doc into verification-ready task specs (tdd/test-after/ui/checklist), emitted as a separate TASKS- - .md file alongside ARCH for the implement skill. Use only when the user asks to run Phase 3 or generate tasks from an ARCH doc — never trigger automatically.
unity-testing
Unity 6 testing guide. Use when writing unit tests, integration tests, or doing TDD with Unity Test Framework. Covers Edit Mode and Play Mode tests, NUnit attributes ([Test], [UnityTest], [SetUp], [TearDown]), testing MonoBehaviours and coroutines, and CI/CD integration. Based on Unity 6.3 LTS documentation.
uw-code-review
Pre-commit code quality review for Unity C# code. Checks against Rules, CODINGSTANDARDS.md, NAMINGCONVENTIONS.md, and GDD Gherkin test coverage. Use when code has been written and tests are passing but before committing. Runs automatically at Step 8.5 of /uw-cmd-implement-feature. Triggers on "review this code"…
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.
phx-work
Execute Elixir/Phoenix plan tasks with progress tracking. Use after phx-plan to implement features with mix compile and mix test verification after each step, or --continue to resume interrupted work.