Agent skill · software engineering · addyosmani
incremental-implementation
Delivers changes incrementally in thin, verifiable slices. Use when implementing any feature or change that touches more than one file, or when picking up the next task from a plan. Use when rolling a change out behind a feature flag, when you're about to write a large amount of code at once, or when a task feels too big to land in one step.
Why this skill is useful
Codifies a structured approach to incremental implementation that the AI could infer but now doesn't have to guess.
What it needs
About 6k tokens when loaded. Last updated 2026-08-06. 83,053 stars on the source repository.
What this skill does
Incremental Implementation Overview Build in thin vertical slices — implement one piece, test it, verify it, then expand. Avoid implementing an entire feature in one pass. Each increment should leave the system in a working, testable state. This is the execution discipline that makes large features manageable. When to Use Implementing any multi-file change Building a new feature from a task breakdown Refactoring existing code Any time you're tempted to write more than ~100 lines before testing When NOT to use: Single-file, single-function changes where the scope is already minimal. The Increment Cycle For each slice: 1. Implement the smallest complete piece of functionality 2. Test — run the test suite (or write a test if none exists) 3. Verify — confirm the slice works as expected (tests pass, build succeeds, manual check) 4. Commit -- save your progress with a descriptive message (see git-workflow-and-versioning for atomic commit guidance) 5. Move to the next slice — carry forward, don't restart Slicing Strategies Vertical Slices (Preferred) Build one complete path through the stack: Each slice delivers working end-to-end functionality. Contract-First Slicing When backend and frontend need to develop in parallel: Risk-First Slicing Tackle the riskiest or most uncertain piece first: If Slice 1 fails, you discover it before investing in Slices 2 and 3. Implementation Rules Rule 0: Simplicity First Before writing any code, ask: "What is the simplest thing that could work?" After writing code, review it against these checks: Can this be done in fewer lines? Are these abstractions earning their complexity? Would a staff engineer look at this and say "why didn't you just..."? Am I building for hypothetical future requirements, or the current task? Three similar lines of code is better than a premature abstraction. Implement the naive, obviously-correct version first. Optimize only after correctness is proven with tests. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills addyosmani/incremental-implementation