Build Features in Tested Vertical Slices

A skill establishing thin-vertical-slice implementation discipline: implement one piece, test it, verify it, then expand - never a whole feature in one pass, and every increment leaves the system working and testable. The increment cycle is implement -> test -> verify -> commit -> next slice, carrying forward rather than restarting. Three slicing strategies: vertical slices (preferred) deliver complete end-to-end functionality per slice, e.g. create-task (DB+API+UI), then list, then edit, then delete, each leaving working CRUD further along; contract-first slicing defines the API contract (types/interfaces/OpenAPI) first, then implements backend and frontend against it in parallel before integrating; and risk-first slicing tackles the most uncertain piece first (e.g. proving a WebSocket connection works before building features on top of it) so failure is discovered early. Implementation rules: Rule 0 (simplicity first) asks "what's the simplest thing that could work" before coding and reviews finished code against whether a staff engineer would ask "why didn't you just..." - three similar lines beat a premature abstraction, and the naive obviously-correct version comes first, optimized only after correctness is proven. Rule 0.5 (scope discipline) forbids touching anything outside the task - no adjacent cleanup, import refactoring in unmodified files, or unrequested features - noting improvements spotted along the way instead of fixing them, and asking whether to create separate tasks for them. Rule 1 (one thing at a time) means each increment changes one logical thing, never mixing a new component with a refactor and a config change in one commit. Rule 2 (keep it compilable) requires the project to build and existing tests to pass after every single increment. Rule 3 (feature flags) lets incomplete features merge to main behind an environment-driven flag rather than sitting on a long branch. Rule 4 (safe defaults) makes new optional behavior opt-in and disabled by default. Rule 5 (rollback-friendly) keeps additive changes easy to revert, modifications minimal and focused, migrations paired with rollback migrations, and deletion separated from its replacement into different commits. When directing an agent, scope should be stated explicitly per increment (e.g. "just the DB schema and API endpoint, not the UI yet") with verification commands specified. An increment checklist confirms: the change does one thing completely, all existing tests pass, the build succeeds, type checking passes, linting passes, the new functionality works, and the change is committed with a descriptive message.

Use it for any multi-file change, building a new feature from a task breakdown, refactoring existing code, or any time you're tempted to write more than ~100 lines before testing. Not for single-file, single-function changes where the scope is already minimal.

Given a feature or task breakdown, it produces a sequence of small, independently working commits - each one implemented, tested, verified, and committed before the next slice begins - rather than one large, hard-to-review, hard-to-revert change.

Pairs with the git-workflow-and-versioning skill for atomic commit guidance, and relies on the project's own test suite, build command, type checker, and linter for per-increment verification (npm test, npm run build, npx tsc --noEmit, npm run lint in the documented examples).

Developers and AI agents implementing multi-file features or refactors who want each increment to be small, working, testable, and independently revertable - avoiding both premature abstraction and scope creep beyond what the current task actually requires.