| name | review-scenario |
| description | Use when reviewing a conformance PR that adds or changes scenario .ts files for a SEP — before approving, before requesting changes, or as a self-check before opening one. |
review-scenario
What to check
Spec diff is ground truth. Pull the SEP's actual spec changes and read the RFC-2119 sentences yourself — don't trust the PR description or SEP summary for keyword levels:
gh api "repos/modelcontextprotocol/modelcontextprotocol/pulls/<SEP>/files" \
--jq '.[] | select(.filename | test("^docs/specification/draft/.*\\.mdx$")) | {filename, patch}'
If the SEP includes a conformance-test-case table, that table is authoritative for the cases it lists. A table/prose mismatch is a spec gap to flag, not something to silently resolve either way.
Traceability YAML. src/seps/sep-<SEP>.yaml should exist (run /new-sep <SEP> first if not). Diff its rows against the spec sentences you extracted; flag rows that paraphrase rather than quote, claim a keyword level the spec doesn't, or assert something the spec never says. Check IDs follow sep-<NNNN>-<kebab-slug>.
Per-scenario-file:
- Spec backing — would a fully spec-compliant implementation FAIL this check? If yes — or if two compliant SDKs in different languages would get different results — the spec hasn't pinned the behavior; note it as a gap rather than enforce it.
- Dead checks — emits FAILURE with no reachable SUCCESS counterpart, or sits behind an always-false guard.
- Logic — does a missing/malformed input silently pass? Does the assertion distinguish "rejected for the right reason" from "rejected at all"?
Coverage. Count YAML check: rows vs how many the PR's scenarios actually exercise; list the gaps.