cliffhall · Oct 4, 2026 · Oct 4, 2026 · Oct 4, 2026
diff --git a/.claude/skills/pr-flow/SKILL.md b/.claude/skills/pr-flow/SKILL.md
@@ -131,8 +131,8 @@ One thing the gate deliberately leaves out:
 
 ## 5. Client evidence
 
-A PR shows the change working, as the PR template's **How Has This Been
-Tested?** section asks. Here that means evidence from clients, not screenshots.
+A PR shows the change working, under the body's **How Has This Been Tested?**
+section (step 6). Here that means evidence from clients, not screenshots.
 
 **A change to server behavior** (a tool, resource, prompt, capability,
 transport or error it returns) records, for **both** the Inspector V2 and an
@@ -159,6 +159,33 @@ Put the evidence in the PR body under **How Has This Been Tested?**.
 Base **`v2/main`** (or the lower branch, when stacked). **Never `main`.** Label
 it `v2`. The body's **first line is `Closes #<N>`**.
 
+The body carries these sections, in order. `.github/pull_request_template.md`
+is only the "issues, not PRs" banner that turns outside PRs away, so this list
+is where the structure lives:
+
+- **Description**: what changed and why.
+- **Server Details**: the server (or "none (repository-wide)") and what in it
+  changed (tools, resources, prompts, docs, …).
+- **Motivation and Context**: the problem it solves; usually a pointer to the
+  issue.
+- **How Has This Been Tested?**: the evidence from step 5.
+- **Breaking Changes**: whether users must change their client configuration.
+- **Types of changes**: tick each that applies: bug fix, new feature, breaking
+  change, documentation update.
+- **Checklist**: answer every item. Tick each that holds, and tick and mark
+  each that does not apply "(not applicable: <why>)"; leave none blank:
+  - [ ] I have read the [MCP Protocol Documentation](https://modelcontextprotocol.io)
+  - [ ] My changes follow MCP security best practices
+  - [ ] I have updated the server's README accordingly
+  - [ ] I have added a changeset (`npm run changeset`) if this changes what a
+        TypeScript server publishes
+  - [ ] I have tested this with an LLM client
+  - [ ] My code follows the repository's style guidelines
+  - [ ] New and existing tests pass locally
+  - [ ] I have added appropriate error handling
+  - [ ] I have documented all environment variables and configuration options
+- **Additional context** (optional): implementation notes or design decisions.
+
 Write the body to a file and pass it with `--body-file`. A body passed inline
 in double quotes goes through the shell, so every backtick in its Markdown runs
 as a command substitution and `$VAR` expands. Keep the file outside the
@@ -169,7 +196,7 @@ BODY=$(mktemp)
 cat > "$BODY" <<'EOF'
 Closes #<N>
 
-<what changed and why, then the template's sections, with the evidence>
+<the sections above, with the evidence>
 EOF
 gh pr create --repo modelcontextprotocol/servers \
   --base v2/main --label v2 --title "<title>" --body-file "$BODY"

diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
@@ -1,86 +1,6 @@
-<!--
-  ⚠️ Before you open this pull request, please read our contribution policy.
-
-  We accept ISSUES, NOT PULL REQUESTS from anyone but the repository
-  maintainers, organization members with write access included.
-
-  Design and implementation are done by the maintainers through a
-  prompt-driven workflow (see AGENTS.md). Outside pull requests are closed,
-  not merged: a diff written outside that workflow has to be reverse-engineered
-  to fit our conventions, tests and gates, so it's faster for us to re-derive
-  the change from your intent.
-
-  If you've found a bug or want a feature:
-    → Open an issue instead, using the Bug report or Feature request form.
-
-  If you've already built the change locally:
-    → Open an issue and share the PROMPT(S) you used to generate it, not a
-      diff. We'll reproduce it through our own workflow.
-
-  If you want to list or add a server:
-    → Publish it to the MCP Server Registry instead
-      (https://github.com/modelcontextprotocol/registry).
-
-  Full policy:
-  https://github.com/modelcontextprotocol/servers/blob/main/CONTRIBUTING.md
-
-  Maintainers: delete this comment and the banner below, keep the first line
-  as `Closes #<ISSUE_NUMBER>`, and fill in the sections.
--->
-
 > **Heads up:** this repository accepts **issues, not pull requests**, from
 > anyone but the repository maintainers. Please read
 > [`CONTRIBUTING.md`](https://github.com/modelcontextprotocol/servers/blob/main/CONTRIBUTING.md) before continuing. If you're not a
 > maintainer, open an issue (and share the prompt you used, if you've already
 > built the change) rather than this PR. To make a server discoverable, publish
 > it to the [MCP Server Registry](https://github.com/modelcontextprotocol/registry).
-
-Closes #<ISSUE_NUMBER>
-
-## Description
-
-## Server Details
-
-<!-- If modifying an existing server, provide details -->
-
-- Server: <!-- e.g., filesystem, git -->
-- Changes to: <!-- e.g., tools, resources, prompts -->
-
-## Motivation and Context
-
-<!-- Why is this change needed? What problem does it solve? -->
-
-## How Has This Been Tested?
-
-<!-- Have you tested this with an LLM client? Which scenarios were tested? -->
-
-## Breaking Changes
-
-<!-- Will users need to update their MCP client configurations? -->
-
-## Types of changes
-
-<!-- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
-
-- [ ] Bug fix (non-breaking change which fixes an issue)
-- [ ] New feature (non-breaking change which adds functionality)
-- [ ] Breaking change (fix or feature that would cause existing functionality to change)
-- [ ] Documentation update
-
-## Checklist
-
-<!-- Go over all the following points, and put an `x` in all the boxes that apply. -->
-
-- [ ] I have read the [MCP Protocol Documentation](https://modelcontextprotocol.io)
-- [ ] My changes follows MCP security best practices
-- [ ] I have updated the server's README accordingly
-- [ ] I have added a changeset (`npm run changeset`) if this changes what a TypeScript server publishes
-- [ ] I have tested this with an LLM client
-- [ ] My code follows the repository's style guidelines
-- [ ] New and existing tests pass locally
-- [ ] I have added appropriate error handling
-- [ ] I have documented all environment variables and configuration options
-
-## Additional context
-
-<!-- Add any other context, implementation notes, or design decisions -->
diff --git a/AGENTS.md b/AGENTS.md
@@ -61,7 +61,7 @@ servers/
 │                             version-packages.yml (the changesets PR), prepare-python-release.yml (the CalVer PR),
 │                             claude.yml (@claude mentions)
 ├── .github/ISSUE_TEMPLATE/   Bug and feature issue forms; config.yml routes security and new servers away
-├── .github/pull_request_template.md   The "issues, not PRs" banner and the maintainers' PR checklist
+├── .github/pull_request_template.md   The "issues, not PRs" banner that turns outside PRs away
 ├── RELEASING.md              How packages are versioned and published, and how to recover a failed publish
 └── CONTRIBUTING.md           The contribution policy: issues, not PRs; what is accepted
 ```
@@ -278,7 +278,7 @@ holds for a maintainer's own one-line fix as much as for a feature.
   is merged with a merge commit, never squashed. The flow is the `release`
   skill.
 - **Exception: the two version PRs that automation opens.** Each changes
-  version metadata only, so neither answers the template checklist, and each
+  version metadata only, so neither answers the PR checklist below, and each
   is tied to its milestone's **release issue** rather than to an issue of its
   own.
   - The **Prepare Python Release** PR follows the rest of the rules: the
@@ -293,12 +293,13 @@ holds for a maintainer's own one-line fix as much as for a feature.
 
 No other PR is exempt.
 
-Every PR answers the checklist in
-[`.github/pull_request_template.md`](./.github/pull_request_template.md):
-the MCP documentation was read for the feature touched, the change follows MCP
-security best practices, the server's README is updated, and a **server-facing
-change was tested with an LLM client**, with the scenarios tested named under
-the template's "How Has This Been Tested?" heading.
+Every PR answers the PR checklist in its body: the MCP documentation was read
+for the feature touched, the change follows MCP security best practices, the
+server's README is updated, and a **server-facing change was tested with an LLM
+client**, with the scenarios tested named under the body's "How Has This Been
+Tested?" heading. The body's sections and the full checklist are in the
+`pr-flow` skill. [`.github/pull_request_template.md`](./.github/pull_request_template.md)
+is only the "issues, not PRs" banner; it does not carry them.
 
 ## Maintenance rules