Code Quality 20

Rule

Keep Files Short

Limit file length to maintain readability and focus

readabilityorganizationmaintainability
Rule

Single Responsibility Functions

Each function should do exactly one thing

functionsclaritydesign
Rule

Meaningful Names

Use descriptive variable and function names that reveal intent

namingreadabilityclarity
Rule

No Magic Numbers

Replace magic numbers and strings with named constants

readabilityconstantsclarity
Rule

No Dead Code

Remove unused code instead of commenting it out

cleanupreadabilitygit
Rule

Don't Repeat Yourself

Extract shared logic when you see the same pattern three times

reuseabstractionmaintainability
Rule

Early Returns

Use early returns to reduce nesting depth

readabilitycontrol-flowclarity
Rule

Consistent Code Style

Follow the existing code style and patterns in the project

consistencystyleconventions
Rule

No Abbreviations

Avoid abbreviations in identifiers unless they are universally understood

namingreadabilityclarity
Rule

Small Functions

Keep functions under 25 lines to maintain readability

functionsreadabilityorganization
Rule

No Nested Ternaries

Avoid nested ternary expressions for readability

readabilitycontrol-flowclarity
Rule

Explicit Over Implicit

Prefer explicit code over clever implicit behavior

clarityreadabilitymaintainability
Rule

No Premature Abstraction

Don't create abstractions until you have three concrete use cases

abstractiondesignsimplicity
Rule

Guard Clauses

Use guard clauses instead of deeply nested conditionals

readabilitycontrol-flowpatterns
Rule

Immutable by Default

Prefer const and readonly; mutate only when necessary

immutabilitysafetypatterns
Rule

No Side Effects

Keep functions pure when possible

functionalpuritytesting
Rule

Limit Parameters

Functions should take no more than 3 parameters

functionsdesignreadability
Rule

Boolean Naming

Name booleans as questions using is, has, can, or should prefixes

namingbooleansreadability
Rule

No Commented-Out Code

Delete commented-out code; git preserves history

cleanupreadabilitygit
Rule

Consistent Return Types

Functions should consistently return the same type

typesconsistencyreliability

Architecture 15

Rule

Separation of Concerns

Separate business logic from I/O and presentation

architecturelayersdesign
Rule

Dependency Injection

Inject dependencies instead of importing them directly

testingcouplingdesign
Rule

Interface Boundaries

Define clear interfaces between modules

modulescontractsarchitecture
Rule

Feature Folders

Organize code by feature, not by file type

organizationstructurearchitecture
Rule

No Circular Dependencies

Avoid circular dependencies between modules

modulesdependenciesarchitecture
Rule

Thin Controllers

Keep route handlers thin; delegate to service functions

apiarchitecturepatterns
Rule

Config from Environment

Read configuration from environment variables, never hardcode

configurationenvironmentsecurity
Rule

API Versioning

Version APIs from the start to enable non-breaking changes

apiversioningcompatibility
Rule

Clear Layers

Maintain clear architectural layers: routes, services, data

architecturelayersorganization
Rule

No God Objects

Break large classes or modules into focused, smaller units

designorganizationcomplexity
Rule

Encapsulate Implementation

Keep implementation details private; expose minimal interfaces

encapsulationapi-designmodules
Rule

Colocate Related Code

Keep related code close together in the file system

organizationstructureproximity
Rule

Domain Modeling

Model the domain with explicit types rather than primitive values

typesdomaindesign
Rule

Stateless Services

Keep service functions stateless when possible

architecturestatescalability
Rule

Limit Module Exports

Only export what consumers actually need

modulesapi-designencapsulation

Testing 15

Rule

Test Behavior, Not Implementation

Test outcomes and behavior, not internal implementation details

testingbehaviormaintainability
Rule

Arrange-Act-Assert

Structure tests with clear arrange, act, and assert sections

testingstructurereadability
Rule

Descriptive Test Names

Name tests to describe the expected behavior

testingnamingdocumentation
Rule

Independent Tests

Each test must pass when run in isolation

testingisolationreliability
Rule

Test Edge Cases

Always test boundary conditions, empty inputs, and error paths

testingedge-casescoverage
Rule

Integration Over Mocks

Prefer integration tests over mocking internal modules

testingintegrationmocks
Rule

One Concept Per Test

Each test should verify one logical concept

testingfocusclarity
Rule

Test Public API

Test through public interfaces, not private internals

testingapiencapsulation
Rule

