Browse 354 rules, 42 knowledge articles, and 28 prompt templates across security, performance, architecture, and quality.
BeforeMerge scans your pull requests against these rules automatically. Get actionable feedback before code ships to production.
58 rules matching filters
Use a multi-AZ/standby configuration and ensure the app reconnects cleanly on failover instead of caching a dead endpoint.
Route read-heavy or analytics queries to read replicas, keeping the primary focused on writes and consistency-critical reads.
Restore dependency and build-layer caches keyed on the lockfile to avoid redundant work each run.
Design pipeline steps to produce the same result on re-run, with no reliance on hidden state or run order.
Every pull request must run linting and the test suite, and merging must be blocked when they fail.
Gate deployments on a passing CI run so only verified commits can be promoted to an environment.
Define infrastructure as code in version control and change it through reviewed, auditable commits.
Pipelines must stop immediately on the first error instead of masking failures and continuing.
Maintain distinct dev/staging/prod environments and drive their differences through configuration, not branching code paths.
Deploy through an automated pipeline and keep a one-step rollback to the previous known-good release.
Apply schema migrations through a dedicated, version-controlled, gated pipeline step — not ad hoc or implicitly on deploy.
Produce one immutable build artifact and promote that same artifact through staging to production.
Enforce branch protection on main: require pull-request review and passing CI before any merge.
Prefer squash or rebase merges (per team policy) to keep main history linear and easy to read, bisect, and revert.
Scope each pull request to one logical change so reviewers can understand it quickly and catch defects.
Keep feature branches small and short-lived, rebasing or merging from the base branch often to avoid drift and painful conflicts.
On successful creation respond with 201 Created, a Location header pointing to the new resource, and ideally its representation.
Expose filtering, sorting, and field selection through query parameters rather than proliferating bespoke endpoints.
Use plural nouns for collections and one consistent casing (e.g. snake_case or camelCase) for fields across the entire API.
Return collections in bounded pages with a default and maximum page size, exposing next/prev cursors or links.
Every error response should share one machine-readable shape (code, message, details) so clients can parse failures uniformly.
Accept a client-supplied Idempotency-Key header on create/payment endpoints so retried requests do not create duplicate resources.
GET must be safe and idempotent, PUT/DELETE idempotent, and POST for non-idempotent creates. Never mutate state on a GET.
Model endpoints as nouns representing resources, not verbs. Let HTTP methods express the action instead of encoding it in the path.