# Feature Implementation

## Purpose

Guide implementation of new behavior or meaningful changes to existing behavior with a bias toward working software, repository alignment, and practical verification.

## When to use

- Building a new feature
- Expanding an existing workflow
- Making a multi-file change that affects user or developer behavior
- Turning a scoped request into implemented code

## Inputs to gather

- Relevant entrypoints, modules, and surrounding patterns
- Existing interfaces, types, schema, and tests
- User goal, success criteria, constraints, and impacted surfaces
- Any repository instructions that override generic defaults

## How to work

- Inspect the codebase before editing and identify the smallest coherent change set.
- Prefer existing patterns over introducing novel structure unless the current patterns are clearly limiting.
- Implement end-to-end behavior, not just partial scaffolding, when feasible.
- Keep logic changes close to the relevant module boundaries and avoid unrelated cleanup unless it materially helps the task.
- Validate with targeted tests, builds, or manual checks appropriate to the repository.
- Update docs, examples, or change notes when the feature alters usage or expectations.

## Output expectations

- A working implementation or a clearly explained blocker
- Concise summary of what changed and why
- Validation results and any gaps that remain
- Notes on follow-up work only when it is genuinely important

## Quality checklist

- The change matches the stated goal and avoids unrelated churn.
- Naming, structure, and style fit the existing codebase.
- Errors, edge cases, and obvious failure paths are handled.
- Verification is appropriate for the size and risk of the change.
- User-facing or developer-facing behavior changes are documented when needed.

## Handoff notes

- Mention touched subsystems and any assumptions made because the repo did not answer them.
- Call out migration or rollout concerns if the feature affects data, config, or compatibility.