No Flaky Tests

Fix or remove flaky tests immediately

testingreliabilityci
Rule

Test Error Paths

Test failure scenarios as thoroughly as success paths

testingerrorscoverage
Rule

Realistic Test Data

Use realistic data in tests, not placeholder values

testingdataclarity
Rule

Snapshot Tests Sparingly

Use snapshot tests sparingly; prefer explicit assertions

testingsnapshotsmaintainability
Rule

Test Before Refactoring

Add tests before refactoring code that lacks coverage

testingrefactoringsafety
Rule

Fast Unit Tests

Unit tests should run in under 100ms each

testingperformancespeed
Rule

Test File Convention

Follow a consistent test file naming and location convention

testingconventionsorganization

Communication Style 15

Rule

Be Concise

Keep responses short and direct without unnecessary preamble

communicationbrevitystyle
Rule

No Trailing Summaries

Don't summarize what you just did at the end of responses

communicationbrevitystyle
Rule

Explain Why

When suggesting changes, explain the reasoning behind them

communicationreasoningcontext
Rule

Ask Before Refactoring

Ask before making changes beyond the requested scope

communicationscopecollaboration
Rule

No Unsolicited Improvements

Only change what was specifically requested

scopedisciplinefocus
Rule

Match Communication Tone

Match the formality level of the user's messages

communicationtoneadaptation
Rule

Code Over Prose

Show code examples instead of describing changes in words

communicationexamplesclarity
Rule

Flag Tradeoffs

When making a design choice, mention the tradeoffs involved

communicationdecisionstransparency
Rule

Admit Uncertainty

Say 'I'm not sure' instead of guessing confidently

communicationhonestyreliability
Rule

No Filler Phrases

Avoid filler phrases like 'Great question!' or 'Absolutely!'

communicationbrevityprofessionalism
Rule

Actionable Suggestions

Every suggestion should include a clear, concrete next step

communicationactionsclarity
Rule

Reference File Locations

Reference file paths and line numbers when discussing code

communicationreferencesprecision
Rule

Prefer Examples

Use short code examples rather than long explanations

communicationexamplesteaching
Rule

One Approach

Suggest one recommended approach, not a menu of options

communicationdecisionsdirectness
Rule

No Apologies

Don't apologize; just fix the issue and move on

communicationefficiencyprofessionalism

Agent Behavior 20

Rule

Read Before Edit

Always read a file completely before modifying it

agentsafetycontext
Rule

Verify Assumptions

Check code and docs to verify assumptions instead of guessing

agentaccuracyverification
Rule

One Change at a Time

Make one logical change and verify before moving to the next

agentincrementalsafety
Rule

Run Tests After Changes

Run the test suite after making changes to catch regressions

agenttestingverification
Rule

Minimal Changes

Make the minimum change needed to accomplish the task

agentscopeprecision
Rule

Preserve Existing Style

Match the codebase's existing style; don't impose new patterns

agentconsistencystyle
Rule

No Placeholder Code

Never leave TODO comments or placeholder implementations

agentcompletenessquality
Rule

Check Existing Patterns

Look for established patterns before introducing new ones

agentconsistencypatterns
Rule

Confirm Destructive Actions

Ask before running destructive or irreversible operations

agentsafetyconfirmation
Rule

Explain Errors Clearly

When something fails, explain what went wrong and why

agenterrorscommunication
Rule

No Hallucinated APIs

Never invent API methods or library functions; verify they exist

agentaccuracyverification
Rule

Incremental Progress

Work incrementally; don't try to change everything at once

agentincrementalworkflow
Rule

Read Surrounding Context

Read surrounding code and related files before making changes

agentcontextunderstanding
Rule

Respect .gitignore

Never commit files that should be gitignored

agentgitsafety
Rule

Test After Implementation

Verify the feature works end-to-end after implementing it

agenttestingverification
Rule

Don't Create Unnecessary Files

Prefer editing existing files over creating new ones

agentfilesorganization
Rule

Fix Root Cause

Fix the underlying cause of problems, not just symptoms

agentdebuggingquality
Rule

No Backwards Compatibility Hacks

Change the code directly; don't add shims or wrappers

agentsimplicitydirectness
Rule

Rollback on Failure

If a change breaks things, revert and try a different approach

agentsafetyrecovery
Rule

Scope Discipline

Stay within the requested scope; don't add unrequested features

agentscopediscipline

No rules match your search.