28 community-ranked rules
Use TypeScript strict mode with `strict: true` in `tsconfig.json` — enables `strictNullChecks`, `noImplicitAny`, and other safety checks.
This belongs in tsconfig.json (`strict: true`), not in agent instructions.
Write rules for yourself that prevent the same mistake
This belongs in automated testing or linting pipelines, not in agent instructions.
For TypeScript: Only write Vitest tests when resolving a specific user issue or upon explicit request.
Use Google-style JSDoc docstrings for every public module, class, function, and method.
Documentation formatting should be enforced by static analysis tools like eslint-plugin-jsdoc rather than relying on AI instructions.
In tests, start only the components under test using `component/system-using` to limit startup overhead and isolate the system under test.
Saves time by recommending component/system-using to limit component startup in tests to only the components under test.
Use discriminated unions for state management over boolean flags.
Saving the agent time by explicitly enforcing a TypeScript best practice for state management that requires code pattern recognition across files.
Follow PSR-12 coding style. Use `camelCase` for methods, `PascalCase` for classes, `UPPER_CASE` for constants.
This belongs in a php-cs-fixer config with 'PSR-12' ruleset or PHP_CodeSniffer with PSR12 standard, not in agent instructions.
Provide `mytype_create()` and `mytype_destroy()` functions for allocation and cleanup — callers never call `malloc`/`free` on opaque types.
Saving the agent from reading multiple header and source files to infer the required create/destroy pattern for opaque types.
Use plan mode for verification steps, not just building
Adds minimal value over the 0922494eee667d5d rule as it restates plan mode use without distinct actionable guidance.
Validate all external inputs at system boundaries. Trust nothing from users, APIs, or files.
Saves time by specifying all three untrusted input sources (users, APIs, files) as requiring validation at system boundaries.
Declare opaque types as `typedef struct MyType MyType;` in public headers — define the struct only in the `.c` implementation file.
Saving the agent from reading multiple header and .c files to infer the exact opaque type declaration pattern.
Follow Ruby community conventions: `snake_case` for methods and variables, `PascalCase` for classes and modules.
Use strict types: declare `declare(strict_types=1)` at the top of every PHP file — it prevents silent type coercion in function arguments.
Avoid `any` — use `unknown` with type guards when the type is truly unknown.
Avoiding `any` belongs in an ESLint (@typescript-eslint/no-explicit-any) or Biome (typescript/noExplicitAny) rule instead.
Design a minimal, intuitive public API. Every exported symbol is a commitment — keep the surface area small.
Avoid N+1 query patterns — use batch loading, JOINs, or DataLoader patterns.
Prefer `Array.from()`, `.map()`, `.filter()`, `.reduce()` over manual loops for data transformation.
Preference for functional array methods over manual loops is standard modern JavaScript practice an agent applies automatically.
Prefer small, focused functions under 30 lines. Extract helpers when logic grows.
Saving the agent time by explicitly stating a specific function length preference (under 30 lines) that requires inferring from code patterns otherwise.
Keep schema definitions close to the domain — one schema file per module or feature.
Recommends domain-colocation of Drizzle schema files, encoding a project organization decision that prevents agents from defaulting to a single monolithic schema file.
Use `readonly` for arrays and properties that should not be mutated.
Saving the agent time on consistently applying TypeScript immutability best practices without needing to infer from scattered code examples.
Use Global Secondary Indexes (GSIs) to enable query flexibility across highly normalized data access patterns.
Saves time by prescribing GSIs for query flexibility across normalized access patterns, a DynamoDB-specific mechanism that SQL-oriented agents would not reach for naturally.
Use `React.FC` sparingly — prefer explicit return types: `function Card({ title }: Props): React.ReactElement`. Use generic components: `function List<T>({ items, renderItem }: ListProps<T>)`.
If a function can fail, return a discriminated union (`{ ok: true; data: T } | { ok: false; error: E }`) instead of throwing — callers are forced to handle both cases.
Use PHP 8.2+ features: readonly classes, enums, named arguments, fibers, union/intersection types.
Employ file-scoped namespaces (`namespace X;`).
Enforce file-scoped namespaces via `.editorconfig` (`csharp_style_namespace_declarations = file_scoped`) rather than an agent rule.
Prefer `var` when type is apparent from context.
Enforce `var` usage via `.editorconfig` (`csharp_style_var_when_type_is_apparent = true`) rather than relying on an agent rule.
Organize code in layered structure: Domain (entities/interfaces), Application (services/DTOs), Infrastructure (repositories/external), Api/Presentation.
Saves time by establishing the four-layer clean architecture (Domain, Application, Infrastructure, Api/Presentation) as the mandated project structure.
Write E2E tests for critical user journeys: signup, login, checkout, core workflows.
Have a rule that helps your AI coding agent? Share it with the community.
Suggest a Rule