51 lines
1.7 KiB
Markdown
51 lines
1.7 KiB
Markdown
# Agent Instructions
|
|
|
|
Use documentation selectively.
|
|
|
|
Always read the minimum relevant documentation before making changes.
|
|
|
|
## Required documentation by task type
|
|
|
|
### Small scoped changes
|
|
For small UI fixes, copy updates, styling adjustments, or isolated bug fixes:
|
|
- read only the directly relevant files
|
|
- do not read project-wide documentation unless needed
|
|
|
|
### Feature-scoped changes
|
|
For changes affecting an existing feature:
|
|
- read the matching file in `specs/`
|
|
- read `docs/ARCHITECTURE.md` only if the change affects structure or flow
|
|
|
|
### Large or cross-cutting changes
|
|
For new features, architecture changes, domain rule changes, or public behavior changes:
|
|
- read:
|
|
- docs/ARCHITECTURE.md
|
|
- docs/DOMAIN_RULES.md
|
|
- docs/FEATURES.md
|
|
- also read the matching file in `specs/` when applicable
|
|
|
|
## Core rules
|
|
|
|
- Do not introduce new patterns, abstractions, or frameworks unless explicitly requested.
|
|
- Do not refactor unrelated code.
|
|
- Do not rename files, folders, database fields, or public interfaces unless explicitly requested.
|
|
- Follow the existing folder structure and module boundaries.
|
|
- Keep changes minimal, scoped, and consistent with the current codebase.
|
|
- Reuse existing primitives, services, validators, helpers, and utilities whenever possible.
|
|
- Preserve the current implementation unless the task explicitly requires changing it.
|
|
|
|
## Documentation updates
|
|
|
|
Update documentation only when implementation changes affect:
|
|
- feature scope
|
|
- business rules
|
|
- architectureڑڑ
|
|
- public behavior
|
|
|
|
Do not update documentation for small isolated fixes or purely visual changes.
|
|
|
|
Update only the relevant files in:
|
|
- docs/
|
|
- specs/
|
|
|
|
Keep documentation aligned with the real implementation, not assumptions. |