// Build features in thin vertical slices with continuous verification
Five-axis code review for comprehensive quality assessment
Write tests before code using RED-GREEN-REFACTOR cycle
Skill to automate the full deployment process including build, test, and release steps
Skill to perform a thorough security audit of the codebase
| name | Incremental Implementation |
| description | Build features in thin vertical slices with continuous verification |
"The simplest thing that could work."
Build in thin vertical slices. Each increment leaves the system working and testable.
Use this skill when:
Skip for:
┌─────────────────────────────────────────┐
│ 1. Pick smallest complete piece │
│ ↓ │
│ 2. Write failing test (RED) │
│ ↓ │
│ 3. Implement minimal code (GREEN) │
│ ↓ │
│ 4. Refactor if needed │
│ ↓ │
│ 5. Run all tests │
│ ↓ │
│ 6. Commit with clear message │
│ ↓ │
│ 7. Repeat for next piece │
└─────────────────────────────────────────┘
Each slice delivers end-to-end functionality:
Task 1: User can create a task
└── DB model + API route + UI component
Task 2: User can view task list
└── DB query + API endpoint + List component
Task 3: User can complete a task
└── DB update + API handler + Toggle UI
Layers completed separately:
Task 1: Create all DB models
Task 2: Create all API routes
Task 3: Create all UI components
❌ Problem: Nothing works until everything is done
Slice 1: Basic flow works
Slice 2: Add validation
Slice 3: Add error handling
Slice 4: Add edge cases
Slice 1: Uncertain/complex piece (reduce risk early)
Slice 2: Dependent pieces (build on verified foundation)
Slice 3: Polish (now safe to invest time)
Slice 1: Define API contract (types, endpoints)
Slice 2: Backend implements contract
Slice 3: Frontend implements against contract
Test before writing more than ~100 lines.
If you've written 100+ lines without running tests, stop and verify.
Don't refactor adjacent code. Don't add unrequested features.
Stay focused on the current task.
Project must compile and tests must pass after each increment.
Never leave the codebase broken between commits.
// Use flags when merging incomplete features
if (featureFlags.newCheckout) {
return <NewCheckoutFlow />;
}
return <LegacyCheckout />;
New code defaults to conservative, disabled behavior:
Each increment should be independently revertable:
# If this commit breaks something, revert just this
git revert HEAD
Stop and reassess if you're:
Each increment = one commit:
# Good: Atomic, focused commits
git commit -m "feat(tasks): add Task model with title and status"
git commit -m "feat(tasks): add POST /api/tasks endpoint"
git commit -m "feat(tasks): add CreateTaskForm component"
# Bad: Large, unfocused commits
git commit -m "Add task feature" # 500 lines across 10 files
If an increment fails:
After each increment: