| name | build-sub-feature |
| type | Skill |
| title | build-sub-feature — add a capability INTO a live feature, to a world-class bar |
| description | Implement a sub-feature — a new capability added INTO a live, existing feature — to a world-class bar. Use whenever the user asks to add, extend, or wire a capability into something that already exists: 'add X to Y', 'extend Y to support X', 'build a new option / button / setting / endpoint / tool for Y', or hands over a sub-feature spec to implement. Runs a fast interview first (basics before code; the user can walk away during exploration), then builds to non-negotiable acceptance criteria: reuse canonical code instead of forking variants, bring the whole stack along (a needed backend contract is part of the work, not a follow-up ticket), propagate shared logic to every surface (web, desktop, Chrome extension, mobile, admin), annihilate anything replaced (no shims, fallbacks, or dead code), and emulate the best systems that already solve this. NOT for whole-feature audits or overhauls (use feature-deep-dive), greenfield standalone features, pure bug fixes, or trivial copy/style tweaks. |
| tags | ["execution","features","implementation","doctrine"] |
| timestamp | 2026-08-22T00:00:00.000Z |
Build a Sub-Feature
You're implementing a new sub-feature — an addition to something that already exists in the platform. The spec comes from the user (interview below); the standards are non-negotiable acceptance criteria. Implement to them, and loop until the result actually satisfies them. You're done when it's real, complete, verified, and indistinguishable from work shipped by the best engineering organization on earth — not before.
This isn't greenfield. It's an addition to something live, so the surrounding system is your first concern, not an afterthought. Build so the whole ecosystem is better for this — not just the one spot it lands in.
Step 1 — Interview: nail the spec before touching code
If the invocation already includes a description, treat it as the overview and interview only for the gaps. Ask in plain chat text — never a structured question picker; it blocks free-form replies.
- Open with ONE quick round of basic questions BEFORE going into the codebase. The user is actively waiting during this step — ask everything together, keep it fast.
- Attach your recommendation or the known best practice to every question that has one, stated plainly, so the user can confirm with a single word.
- End every round with a genuinely open-ended question ("what else should I know that I didn't ask?") — strict questions limit what the user can contribute; the open one is where the unanticipated context arrives.
- The moment you have enough to explore, SAY SO explicitly — "I have what I need; exploring the codebase now — you can step away" — then go. The user plans their time around this signal.
- Exploration surfaces new questions. Bring them back in batches, not one at a time, and keep the interview alive until you have explored all you need and have all the answers you need.
Step 2 — Explore: know the ground
Before designing or writing anything, establish from the actual code: what this lands inside, what consumes it, what it depends on, what already exists to reuse, and which of the world's best systems already solve this problem well. The standards below tell you what to look for; exploration is where you look.
The standards — non-negotiable acceptance criteria
Reuse before you write. Assume what you need already exists — a component, hook, utility, service, type, or pattern — and go find it. If it almost exists, extend the canonical one rather than forking a variant. Write something new only when nothing reusable fits, and when you do, write it so the next person consumes it instead of rebuilding it.
Build into the ecosystem, not beside it. Know the blast radius before you start: what consumes this, what it depends on, and whether the server, database, or shared packages need to change for it to be done right. If the backend needs a new contract to support this properly, that contract is part of the work — not a follow-up ticket. A sub-feature that works in isolation while ignoring everything around it is unfinished.
