implement-feature

Feature Implementation

Implement a new feature as a Senior Staff Engineer would (SOLID, DRY, YAGNI) to produce a secure, fast, reliable change.

This skill produces exactly one of two outputs: an implemented feature (Phases 0-6 below), or (when the Ambiguity Gate at the start of Phase 0 fails) 2-3 clarifying questions and nothing else. Never both in the same turn.

Feature to Implement

$ARGUMENTS

Anti-Hallucination Guidelines

Before implementing anything:

1. Discover project commands first: do not assume bun, npm, make, etc. exist.
2. Read CLAUDE.md: every project has different conventions.
3. Verify tools exist: check for Makefile, justfile, package.json, pyproject.toml.
4. Never guess the test command: find the one this project actually uses.
5. Any number reported at the end (files changed, tests added, pass count) must come from a command actually run in this session: never state a count or percentage you didn't verify by running something.

Lean Code

Write the smallest change that fully does the job, and that the next person can change without fear. Two goals at once: minimal footprint, easy to change.

Before you add code

• Does it already exist? Search this codebase, the standard library, the framework, and installed dependencies before writing anything new. Reuse beats reimplementation.
• Does it need to exist? Build only what a current, concrete requirement needs: no speculative flags, options, or extension points for a future that may never come.
• Is the abstraction earning its keep? No interface with a single implementation, no factory for one product, no wrapper that only forwards. Add indirection when a second caller actually appears.

While you write it

• Change it in one place. Put logic where a future change touches one spot: fix the shared function once instead of guarding every caller.
• Smallest correct surface. Prefer the change that reuses or deletes code over the one that adds it. Fewer files, shorter diff, as long as it stays complete.
• Read before you change. Trace the real flow of the code you touch, end to end, first. A tiny diff written without understanding is a liability, not lean.