ext-skills/AGENTS.md
Sambhav Kothari 34315ab7d7
docs: align Skills corrections with the final SEP and website (#147)
The stable Skills page missed the final SEP's Agent Skills compatibility
clause, and its examples used abbreviated hashes and inconsistent byte
sizes. Archived drafts also retained current-sounding source-of-truth
guidance.

This corrects the stable page directly to match already-established
requirements: restores the compatibility clause, shows the resources
capability and server/discover, explains omitted request metadata, and
makes the example manifests and content consistent. It also labels
archived documents as historical and fixes the SEP domain in AGENTS.md.
This is an editorial alignment, not a new extension proposal; #142
remains separate.

Validation: all JSON examples parsed; all 13 manifest entries checked
against sample bytes for SHA-256 and size; the corrected specification
builds with the VitePress publishing site; git diff --check passed.

AI assistance: prepared with Codex.
2026-09-16 06:03:49 -07:00

2.5 KiB

What to reference as a source

IMPORTANT: The source of truth for the Skills extension (io.modelcontextprotocol/skills) is specification/stable/skills.mdx in this repository. It is the normative text of the extension, written against base protocol revision 2026-07-28, and is what the official documentation at modelcontextprotocol.io/extensions/skills/overview summarizes.

SEP-2640 is the accepted proposal behind the extension (Status: Final; PR #2640 merged 2026-09-13). docs/archive/sep-draft-skills-extension.md is a copy of that SEP text pinned at the commit named in its header, kept so Working Group discussion, meeting notes, and decision records can quote and link stable text. It is a historical baseline, not the current spec.

  • Answer questions about what the extension requires from specification/stable/skills.mdx, not from the SEP copy or the docs/ folder. Where the spec page and the SEP differ, the decision log records why (see the 2026-09-08 entry).
  • The docs/ folder holds design history, rationale, experimental findings, and trackers. Treat it as context, not as normative text.

Proposing changes to the specification

Changes are proposed here. The vehicle is a dated entry in docs/decisions.md with **Status:** Proposed, in the ADR-lite format used throughout that file (Status / Context / Decision / Rationale / References) — the PR carrying that entry is the proposal.

specification/stable/skills.mdx is a released snapshot and is not edited in place. Once a proposal is accepted, the resulting text lands in a draft revision of the specification (a draft/ directory alongside the released text, following the layout used by ext-tasks), the entry's status is updated to Accepted, and the draft ships as a new stable revision when released.

When a decision supersedes or amends an earlier one, add a forward pointer to the earlier entry's **Status:** line rather than rewriting the entry. The log is an auditable trace of the group's reasoning over time, not a snapshot of current state.

See CONTRIBUTING.md for participation, meetings, decision-making authority, and full decision-log guidance.