Inverse CLI and Skill dependency

[Corb3nik]

Currently, the skill has an internal caido CLI as a resource.

The setup process requires then to:

• Install the skill
• Install the deps for the caido CLI resource
• Use the skill

This puts the burden on the user to install the deps, use the right package manager, etc...
This makes the process error-prone.

Solution

I propose that we make a caido/cli tool, and publish it as a package on npm.

The caido-cli tool would then have a setup-skills that guides the user to the process of setting up the skill for codex, claude, cursor, etc.

The setup process then becomes

npx install -g caido/cli
caido/cli setup-skills

Benefits:

• The process is a lot less error prone. User must have npx, that's it.
• caido-cli becomes a global binary, easy to access from anywhere
• The skills are hosted in the caido/cli project, making them versioned.
  • When we add new functionality to the CLI, we update the skills to match
  • If we want to patch the skills, it gets a version

[m4dni5]

I like the idea of easing the setup pain, but for me there's a deeper design question of why we're driving Caido through the CLI to begin with and who the consumer of that CLI tool is. In its current state we have a Caido instance providing a GraphQL API, wrapped in the sdk-js, in turn wrapped in a CLI interface.

The behavior I have observed with my agent using caido-mode, is that when I really pressed it to do something the CLI tool didn't yet encapsulate, it leveraged GraphQL introspection and started using the API directly.

I think there's some more exploration to do on that front, and probably some pros and cons to enumerate. But the idea of eliminating several layers by providing the agent with the schema as reference and some "go-to" patterns feels pretty attractive to me. With a fallback mode of "use GraphQL introspection to update your reference", we eliminating a lot of maintenance surface area.

Footnote here that caido-cli is the CLI tool for running a Caido instance.

[Sytten]

We do need to change the name of the current caido-cli to something else like caido-server.

I think it comes down to token usage, the skill or the MCP consumes less tokens for the same operation than using the graphql API directly. It is also more reliable for more complex operations that might require multiple API calls (thinking about our new replay api which requires 3 calls).

[m4dni5]

It's a good point about tokens. I started thinking about switching the skill to composing with sdk-python and ultimately started writing a Hermes plugin. That's the agent I'm using anyway and I can bundle skills for the more advanced operations. The core functionality is exposed as tools, the bundled skills use a small Python library and load as needed. Work in progress if you're curious.

[Sytten]

Just an FYI @m4dni5, I still have not repaired the sdk-python for the v0.57.0 API changes so you might see some errors there. Looks cool otherwise!