---
name: incremental-implementation
description: "Implements thin vertical slices - implement, test, verify, commit. Invoke when building features with feature flags, safe defaults, rollback-friendly changes, or when user says /build. | 实现薄垂直切片——实现、测试、验证、提交。当使用特性开关、安全默认值、可回滚变更构建功能时，或用户说 /build 时触发。"
metadata:
  {
    "builtin_skill_version": "1.0",
    "xingzierai":
      {
        "emoji": "🔨",
        "requires": {}
      }
  }
---
# Incremental Implementation

Build thin vertical slices. Implement one task at a time, verify it works, then move on.

## Overview

The goal is to ship value continuously, not in big bangs. Each increment should:
- Be thin (one task at a time)
- Be complete (implement + test + verify)
- Be safe (feature flags, rollback capability)
- Be verifiable (automated tests pass)

This follows the "commit-as-save-point" pattern: each commit represents a working state.

## When to Use

**Activate this skill when:**
- User says `/build` or asks to "implement" or "build" something
- Starting implementation of a planned task
- Any change touching more than one file

**Do not activate for:**
- Single-file changes that don't affect behavior
- Trivial typo fixes (still commit them though)

## Process

### Step 1: Verify Prerequisites

1. `SPEC.md` exists and is approved (or user has described the task)
2. `PLAN.md` exists with this task defined (or user has given clear instructions)
3. Task has clear acceptance criteria
4. Task dependencies are already implemented

### Step 2: Implement Thin Slice

1. **Isolate the change**: One logical unit of work
2. **Use feature flags**: Wrap new behavior in flags for unsafe features
3. **Keep defaults safe**: System should work with new feature off
4. **Write tests first**: If test-driven-development skill is relevant, use it

### Step 3: Implement, Test, Verify

For each increment:

```
Implement -> Test -> Verify -> Commit
```

1. **Implement**: Write the code
2. **Test**: Run relevant tests
3. **Verify**: Manual check if needed
4. **Commit**: If all pass, commit with clear message

### Step 4: Feature Flag Protocol

For new features:

```python
if FeatureFlags.is_enabled("new_feature"):
    pass
else:
    pass
```

1. Default to **OFF** for new features
2. Enable progressively as verified
3. Keep legacy path until new path is stable
4. Remove flag only after full rollout

### Step 5: Commit Pattern

Commit message format:

```
[TYPE] Brief description

- What changed
- Why it changed
- How to verify

Closes #issue
```

Types: `FEAT`, `FIX`, `REFACTOR`, `DOCS`, `CHORE`, `TEST`

## Rationalizations

| Excuse | Rebuttal |
|--------|----------|
| "I'll implement everything then test" | Big implementations are hard to debug. Ship increments. |
| "Feature flags add complexity" | Flags enable safe rollout. The complexity is necessary. |
| "Tests slow me down" | Tests catch bugs early. Bug hunting is slower. |
| "I'll commit when it's complete" | Commit as save point. Each commit should be a working state. |

## Red Flags

- Implementing multiple unrelated changes in one go
- No tests for new functionality
- Feature flag defaulting to ON before verification
- Commit message just says "updates" or "fixes"
- More than 3 files changed without clear reason

## Verification

**Evidence that incremental implementation is working:**

- [ ] Each increment is small (under 200 lines diff)
- [ ] Each increment has tests
- [ ] Each increment passes verification
- [ ] Feature flags used for new functionality
- [ ] Safe defaults maintained
- [ ] Commits are atomic and descriptive
