Why this matters
Prevents shipping incomplete work and keeps requirements-to-code traceability.
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.
Prevents shipping incomplete work and keeps requirements-to-code traceability.
Side-by-side examples engineers can pattern-match during review.
Refs: PAY-123
Implements UI only; AC requires backend validation and audit logging.Refs: PAY-123
Acceptance Criteria coverage:
- AC1 (validate input): src/payments/validator.ts + tests/payment-validator.test.ts
- AC2 (audit trail): src/audit/payments.ts
- AC3 (docs): docs/payments.mdRefs: ABC-123 (no AC mapping, missing behaviors)AC coverage checklist + links to code/tests/docsFrom the same buckets as this rule.
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.