eh-implement

name: eh-implement description: Implement a planned story, feature slice, or description. Follow llm/notes.md while making small, testable, low-coupling code changes with disciplined comments. user-invocable: true allowed-tools: Bash, Read, Glob, Grep, Write, Edit, Task(subagent_type=Explore *)

Implement one story at a time: one acceptance test, one PR, one thin end-to-end slice.

Before changing code, read:

Expect input to be one of:

If the input still contains multiple acceptance tests or unrelated behavior, stop.

Identify the single acceptance test being implemented.
Restate the observable behavior, what is in scope, and what is explicitly out of scope.
Prefer the smallest tracer-bullet path that proves the behavior end to end.

Read the surrounding code before editing.
Reuse existing abstractions when they fit.
If you need a new abstraction, introduce the smallest one that makes the next change easier.
Optimize for replaceability, low coupling, and clear contracts rather than cleverness.
If the change crosses service or data boundaries, make ownership, guarantees, and failure behavior explicit.
If you make a material architectural trade-off, capture the why in the most appropriate artifact for the repo: ADR, ticket, planning doc, or PR notes.

Keep functions small and single-purpose.
Make illegal states hard to represent. Validate assumptions and fail early when a contract is violated.
Remove duplication instead of copying logic into another place.
Fix nearby broken windows that directly obscure the change but do not sprawl into unrelated cleanup.
Prefer plain, obvious code over indirection.
If you are prototyping to learn, keep it disposable. Do not smuggle prototype shortcuts into the final code.
For distributed or data-heavy changes, be explicit about consistency, ownership, retries, idempotency, and failure modes.

Do not add comments that narrate what the next line or block does.
Inline comments are for why: constraints, invariants, trade-offs, or non-obvious behavior.
What comments belong only in doc comments on functions, classes, modules, or similar units, and those doc comments should be terse.
If the code is self-explanatory, prefer no comment.
Delete stale or noisy comments in code you touch.

Run the narrowest useful tests first, then broader tests as needed.
Do not assume behavior. Prove it with tests, logs, types, contracts, or direct inspection.
Verify the acceptance test, the main failure path, and any contract you changed.
If architecture-level guarantees matter, add or update automated checks where practical.

Check for accidental coupling, hidden duplication, oversized functions, leaky names, and comment noise.
Check whether the change still maps cleanly to one acceptance test.
If the slice grew beyond a couple of days of work, send it back through planning and split it.
Summarize the trade-offs and remaining risks.