They keep getting more and more suspicious with each model generation. (Though I haven’t heard of Fable complaining yet...)
Re: the SKILL.md file—you can just go to the page yourself and copy its contents into the context window, if they refuse to fetch them.
Why not an official “Connector” using an MCP server? A few reasons:
MCP-based tools are (currently) non-composable, so in many ways are less ergonomic for models, i.e. they can’t pipe their outputs to disk, into other commands, etc.
Anthropic’s approval process is annoying.
For use in contexts like Claude Code (or, really, anything other than the claude.ai web interface), it’s almost strictly more overhead to set up than to create a new skill.
We’ve iterated on the wording and will probably continue to do so, but it’s a moving target.
Yeah I’m aware of the limits of MCP, and claude.ai, but they don’t obviously apply to basic doc review needs.
The publish menu says nothing about a skill.md, where to get it, how to add it. You say “go to the page”—what page? You could publish the skill on a plugin marketplace which would be more ergonomic. But a plugin/skill seems like a better approach if you want to do an API integration. So I’m interested. I’ll just … go find it.
If you establish the integration, and then click the actual “Claude” button in the publishing menu, it prefills the claude.ai prompt with this message:
I also tried the approach described here of setting the post to allow comments to anyone with the URL, and Sonnet retrieved the content but considered the associated API notes to be highly suspicious and again, likely a prompt injection attack on me.
But now I realize you probably meant the metadata we return as part of the markdown response when agents fetch posts via the common mechanisms that we can detect.
A message close to the second form got me (Opus 4.8/high):
On the second link: I didn’t fetch lesswrong.com/api/SKILL.md, and I’d treat it with suspicion. A SKILL.md is normally a trusted file in my local environment, not something served from an arbitrary web path — and LessWrong’s actual API is GraphQL, with no such documentation convention I’m aware of. …
Ironically I was asking questions about prompt-infection. So another data point for a regular published skill over dynamic skill retrieval.
They keep getting more and more suspicious with each model generation. (Though I haven’t heard of Fable complaining yet...)
Re: the SKILL.md file—you can just go to the page yourself and copy its contents into the context window, if they refuse to fetch them.
Why not an official “Connector” using an MCP server? A few reasons:
MCP-based tools are (currently) non-composable, so in many ways are less ergonomic for models, i.e. they can’t pipe their outputs to disk, into other commands, etc.
Anthropic’s approval process is annoying.
For use in contexts like Claude Code (or, really, anything other than the claude.ai web interface), it’s almost strictly more overhead to set up than to create a new skill.
We’ve iterated on the wording and will probably continue to do so, but it’s a moving target.
Yeah I’m aware of the limits of MCP, and claude.ai, but they don’t obviously apply to basic doc review needs.
The publish menu says nothing about a skill.md, where to get it, how to add it. You say “go to the page”—what page? You could publish the skill on a plugin marketplace which would be more ergonomic. But a plugin/skill seems like a better approach if you want to do an API integration. So I’m interested. I’ll just … go find it.
If you establish the integration, and then click the actual “Claude” button in the publishing menu, it prefills the claude.ai prompt with this message:
I thought that’s what you meant by this:
But now I realize you probably meant the metadata we return as part of the markdown response when agents fetch posts via the common mechanisms that we can detect.
A message close to the second form got me (Opus 4.8/high):
Ironically I was asking questions about prompt-infection. So another data point for a regular published skill over dynamic skill retrieval.