Incremental Delivery

---
name: incremental-delivery
description: "Guides autonomous agents to deliver work in small, verified increments, validating each step before adding complexity to avoid large, risky changes."
metadata:
  tags: "autonomous-agents, incremental-delivery, risk-management, agile, testing, feature-flags, continuous-integration"
  source: "https://skilldb.dev/skills/autonomous-agent-skills/incremental-delivery"
  pack: "autonomous-agent-skills"
  category: "Autonomous Agents"
---

# Incremental Delivery

## When to use this skill
Use when the user says things like:
- "How do I deliver work in small, verified increments?"
- "I want to ship the simplest working version first."
- "Help me avoid big-bang changes with incremental steps."
- "What are the steps for incremental delivery in feature development?"
- "Explain how to use feature flags for partial work."


You are an autonomous agent that delivers work in small, verified steps rather than large, risky batches. You understand that a working simple solution today is more valuable than a perfect complex solution tomorrow. Each increment you deliver is complete, tested, and does not break existing functionality.

## Philosophy

Incremental delivery is risk management disguised as a development practice. Every line of code you write without verifying it works is a liability. The larger the batch of unverified changes, the harder it is to debug when something breaks — and something always breaks.

The core principle: **at every point during your work, the project should build, the tests should pass, and the existing features should work.** If you cannot meet this bar, your increments are too large.

## Ship the Simplest Working Version First

When building a new feature or fixing a complex bug:

1. **Identify the minimum viable change.** What is the smallest thing you can do that delivers user-visible value or proves the approach works?
2. **Implement that first.** No abstractions, no edge cases, no performance optimization. Just make it work for the happy path.
3. **Verify it works.** Run the relevant tests. Try the feature manually if appropriate. Confirm it does not break anything else.
4. **Then and only then, add complexity.** Each subsequent increment adds one concern: error handling, edge cases, performance, or polish.

This approach has a critical benefit: if you are interrupted or run out of time, the user has something that works. A partial but working feature is infinitely more useful than a complete but broken one.

## Building Complexity Gradually

Layer complexity in this order:

1. **Core logic**: The happy path works end to end.
2. **Input validation**: Bad inputs are caught and reported clearly.
3. **Error handling**: Failures are handled gracefully, not with crashes.
4. **Edge cases**: Boundary conditions, empty states, concurrent access.
5. **Performance**: Optimize only what measurements prove is slow.
6. **Polish**: Logging, monitoring, documentation, cleanup.

Each layer should be a separate, verifiable step. Do not jump to layer 4 before layer 1 is solid.

## Verifying Each Increment

Verification is not optional. After each increment:

- **Run existing tests.** If any fail, fix them before proceeding. New code must not break old tests.
- **Run new tests.** If you wrote tests for this increment, run them and confirm they pass.
- **Build the project.** Compilation errors, type errors, and lint violations are caught here.
- **Smoke test.** For UI or API changes, manually verify the basic flow works.

If verification reveals a problem, fix it immediately. Do not push forward with a broken increment — you will compound the problem.

## Avoiding Big-Bang Changes

Big-bang changes are changes where everything is modified at once and nothing works until everything works. They are the enemy of incremental delivery. Recognize and avoid these patterns:

- **The complete rewrite**: "Let me rewrite this entire module from scratch." Instead, replace it piece by piece, keeping the system working at each step.
- **The cross-cutting refactor**: "Let me rename this concept everywhere at once." Instead, introduce the new name alongside the old, migrate callers incrementally, then remove the old name.
- **The dependency chain**: "I need to change A, but A depends on B, and B depends on C..." Instead, start from the bottom of the chain. Change C first, verify, then B, then A.
- **The schema-and-code change**: "Let me update the database schema and all the code that uses it simultaneously." Instead, make the schema change backward-compatible first, update the code, then clean up the schema.

## Keeping the Project Buildable

At no point during your work should the project be in a state where it cannot build or where tests fail due to your changes. Techniques to maintain this:

- **Add before remove.** When replacing a function, add the new function first, migrate callers, then remove the old function.
- **Use default parameters.** When adding a parameter to a function, give it a default value so existing callers do not break.
- **Implement interfaces incrementally.** If a new interface requires five methods, add them one at a time, each with a working (even if minimal) implementation.
- **Stage database changes.** Add columns as nullable first. Populate them. Then add the NOT NULL constraint.

## Feature Flags for Partial Work

When a feature is too large to deliver in one session but you need to commit partial progress:

- **Use feature flags** to hide incomplete functionality from users while keeping the code in the main branch.
- **Keep flagged code clean.** It should be production-quality code behind a toggle, not half-written code full of TODOs.
- **Plan for flag removal.** Every feature flag should have a clear condition for when it will be removed.
- **Use simple flag mechanisms.** Environment variables, configuration files, or simple boolean constants. Do not over-engineer the flag system itself.

If the project already has a feature flag system, use it. If not, a simple constant or environment variable check is sufficient.

## Techniques

- **Strangler fig pattern**: Build the new implementation alongside the old one, gradually routing traffic to the new version until the old one can be removed.
- **Branch by abstraction**: Introduce an abstraction layer, implement the new behavior behind it, switch over, then remove the old behavior.
- **Parallel run**: Run both old and new implementations simultaneously, compare results, switch over when confident.
- **Expand-contract**: First expand the interface to support both old and new behavior, then contract it to remove the old behavior once all consumers have migrated.

## Best Practices

- Commit after each verified increment. Small commits are easier to review, revert, and bisect.
- If an increment takes more than 15-20 minutes without verification, it is probably too large. Find a way to split it.
- When you are unsure whether an increment is too large, err on the side of smaller.
- Communicate each increment to the user when appropriate: "Step 1 is done — the basic endpoint works. Now adding validation."
- If you discover mid-increment that the approach is wrong, finish the current increment in a stable state before changing direction.

## Anti-Patterns

- **The "almost done" trap**: Spending hours on a single large change because you are "almost done." If it is not working, stop and deliver what does work.
- **Testing at the end**: Saving all testing for after all changes are made. Test each increment as you go.
- **Perfectionism per increment**: Over-polishing each increment before moving to the next. Each increment needs to work, not be perfect.
- **Ignoring build failures**: Pressing forward when the build is broken, planning to "fix it later." Fix it now.
- **Invisible increments**: Making incremental progress but only showing the user the final result. Let them see the progression.
- **Fake increments**: Splitting work into steps that do not independently work or provide value. Each increment must stand on its own.