aif-best-practices

Use descriptive names that reveal intent, avoid abbreviations except universal ones like id or url, and prefix booleans with is, has, can, or should. Functions should follow a verb-plus-noun pattern such as fetchUser or validateInput, with constants in SCREAMING_SNAKE_CASE.

Create specific error classes for domain errors, such as a UserNotFoundError that includes the user ID in its message. Never swallow exceptions with empty catch blocks, and always log errors with context like user IDs or request IDs.

Functions should follow single responsibility with one job each, staying within roughly 20 to 30 lines and accepting at most 3 to 4 parameters. Use early returns for guard clauses and avoid side effects in pure functions.

AAA stands for Arrange, Act, Assert: set up test data, execute the function under test, then verify the result. Each test should check one behavior concept and use a descriptive name following the pattern 'should [expected behavior] when [condition]'.

A reviewer checklist should cover correctness, edge cases, security, performance, readability, test coverage, and consistency with project conventions. Authors should self-review the diff, ensure tests pass, and remove debug code before requesting review.

Project-specific rules from a skill-context file take priority when they conflict with general guidelines, since they reflect conventions proven in the actual codebase. When there is no conflict, both general and project rules apply together.