I really like the way you can expose your schema through adding fields to a web form, that feels like a really nice extension and a great way to piggyback on your existing logic.
To me this seems much more promising than either needing an MCP server or the MCP Apps proposal.
Demo I built 5 months ago: https://www.youtube.com/watch?v=02O2OaNsLIk
This exposes ecommerce specific tool calls as regular javascript functions as it is more lightweight than going the MCP route.
It's great they are working on standardizing this so websites don't have to integrate with LLMs. The real opportunity seems to be able to automatically generate the tool calls / MCP schema by inspecting the website offline - I automated this using PLayright MCP.
Heh, is through Claude Code? I have a side project where I'm sometimes using Claude Code installs for chat, and it usually doesn't mind too much. But when I tested the Haiku model it would constantly complain things like "I appreciate the question, but I'm here to help you with coding" :)
It asked through Cursor. Usually Claude doesn't complain that it isn't relevant to coding, but this was in my all purpose coding problems project with quite a long chat history already.
I've got a heirarchical structure for my CC projects. ~/projects/CLAUDE.md is a general use context that happily answers all sorts of questions. I also use it to create project specific CLAUDE.md files which are focused on programming or some other topic. It's nice to have the general fallback to use for random questions.
Something I learned while hacking on something recently is that claude’s non-interactive mode is super powerful. It uses all the same tools/permissions etc as interactive would, it can stream responses as JSON with tool use etc, and it can resume from a previous session. Together this means you can actually build a really slick chat-like UI for it.
This is using Claude on VMs that don’t have SSH, so can’t use a regular terminal emulator. They stream responses to commands over websockets, which works perfectly with Claude’s streaming. They can run an interactive console session, but instead I built a chat UI around this non-interactive mode.
We use Slack at work, and everyone we work with uses Slack, and we all work together with Slack Connect. I suspect if we moved to a competitor that’s pretty much the main impact we’d see, and it wouldn’t be good unless everyone else work with moved too. I think that network effect is probably the only meaningful differentiation in that space.
You could also look at it as: in order for a Slack competitor to compete with Slack's network effects, the new program will need to offer an easy way to extend chat workspaces with external collaborators. It's not impossible, but it does make Slack's moat explicitly clear.
The problem here is that companies artificially limit integrations, so it's impossible to exchange messages between different providers like how email works.
I’ve always thought that the proper competitor to Slack/Twitter/etc… was a protocol not another service. Protocols enable competition, services just shift the market to another service.
We really need some legal requirements similar to "right to repair" for machinery. We need "right to integrate" for software. I don't know how you'd pull it off, or how much support for integrations would be "enough" but it would allow competitors to cross these network effect lock-in moats that large players are able to build.
Maybe I'm just really lucky but reading those instructions it's basically how I find Claude Code behaves. That repo with 4k stars is only 2 weeks old as well, so it's obviously not from a much less competent model.
Same here, I find most of these skills/prompts a bit redundant. Some people argue that in including these in the conversation, one is doing latent space management of sorts and bringing the model closer to where one wants it to be.
I wonder what will happen with new LLMs that contain all of these in their training data.
I keep wondering if this is what kills GitHub. Anthropic have done a pretty good job of making Claude work well with GitHub, and it makes all the GitHub agent stuff feel pointless to me. But they keep adding it in more and more places, and I’m guessing most people just keep ignoring it and using Claude.
Would they think it’s worth introducing restrictions to make it harder to use Claude with GitHub in the hopes that it forces us to use their endless collection of agent stuff instead? I think they probably would choose that tradeoff.
I don’t think there’s any solution to what SimonW calls the lethal trifecta with it, so I’d say that’s still pretty impossible.
I saw on The Verve that they partnered with the company that repeatedly disclosed security vulnerabilities to try to make skills more secure though which is interesting: https://openclaw.ai/blog/virustotal-partnership
I’m guessing most of that malware was really obvious, people just weren’t looking, so it’s probably found a lot. But I also suspect it’s essentially impossible to actually reliably find malware in LLM skills by using an LLM.
Regarding prompt injection: it's possible to reduce the risk dramatically by:
1. Using opus4.6 or gpt5.2 (frontier models, better safety). These models are paranoid.
2. Restrict downstream tool usage and permissions for each agentic use case (programmatically, not as LLM instructions).
3. Avoid adding untrusted content in "user" or "system" channels - only use "tool". Adding tags like "Warning: Untrusted content" can help a bit, but remember command injection techniques ;-)
4. Harden the system according to state of the art security. 5. Test with red teaming mindset.
Anyone who thinks they can avoid LLM Prompt injection attacks should be asked to use their email and bank accounts with AI browsers like Comet.
A Reddit post with white invisible text can hijack your agent to do what an attacker wants. Even a decade or 2 back, SQL injection attacks used to require a lot of proficiency on the attacker and prevention strategies from a backend engineer. Compare that with the weak security of so called AI agents that can be hijacked with random white text on an email or pdf or reddit comment
There is no silver bullet, but my point is: it's possible to lower the risk. Try out by yourself with a frontier model and an otherwise 'secure' system: the "ignore previous instructions" and co. are not working any more. This is getting quite difficult to confuse a model (and I am the last person to say prompt injection is a solved problem, see my blog).
> Adding tags like "Warning: Untrusted content" can help
It cannot. This is the security equivalent of telling it to not make mistakes.
> Restrict downstream tool usage and permissions for each agentic use case
Reasonable, but you have to actually do this and not screw it up.
> Harden the system according to state of the art security
"Draw the rest of the owl"
You're better off treating the system as fundamentally unsecurable, because it is. The only real solution is to never give it untrusted data or access to anything you care about. Which yes, makes it pretty useless.
Wrapping documents in <untrusted></untrusted> helps a small amount if you're filtering tags in the content. The main reason for this is that it primes attention. You can redact prompt injection hot words as well, for cases where there's a high P(injection) and wrap the detected injection in <potential-prompt-injection> tags. None of this is a slam dunk but with a high quality model and some basic document cleaning I don't think the sky is falling.
I have OPA and set policies on each tool I provide at the gateway level. It makes this stuff way easier.
The issue with filtering tags: LLM still react to tags with typos or otherwise small changes. It makes sanitization an impossible problem (!= standard programs).
Agree with policies, good idea.
I filter all tags and convert documents to markdown as a rule by default to sidestep a lot of this. There are still a lot of ways to prompt inject so hotword based detection is mostly going to catch people who base their injections off stuff already on the internet rather than crafting it bespoke.
Agree for a general AI assistant, which has the same permissions and access as the assisted human => Disaster. I experimented with OpenClaw and it has a lot of issues. The best: prompt injection attacks are "out of scope" from the security policy == user's problem.
However, I found the latest models to have much better safety and instruction following capabilities. Combined with other security best practices, this lowers the risk.
> I found the latest models to have much better safety and instruction following capabilities. Combined with other security best practices, this lowers the risk.
It does not. Security theater like that only makes you feel safer and therefore complacent.
As the old saying goes, "Don't worry, men! They can't possibly hit us from this dist--"
If you wanna yolo, it's fine. Accept that it's insecure and unsecurable and yolo from there.
Honestly, 'malware' is just the beginning it's combining prompt injection with access to sensitive systems and write access to 'the internet' is the part that scares me about this.
I never want to be one wayward email away from an AI tool dumping my company's entire slack history into a public github issue.
reply