Complementarity with capability discovery (## Skills / SKILL.md), and a note on "skill" terminology

[MauricioPerera]

Really nice to see auth.md — the "agent-readable Markdown manifest at your domain, no server required" pattern is clearly the right shape, and it's encouraging to see it arrived at independently for the authentication layer.

I've been working on a closely adjacent piece and wanted to flag the relationship in case it's useful:

Different layers, naturally complementary.

• auth.md answers "how does an agent register/authenticate with this service?"
• A parallel effort adds a ## Skills section to llms.txt (pointing at Agent Skills SKILL.md files) to answer "what can an agent do here, and how?" — capability discovery.

A fully agent-ready domain could serve both: ## Skills for capabilities, AUTH.md for credential acquisition. They don't overlap; they compose. (Spec/impl, FWIW: https://github.com/MauricioPerera/llms-txt-skills)

One constructive terminology note. auth.md uses the word "skill" (and a skill field in the .well-known/oauth-authorization-server metadata) for the auth manifest. In the Agent Skills ecosystem, "skill" / SKILL.md already means a unit of agent capability. Implementers wiring up both may conflate them. Might be worth a sentence in the spec disambiguating auth.md's manifest from an Agent Skill — or, if alignment is intended, that's an even more interesting conversation.

Open question on discovery. auth.md discovers via .well-known metadata; capability discovery (in this other effort) leans on co-location in llms.txt plus a .well-known/agent-skills/index.json. Is there appetite to think about how these discovery surfaces relate, so domains don't end up with N disjoint pointers? Happy to compare notes.

Either way — great work, and glad to see momentum behind domain-hosted agent manifests.

[sergeliatko]

Great points, let's align! @MauricioPerera

[m0tzy]

Adding a skills section in llms.txt that has an entry pointing to /auth.md makes sense to me!

I do see the auth.md file being a skill — it tells the agent how to auth with a service. Whether it can/should be installed as a Skill is another question. In an ideal world, agent harnesses know "if I want to auth against a service, I look for an auth.md file" and that could be cached / added to memory vs. installed via a directory. Presumably these documents are alive and copying them to disk makes that harder to manage over time.

[MauricioPerera]

Thanks both — @sergeliatko, glad to align, and @m0tzy that's exactly the right distinction.

The ## Skills-in-llms.txt model is reference-by-pointer, fetched on demand — not install/copy-to-disk. An entry is just a discoverable link; the agent fetches the target when it actually needs it (and may cache it), but nothing is copied to a skills directory. That's precisely why a live document like auth.md fits cleanly: the llms.txt entry points at /auth.md, the agent reads the current version at auth time, and there's no stale copy to manage.

It also dissolves the terminology worry from the issue: auth.md doesn't have to be an installable Agent Skill (SKILL.md) to be discoverable the same way. It's a referenced capability doc ("how to authenticate here"), surfaced through the same co-located pointer mechanism, with no implication of installation.

Concretely, that's a one-line entry a site already serving auth.md can add:

- [auth](/auth.md): how an agent authenticates with this service

Happy to align on a minimal convention for that pointer so harnesses can rely on it. The reference/cache-vs-install split is worth stating explicitly — agents should treat auth.md (and other live docs) as fetch-on-demand, not install.