Sources & Confidence

The harness claims across this site are not equally well-sourced, and the difference matters when you are deciding how much to rely on one. Supporting evidence is recorded in .research/agentic-configuration-standards/, .research/mcp-canonical-location/, and .research/plugin-skill-naming/ in the repository.

Claim	Confidence	Basis
Codex, Copilot CLI, and Cursor skill discovery paths	High	primary vendor documentation
Claude Code reading neither .agents/skills nor ~/.agents/skills	High	primary vendor documentation, plus an independent bug report at user scope
Claude Code reading AGENTS.md from v2.1.277, and a CLAUDE.md beside it suppressing that	High	primary vendor documentation, including the vendor’s own table of which file is read
Frontmatter field origins	High	primary vendor documentation
Devin Desktop skill paths and the rebrand	High	official vendor announcement and documentation
Antigravity and VS Code skill paths	High / Medium	primary vendor documentation
Posit Assistant reading .agents/skills at both scopes and AGENTS.md as project memory	High	primary vendor documentation, which publishes the default search order and the memory filenames
Gemini CLI reads .agents/skills at both scopes	High	the Gemini CLI discovery source, corroborated by its documentation
Gemini CLI context.fileName	Medium	project documentation, partly an issue thread
JSON comment tolerance in .gemini/settings.json and .claude/settings.json	High	the Gemini CLI loader source, and Claude Code documentation plus an open request for JSONC support
Cursor’s Agent-mode-only AGENTS.md support	Medium	secondary comparisons, not primary Cursor documentation
AGENTS.md context cost and length guidance	Low	practitioner analysis and reported measurements, no vendor specification
Claude Code skill runtime fields, and their turn-scoping	High	primary vendor documentation
user-invocable and disable-model-invocation being independent	High	primary vendor documentation, including the vendor’s own comparison table
A missing description falling back to the body’s first paragraph	High	primary vendor documentation
commands/ being merged into skills rather than deprecated	High	primary vendor documentation
What an agent definition can express that a skill cannot	High	primary vendor documentation
Claude Code skill arguments, and the fields the spec rejects	High	primary vendor documentation
Codex skills having no argument mechanism	High	absence from the vendor page that supersedes custom prompts
Cursor rule selection via globs / description / neither	High	primary vendor documentation
Copilot applyTo path-specific instructions	High	primary vendor documentation
Nested AGENTS.md resolution (nearest-file-wins)	High	agents.md body copy and FAQ, primary
Claude Code concatenating every discovered CLAUDE.md	High	Claude Code memory documentation, primary
Nested-resolution semantics beyond precedence	Low	unratified v1.1 proposal, no maintainer response
A standard local-override file (AGENTS.local.md)	Low	absent from the standard; three open issues, two candidate names
MCP configuration having a cross-harness mapping that is not lossless	High	primary vendor documentation per host, plus inspection of the published agent-install registry
Per-harness project-scope MCP files, keys, and formats	High	primary vendor documentation per host
Per-harness MCP entry shape — transport selection, reference syntax, timeout unit	High / Medium	primary vendor documentation per host; Cursor’s remote-transport-selection field and its timeout/enable/description fields are unverified rather than confirmed absent
No standard naming an MCP configuration location	High	the MCP specification’s silence, plus the open standards-track proposals themselves
The .agents/mcp.json proposal being unaffiliated and unadopted	Medium	the draft’s own site; nothing establishes that anyone reads it
Only Claude Code addresses a plugin’s skill as plugin:skill and lets one plugin depend on another; Codex, Cursor, and Copilot CLI name skills bare	High	primary vendor documentation for each; the absence claims are checks of each vendor’s plugin manifest and skills reference

Not established

Two claims about instruction files are left unstated rather than guessed:

• whether Devin Desktop reads AGENTS.md,
• whether Antigravity reads AGENTS.md.

Both vendors document skills without addressing repository instructions. Their rows in Harness Differences say “not established” for that column rather than assuming either way.

The two standards disagree about a missing description

Claude Code documents that an omitted description “uses the first paragraph of markdown content.” The Agent Skills client-implementation guide prescribes the opposite: a missing or empty description means the skill is skipped.

Both are primary and both are current, so the disagreement is real rather than a sourcing gap. A skill relying on either behavior is not portable, which is why Direct Invocation Skill requires an explicit marker string rather than an absent field.

Harness settings files are documented only where verified

