| name | code-quality |
| description | Apply linting, formatting, DRY, KISS, functional programming, and clean-code principles to generated or edited code. Use for conforming to project lint/format config, avoiding duplication, and writing maintainable code. Triggers on code review, refactoring, or quality requirements. |
Code quality
Generated or edited code must follow the project's linting and formatting, DRY, KISS, functional programming principles, and clean-code practices.
Linting and formatting
- Conform to the lint and format config already in the repo (e.g. ESLint, Prettier).
- Do not introduce lint or style violations. Run the project's linter and formatter and fix any issues before considering the change complete.
DRY (Don't Repeat Yourself) — required
- Do not copy-paste blocks of logic or styles.
- Extract repeated values into constants, variables, tokens, mixins, or shared utilities.
- Reuse existing components, services, and helpers instead of duplicating behavior.
KISS (Keep It Simple, Stupid) — required
- Prefer the simplest solution that solves the problem; avoid over-engineering.
- Avoid unnecessary abstractions, layers, or indirection until they are justified by reuse or clarity.
- Prefer clear, readable code over clever or "elegant" code when they conflict.
Functional programming principles — required
- Prefer pure functions where possible: same inputs → same outputs, no side effects.
- Avoid mutable state; prefer immutable data and updates (e.g. new objects/arrays instead of mutating in place).
- Use declarative patterns:
map, filter, reduce, and composition over imperative loops when they improve readability.
- Keep side effects (I/O, DOM, subscriptions) at the edges; isolate them in services or explicit effect boundaries.
Clean code — required
- Use full, descriptive names; avoid unnecessary abbreviations (unless a well-known project or domain term).
- Keep units of code focused and single-purpose; prefer small, reusable pieces.
- Avoid deep nesting and tangles; code should be easy to change without breaking unrelated behavior.
- Add brief comments or JSDoc for non-obvious behavior and document why when intent is not clear from the code alone.
Code style (Angular / TypeScript)
- Max ~30 lines per method — extract private helpers for anything longer.
- Max 3 parameters — use an options/config object beyond that.
- Use
private on internal methods and fields.
- Single responsibility — one function does one thing.
- No business logic in components — delegate to stores/services.
TypeScript guidelines
- Prefer type inference where obvious; annotate return types on public methods and service APIs.
- Avoid
any — use unknown and type-narrow.
- Define clear interfaces and types for component state, service responses, and data models. Co-locate in the feature folder or a shared
models/ directory.
- No magic numbers/strings — extract to named constants or enums.
- No
console.log in production code — use console.warn for caught errors only.
