菜单
Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use 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.
Create, update, or review Agent Skill directories and SKILL.md files for valid frontmatter, structure, portability, progressive disclosure, and validation readiness.
Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
Discover and run the project's local formatting, linting, static analysis, test, and build checks before handoff.
Update project-facing documentation after a user-visible behavior, configuration, operation, or workflow change.
Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
Add logs, metrics, traces, profiling, or operational notes for meaningful workflows without unsupported performance claims.
| name | incremental-implementation |
| description | Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use 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. |
| metadata | {"version":"1.1.2"} |
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 not to use: Single-file, single-function changes where the scope is already minimal.
Use this increment cycle for each implementation slice:
Implement -> Test -> Verify -> Checkpoint -> Next slice
Repeat the cycle for each slice.
For each slice:
Build one complete path through the stack:
Slice 1: Create a record (<data_store> + <interface> + basic <user_surface>)
Result: Tests pass, user can create a record through the primary surface
Slice 2: List records (<read_path> + <interface> + <user_surface>)
Result: Tests pass, user can see saved records
Slice 3: Edit a record (<update_path> + <interface> + <user_surface>)
Result: Tests pass, user can modify records
Slice 4: Delete a record (<delete_path> + <interface> + confirmation)
Result: Tests pass, the complete lifecycle works
Each slice delivers working end-to-end functionality.
When producers and consumers need to develop in parallel:
Slice 0: Define the contract artifact (<schema>, <interface>, <protocol>, or <spec>)
Slice 1a: Implement the producer against the contract + contract tests
Slice 1b: Implement the consumer against representative test data
Slice 2: Integrate and test the complete path
Tackle the riskiest or most uncertain piece first:
Slice 1: Prove the riskiest integration point works
Slice 2: Build the first user-visible behavior on the proven integration
Slice 3: Add resilience behavior such as retry, fallback, or recovery
If Slice 1 fails, you discover it before investing in Slices 2 and 3.
Before writing any code, ask: "What is the simplest thing that could work?"
After writing code, review it against these checks:
SIMPLICITY CHECK:
Avoid: Generic event pipeline for one notification
Prefer: Direct call or the simplest local coordination mechanism
Avoid: Abstract factory pattern for two similar implementations
Prefer: Two straightforward implementations with shared helpers only where useful
Avoid: Config-driven builder for three small variants
Prefer: Three clear variants with duplication removed only when the shared concept is proven
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.
Touch only what the task requires.
Do not:
If you notice something worth improving outside your task scope, note it — don't fix it:
NOTICED BUT NOT TOUCHING:
- <module_path> has an unused dependency (unrelated to this task)
- The <boundary_or_component> could use clearer error messages (separate task)
Capture these as follow-up notes or separate tasks only if requested.
Each increment changes one logical thing. Don't mix concerns:
Bad: One commit that adds a new component, refactors an existing one, and updates the build config.
Good: Three separate commits — one for each change.
After each increment, the project must build and existing tests must pass. Don't leave the codebase in a broken state between slices.
If a feature isn't ready for users but you need to merge increments:
# Feature flag for work-in-progress behavior.
enable_new_behavior = settings.get("ENABLE_NEW_BEHAVIOR", False)
if enable_new_behavior:
show_new_behavior()
This lets you merge small increments to the main branch without exposing incomplete work.
New code should default to safe, conservative behavior:
# Safe: disabled by default, opt-in.
def create_record(data, *, notify=False):
if notify:
send_notification(data)
return save_record(data)
Each increment should be independently revertable:
When directing an agent to implement incrementally:
"Let's implement Task 3 from the plan.
Start with just the storage change and the external interface.
Don't touch the user-facing surface yet — we'll do that in the next increment.
After implementing, run `<test_command>` and `<build_command>` to verify
nothing is broken."
Be explicit about what is in scope and what is not in scope for each increment.
After each increment, verify:
<test_command>)<build_command>)<type_check_command>)<lint_command>)Note: Run each verification command after a change that could affect it. After a successful run, don't repeat the same command unless the code has changed since — re-running on unchanged code adds no information.
After completing all increments for a task: