feature-dev

Name: feature-dev
Author: thoughtbot

15stars1forks

How to install feature-dev?

thoughtbot/rails-consultant/feature-dev

$npx -y skills add thoughtbot/rails-consultant --skill feature-dev

Installs into the current project.

Summary

Take one new feature slice from idea to reviewed, committed code in a single guided pass — scope it into the smallest shippable slice, build it test-first with strict TDD, review and fix the diff, then commit it. Chains slice → test-driven-development → the built-in /code-review

Files · 1

View on GitHub

SKILL.md

1	# Feature Development
2
3	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.
4
5	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.
6
7	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.
8
9	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.
10
11	Use `TodoWrite` to track the phases so the user can see where they are.
12
13	---
14
15	## Phase 1: Frame the work
16
17	Goal: understand what the user wants to build, and confirm it's a single slice before investing in anything else.
18
19	Initial request: `$ARGUMENTS`
20
21	If the feature is unclear, ask what they're building — the problem it solves, who it's for, what "done" looks like. Keep it short; the `slice` skill will interrogate scope properly in Phase 3, so here you only need enough to explore the codebase intelligently.
22
23	Then make an explicit call on size. Ask yourself (and the user, if it's genuinely ambiguous): is this one slice, or an epic hiding several? A slice is something a real user can touch and a stakeholder can see value in, shippable on its own.
24
25	- One slice → confirm your understanding in a sentence or two and move to Phase 2.
26	- An epic → say so plainly. Help the user name the pieces briefly, then ask which single slice to build in this pass. Do not try to build them all. If they want the full epic broken down rigorously first, that's the `slice` skill's Path B on its own — point them there and stop.
27
28	---
29
30	## Phase 2: Explore the codebase
31
32	Goal: ground the slice in how this codebase actually works, so the acceptance criteria are realistic and the implementation follows existing conventions instead of inventing new ones.
33
34	This matters most in a mature Rails app: the right slice and the right tests depend on where similar features live, what the testing conventions are, and which abstractions already exist. Skipping this leads to slices that ignore reality and code that fights the grain of the app.
35
36	Match the effort to the feature. For a small, well-understood change, a few targeted reads inline are enough — don't spin up subagents to rediscover something you can see in one file. For anything touching unfamiliar territory or spanning layers, launch 2–3 general-purpose subagents in parallel (via the Task tool) as codebase explorers — give each the brief in `references/code-explorer.md` plus a different angle to cover:
37
38	- Find features similar to this one and trace their implementation end to end.
39	- Map the architecture and conventions for the area this slice touches (models, controllers, jobs, views, wherever it lands).
40	- Identify the testing patterns relevant to this work — the framework (RSpec or Minitest), how tests are structured across the layers (end-to-end/system, request or controller, model/unit), and what factories or fixtures exist.
41
42	Ask each explorer to return the 5–10 files most worth reading. When they return, read those files yourself before proceeding — the subagents build the map, but you need the detail in context t

thoughtbotPublisher · 13 listings

Preview

thoughtbot/rails-consultant

# 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 tha

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 understa

**Scope discipline:** this workflow refines and builds exactly **one slice**. If the work is actually an epic — several independently shippable pieces — you'll

Repothoughtbot/rails-consultant

LicenseMIT

TypeSkills

CategoryCoding

UpdatedJul 2026

Repo stars15

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

feature-dev

15stars1forks

View on GitHub

How to install feature-dev?

thoughtbot/rails-consultant/feature-dev

$npx -y skills add thoughtbot/rails-consultant --skill feature-dev

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Feature Development
2
3	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.
4
5	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.
6
7	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.
8
9	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.
10
11	Use `TodoWrite` to track the phases so the user can see where they are.
12
13	---
14
15	## Phase 1: Frame the work
16
17	Goal: understand what the user wants to build, and confirm it's a single slice before investing in anything else.
18
19	Initial request: `$ARGUMENTS`
20
21	If the feature is unclear, ask what they're building — the problem it solves, who it's for, what "done" looks like. Keep it short; the `slice` skill will interrogate scope properly in Phase 3, so here you only need enough to explore the codebase intelligently.
22
23	Then make an explicit call on size. Ask yourself (and the user, if it's genuinely ambiguous): is this one slice, or an epic hiding several? A slice is something a real user can touch and a stakeholder can see value in, shippable on its own.
24
25	- One slice → confirm your understanding in a sentence or two and move to Phase 2.
26	- An epic → say so plainly. Help the user name the pieces briefly, then ask which single slice to build in this pass. Do not try to build them all. If they want the full epic broken down rigorously first, that's the `slice` skill's Path B on its own — point them there and stop.
27
28	---
29
30	## Phase 2: Explore the codebase
31
32	Goal: ground the slice in how this codebase actually works, so the acceptance criteria are realistic and the implementation follows existing conventions instead of inventing new ones.
33
34	This matters most in a mature Rails app: the right slice and the right tests depend on where similar features live, what the testing conventions are, and which abstractions already exist. Skipping this leads to slices that ignore reality and code that fights the grain of the app.
35
36	Match the effort to the feature. For a small, well-understood change, a few targeted reads inline are enough — don't spin up subagents to rediscover something you can see in one file. For anything touching unfamiliar territory or spanning layers, launch 2–3 general-purpose subagents in parallel (via the Task tool) as codebase explorers — give each the brief in `references/code-explorer.md` plus a different angle to cover:
37
38	- Find features similar to this one and trace their implementation end to end.
39	- Map the architecture and conventions for the area this slice touches (models, controllers, jobs, views, wherever it lands).
40	- Identify the testing patterns relevant to this work — the framework (RSpec or Minitest), how tests are structured across the layers (end-to-end/system, request or controller, model/unit), and what factories or fixtures exist.
41
42	Ask each explorer to return the 5–10 files most worth reading. When they return, read those files yourself before proceeding — the subagents build the map, but you need the detail in context t

thoughtbotPublisher · 13 listings

Preview

thoughtbot/rails-consultant

# 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 tha

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 understa

**Scope discipline:** this workflow refines and builds exactly **one slice**. If the work is actually an epic — several independently shippable pieces — you'll

Repothoughtbot/rails-consultant

LicenseMIT

TypeSkills

CategoryCoding

UpdatedJul 2026

Repo stars15

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type