// library
Severity
Bucket
If a PR changes an API route/controller signature (path, method, params, request/response schema), update the API specification in the same PR. To enable this check, reference the spec file path in the PR (e.g., `openapi.yaml`, `swagger.json`). If multiple specs exist, update the relevant one. Warn when code and spec drift (new params not documented, status codes changed, response shape changed).
When removing or decommissioning a feature, ensure the associated feature flag is also removed from: - application code paths, - config/registry files (e.g., flags.ts, config.json), and - analytics/feature flag tools (if applicable). If a PostHog (or similar) MCP is available, verify the flag is disabled/removed and not referenced elsewhere. Otherwise, require a repo-wide search evidence in the PR.
If the repo defines a Definition of Done (e.g., `DOD.md`, `CONTRIBUTING.md`), ensure the PR meets it. To enable this check, reference the file path in the PR or ask to review it explicitly. Confirm bureaucratic requirements (docs, tests, design approval, rollout plan) are satisfied or explicitly marked as not applicable.
If the PR introduces or expands usage of deprecated libraries/patterns the team is migrating away from (e.g., Moment.js, React Class Components), block and suggest the modern replacement. If the repo includes a migration guide (e.g., `docs/migration.md`, `CONTRIBUTING.md`, `docs/adr/*`), follow it and propose the equivalent snippet. If no guide exists, use an available web/search MCP to propose a safe, modern alternative and ask for confirmation of project standards.
Avoid re-creating existing UI components or duplicating styles (CSS/Tailwind) when the company design system already provides an official component. If the PR touches UI and a design system entry point is referenced (e.g., `ui/index.ts`, `design-system.md`), use it as the source of truth and suggest the equivalent official component.
5 rules