49 lines
2.0 KiB
Markdown
49 lines
2.0 KiB
Markdown
|
# 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.
|