External Context (MCPs) rules

If the PR claims to fix a specific issue (e.g., 'Fixes #123' / 'Fix PAY-123'), validate it against the real production error. - If an observability MCP is available (Sentry/Datadog/Bugsnag): fetch the event/stack trace and confirm the change addresses the root cause. - Require a regression test (or a clearly documented reason why a test cannot be added). Call out fixes that only hide symptoms (catch-and-ignore, broader retries, defaulting values) without removing the underlying failure mode.

Before approving/merging risky changes, check whether there is an active critical production incident. - If an incident/monitoring MCP is available (PagerDuty, Datadog Monitors): query for active Sev1/Sev2 incidents. - If there is an active incident: warn the author and suggest delaying merges/deploys or using an explicit emergency override process.

If a PR changes redirect/header configuration (e.g., middleware redirects, CDN headers, security headers), validate it against the active edge rules to avoid conflicts. - If a Cloudflare MCP is available: fetch active rules and detect potential redirect loops, duplicate rules, or header conflicts. - Otherwise: require the author to link the relevant Cloudflare rules/screenshots in the PR description.

If the PR references a ticket (e.g., 'Refs: ABC-123' or a Linear/Jira/Asana/ClickUp/Trello link), verify the diff covers each Acceptance Criterion. - If a ticketing MCP is available: fetch the ticket and list AC → code/tests mapping. - If no MCP is available or the ticket is inaccessible: ask the author to paste the Acceptance Criteria in the PR description. Flag any missing criteria, unhandled edge cases, or partial implementations before human review.

When a PR changes dependency manifests (e.g., package.json, yarn.lock, requirements.txt, composer.json), check for known vulnerabilities and risky packages. - If an OSV/SCA MCP is available: query it for the new package versions and flag recent CVEs. - Otherwise: require evidence (audit output, advisory links) in the PR description. Also flag suspicious packages (typosquats, low-maintenance critical libs, unexpected transitive jumps) and require lockfile updates.

If a PR changes an API endpoint/controller/route, assess current production health before adding heavier logic. - If a monitoring MCP is available (Datadog/Grafana): query current p95 latency and error rate for that endpoint. - If the endpoint is already degraded, warn against adding heavy queries, blocking I/O, or complex synchronous logic; require performance evidence or a safe rollout plan. To enable this check, the PR should reference the endpoint path (e.g., `POST /api/payments`) or the controller/action name.

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 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.

If a PR adds new TODO/FIXME comments, require a tracking ticket. Preferred formats: `TODO(ABC-123): ...` or `FIXME(ABC-123): ...`. If a ticketing MCP is available, suggest (or create) the ticket and link it in the PR. Avoid leaving untracked TODOs in mainline code.