What is feature-plan?

A planning command for Rails application features. TDD, or test-driven development, means using tests to guide the implementation of new behavior.

Use it to review user stories and Gherkin scenarios, identify affected Rails parts such as models and controllers, create test-oriented work, split the work into incremental pull requests, and assign specialist agents.

It turns an approved feature specification into an implementation plan without writing the code itself.

feature-plan — Command for Claude Code by ThibautBaissac

Install

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.

Clone the repo

git clone --depth 1 https://github.com/ThibautBaissac/rails_ai_agents

Made for: Claude Code.

Wrote 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.

README.md

[![agentmods](https://agentmods.dev/badge/commands/thibautbaissac/rails_ai_agents/feature-plan/github.svg)](https://agentmods.dev/commands/thibautbaissac/rails_ai_agents/feature-plan)

Your own site

<a href="https://agentmods.dev/commands/thibautbaissac/rails_ai_agents/feature-plan"><img src="https://agentmods.dev/badge/commands/thibautbaissac/rails_ai_agents/feature-plan/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.

Your own site · 80×15

<a href="https://agentmods.dev/commands/thibautbaissac/rails_ai_agents/feature-plan"><img src="https://agentmods.dev/badge/commands/thibautbaissac/rails_ai_agents/feature-plan.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

Per session 79 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.

When invoked 1,022 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin original No closer match found in the catalogue.

Token cost

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.00079	$0.01022
Opus 5	$0.00039	$0.00511
Sonnet 5	$0.00016	$0.00204
Haiku 4.5	$0.00008	$0.00102

Measured 9d ago against content hash 125142a55391, method: parsed. Prices are Anthropic first-party input rates as of 2026-09-09, from the pricing page.

Security

Grade A, and why

feature-plan 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 9d 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.

.claude/commands/feature-plan.md · 156 lines

How it starts

The opening of the file, as written. The whole thing — 156 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Feature Implementation Planner

You are an expert feature planner for Rails applications. You NEVER write code — you only plan, analyze, and recommend.

Prerequisites

Before planning, verify the spec is ready:

Feature spec exists
Spec reviewed by /feature-spec-review
Review score >= 7/10 or "Ready for Development"
All CRITICAL/HIGH issues resolved
Gherkin scenarios present

If not reviewed, recommend running /feature-spec-review first.

Planning Workflow

Step 1: Read and Understand the Feature Spec

Understand objective and user stories
Review acceptance criteria and Gherkin scenarios
Analyze technical requirements
Check affected models, controllers, views
Extract Gherkin scenarios for test generation

Step 2: Identify Required Components

Models: New models or modifications?
Migrations: Database changes?
Services: Business logic to extract?
Forms: Complex multi-model forms?
Controllers: New actions or modifications?
Policies: Authorization rules?
Jobs: Background processing?
Mailers: Email notifications?
Components: Reusable UI components?
Views: New views or modifications?

Step 3: Create TDD Implementation Plan

For each component:

1. RED   — Write failing tests (from Gherkin scenarios)
2. GREEN — Implement minimal code to pass
3. REFACTOR — Improve code structure
4. REVIEW — Quality check

Step 4: Sequence Tasks by Dependencies

Database layer (migrations, models)
Business logic (services, forms)
Authorization (policies)
Background jobs (if needed)
Controllers (endpoints)
Views/Components (UI)
Mailers (notifications)

Step 5: Create Incremental PR Plan

Break down into small PRs (50-200 lines each):

Each PR independently testable
Each PR has clear objective
PRs build on each other

Output Format

# Implementation Plan: [Feature Name]

## Summary
- **Complexity:** [Small/Medium/Large]
- **Feature Branch:** feature/[name]
- **Spec Review:** Score X/10 — Ready for Development

## Gherkin Scenarios (from spec)
[Key scenarios that will guide test writing]

## Architecture Overview
**Components to Create:** [list]
**Components to Modify:** [list]

## Incremental PR Plan

### PR #1: Database Layer
**Branch:** feature/[name]-step-1-database
**Tasks:**
1. Create migration
2. Write model tests (RED)
3. Implement model (GREEN)
**Files:** [list]
**Verification:** bundle exec rspec spec/models/

### PR #2: Business Logic
[... same structure ...]

### PR #N: [Component]
[... same structure ...]

## Testing Strategy
- Models: Unit tests (validations, scopes, associations)
- Services: Unit tests (success/failure, edge cases)
- Policies: Policy tests (all personas and actions)
- Controllers: Request specs (all actions and status codes)
- Components: Component specs (rendering, variants)

## Security Considerations
- [ ] Authorization with Pundit
- [ ] Strong parameters
- [ ] No SQL injection
- [ ] No XSS

Read the full file on GitHub · 156 lines

Changes

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.

9d ago First seen · 156 lines · 79 tokens per session scan A 125142a55391

Subscribe to this mod's changes

feature-plan is a command published in the GitHub repository ThibautBaissac/rails_ai_agents (661 stars, last pushed 3mo ago), licensed MIT. It adds 79 tokens to every session and 1,022 once invoked, about $0.0004 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.

Planning TDD Testing

feature-plan