This site does not carry a table of per-harness settings files (.claude/settings.json, .cursor/permissions.json, ~/.codex/config.toml, and peers) covering tool permissions, hooks, and environment defaults. The readily available sourcing for several of those rows is third-party blog posts rather than vendor documentation, and this project does not publish harness claims at that confidence. Adding the table is a research task rather than an editing one.

What is documented is what has been verified and what initialization depends on. Settings are not wholly outside init’s reach: it edits .gemini/settings.json to add AGENTS.md to context.fileName, which is why JSON configuration disagrees about comments is on the site. That claim was established by testing, and it governs a file init writes to.

Corrections

A claim that turns out to be wrong is corrected in place and recorded here. The entry stays after the page is fixed, so you can tell whether something you read earlier has since changed.

2026-09-28 — Cursor was said to read AGENTS.md in Agent mode only

Cursor stated that Cursor reads AGENTS.md in Agent mode alone, that Chat and Composer read .cursorrules and .cursor/rules/*.mdc instead, and that a repository consolidating into AGENTS.md would lose its instructions in two of three surfaces. The claim was sourced to third-party comparisons and marked contested. Cursor’s own documentation contradicts it. Under “Do rules apply in all modes?”: “Yes. Project rules, user rules, and team rules apply in Agent, Ask, Plan, and Debug modes. The rules are included in every conversation regardless of which mode you’re using.”

The claim’s premise was outdated as well. Chat, Composer, and Agent were merged into one interface in v0.46 — “No more confusion between Chat, Composer, and Agent” — and “Composer” now names a model, so the two surfaces said to lose their instructions had not been separate readers for roughly a year and a half. The likely origin is Cursor’s own phrase “Rules only apply to Agent (Chat)”, which names the agent chat surface as against Tab completion, Inline Edit, and Bugbot PR reviews, not Agent mode as against Ask mode.

Corrected at Cursor, and the “Cursor’s mode split is not confirmed” section above was removed rather than rewritten, because the claim is now settled and false rather than unconfirmed. Evidence: E-CUR-05, E-CUR-06, E-CUR-07, superseding E-CUR-02.

Project behavior changed with it. Cursor is no longer described as having an instruction gap, and init no longer offers to leave a generated copy of a consolidated .cursorrules or .cursor/rules/*.mdc behind to keep other modes working — no mode needed keeping. What it offers instead is the trade that is real: a rule carrying globs or a description loads conditionally, and the same content in AGENTS.md loads on every turn. One further finding came out of the same research (E-CUR-07): Cursor reads CLAUDE.md the same way it reads AGENTS.md and applies it to every conversation regardless of alwaysApply, which gives the existing never-write-a-CLAUDE.md rule a second and independent reason.

2026-09-27 — Gemini CLI was said to expand a variable only inside env

mcp project stated that Gemini CLI expands a variable reference only inside a server’s env, and refused a server with a reference anywhere else, such as Authorization = "Bearer ${TOKEN}". That was wrong. Gemini CLI’s configuration reference documents expansion of $VAR, ${VAR}, and ${VAR:-default} in every string value of settings.json, and its source does the same.

Corrected at Dialects. The behavior changed with it: mcp project now writes such a server into .gemini/settings.json as written.

2026-09-27 — Copilot CLI was said to document no project-scope MCP file

MCP Servers stated that Copilot CLI’s absence from the MCP targets was a documented absence. That is no longer true. GitHub now documents project-scope .mcp.json and .github/mcp.json for Copilot CLI.

Corrected in place. The behavior has not changed: Copilot CLI is still not an MCP target, because its first file is Claude Code’s .mcp.json and which file to write for it is undecided.

2026-08-18 — MCP was said to have no cross-harness mapping

Six pages and skill files stated that MCP servers stay canonical because “no safe cross-harness mapping exists”. That was wrong. One exists and is published, mapping server configuration across fourteen hosts, six config keys, and three file formats.

Corrected at What stays canonical, which now separates MCP (a published mapping that is not lossless) from custom agents, hooks, and rules (no published specification at all). The other five locations link there instead of restating a reason. What has not changed is the behavior: this project still does not convert MCP configuration.

2026-08-18 — Settings files were said to be outside initialization’s reach

This page gave two reasons for not documenting harness settings files. The second, that “settings are outside what initialization touches”, was false: init edits .gemini/settings.json to add AGENTS.md to context.fileName. The sourcing-quality reason was and remains true. The section above now states only that one.

2026-08-18 — help was said to be pasteable except for the instruction repairs

The doctor page said the four instruction repairs “are the one place help cannot be pasted into a terminal”. That was wrong when it was written. Every help line was rendered as Run `<repair>` whether or not the repair was a command, so a configuration finding published lines like Run `remove .windsurf/skills and enable the harness that replaced it` — prose wrapped in an imperative to run it. The diverged-both repair had the same shape from the start, with half the instruction inside the backticks and half outside.

Corrected at Output, and the behavior changed with it: help is now one row per repair with a command column and an instruction column, and command is empty wherever no single invocation completes the repair. A caller no longer has to read the prose to find out whether it may run something. The same page’s sample report was also a version behind — it showed findings without the problem column that finding rows have carried since the configuration checks shipped.

2026-09-16 — Skill scripts were said to depend on the install carrying node_modules

Skill Scripts said the choice was between an npm-sourced install, which carries a plugin’s dependency tree, and a git-sourced one, which does not — so a script with dependencies “wants the npm route” because that route alone happened to carry node_modules. That claim was itself only low-confidence direct observation (see the removed “Plugin dependencies installed for an npm source but not a git source” row above), and this project’s own shipped skills have since stopped relying on it: doctor, init, and repair each now run a bundle — built from the package’s source, with every runtime dependency inlined — that ships inside the skill folder itself rather than depending on a node_modules sitting above it.

Corrected at the same page, which now advises bundling the script per skill at build time and shipping the result through whichever channel already ships the rest of your code, rather than choosing a distribution channel for the sake of carrying a dependency tree. Project behavior changed with it: the shipped launchers are now self-contained bundles, built and packed by prepack, gitignored rather than committed, with the pinned npx fallback reserved for a git-sourced install or a path the agent cannot resolve.

2026-09-19 — Claude Code was said not to read AGENTS.md

Six pages stated that Claude Code “reads CLAUDE.md, not AGENTS.md”, and prescribed a CLAUDE.md containing @AGENTS.md as the instruction bridge for it. From Claude Code v2.1.277 that is wrong: it reads AGENTS.md as the project’s instructions with no import, no symlink, and no setting. What is true instead is the condition on that default — a CLAUDE.md, .claude/CLAUDE.md, or CLAUDE.local.md in the working directory or above it is read instead, and AGENTS.md is then never seen. So the file this project used to prescribe is now the thing that costs a repository its instructions, unless it is an @AGENTS.md import or a symlink, which still deliver the canonical file.

Corrected at Claude Code, which is the one home for the rule, the sessions where the import is still required, and the setting a repository cannot set for its contributors. The other pages link there. Gemini CLI is now the only harness in the registry needing an instruction bridge; the Claude Code skills projection is unaffected.

Project behavior changed with it. init no longer writes a CLAUDE.md, at the root or beside a nested AGENTS.md: a generated copy would be read in place of the file it was copied from. An existing CLAUDE.md with content of its own is consolidated into AGENTS.md on approval and then removed, and one that is only an import or a symlink is offered for removal rather than removed, because the sessions above still need it. doctor gained two findings in the instructions family, instructions-shadowing and instructions-superseded, and the section’s statuses are now ok, missing, unbridged, unreadable, shadowing, and superseded.

Undocumented but verified

Claude Code parses .claude/settings.json, .claude-plugin/plugin.json, and .claude-plugin/marketplace.json as strict JSON. Comments and trailing commas are total parse failures, not warnings. The vendor settings page documents five settings filenames and says nothing about comments either way, so this was established against Claude Code 2.1.234 by testing each file with claude plugin validate and claude doctor. It is verified behavior, not a contract, and could change without notice.

Symlinking the .claude/skills directory itself is not documented by Claude Code, which documents per-skill symlinks instead. The directory-level link is verified working and preferred because it is live, but it is supported in practice rather than guaranteed by contract. Per-skill links remain the documented fallback.

Unratified upstream proposals

Two claims on this site describe upstream work that is proposed rather than adopted, and both are labelled as such where they appear:

• the v1.1 accumulation model for nested AGENTS.md, which would move the standard toward Claude Code’s existing behavior rather than away from it,
• a local-override file, requested in three open issues under two different filenames with two different semantics.

Neither has a maintainer resolution. They are recorded because the divergence they describe is real today, not because either outcome is expected. Positions this project has taken on them are tracked in unsettled upstream questions.

The specification’s file-reference guidance is recorded as E-STD-06. Its first sentence reads as a ban on subdirectories and its second glosses it as a limit on reference chains; Best Practices takes the second reading, and the layout itself is explicitly unconstrained.

An unresolved third-party discrepancy

The vercel-labs/skills README claims 75 supported agents while its public listing shows twenty. The discrepancy is unresolved; prefer the list to the number.