I’ve been building Mandex, a CLI tool, and somewhere along the way I realized: shipping a dev tool in 2026 is a completely different game than it was even two years ago.
The bar is absurdly high. And it’s not because developers got pickier — it’s because the ecosystem moved.
fewer humans, more agents
Claude Code, Codex, Cursor — these are the only dev tools most people actually use now. and if you can build anything in under 24 hours for less than $1000 in tokens with them, why would anyone reach for your CLI?
that’s the real shift. it’s not just that the quality bar is higher — it’s that fewer and fewer humans are using dev tools directly. everything is an AI tool now. your users aren’t people typing commands. they’re agents deciding whether to invoke your tool or just do it themselves.
so you need skills. not just “here’s a skill file” — well-prompted, tested skills that agents actually use correctly. there’s a difference between “technically works” and “works well enough that an agent reaches for it naturally.” the prompting matters. the schema matters. the error messages matter. if an agent tries your tool once and gets a confusing response, it won’t try again.
and the skills need to install themselves. if your setup instructions say “clone this repo, copy the skill files into your agent’s config directory, and restart” — that’s too much friction. nobody’s doing that. the install command should handle everything: the binary, the PATH, and the agent skills. one command, done. if a developer has to manually wire up your tool to their agent, they’ll just skip it.
the checklist keeps growing
A CLI tool used to be: write the code, put it on npm, maybe write a README. Done.
Now? You need:
A website with proper docs. Not a README on GitHub — an actual documentation site. Searchable, organized, with examples. Developers expect this. Agents need it for context. If your docs are a single markdown file, you’ve already lost credibility.
A blog post explaining the why. Not just what the tool does, but why it exists, what problem it solves, how it works under the hood. Cross-post it everywhere — Dev.to, Hashnode, your own blog, Twitter threads. If people can’t find a thoughtful explanation of your tool, they assume it’s not thoughtful.
Seamless installation. npm install -g is table stakes. But the onboarding after that? It needs to be frictionless. OpenClaw nailed this — their first-run experience is so smooth it’s probably a big reason they got traction. The tool should figure out PATH issues on its own, work across shells, and require minimal hand-holding. Nobody wants to debug their ~/.zshrc to use your tool.
Skills that actually work. Not just “here’s a skill file” — skills that are tested against real agent workflows. Does Claude Code use it correctly? Does it handle edge cases? Does the skill give the agent enough context to know when to reach for your tool, not just how?
what this looks like in practice
with Mandex, I tried to get this right. the installer is a single curl:
curl -fsSL https://mandex.dev/install.sh | shthat one command does everything. it detects your platform — linux (glibc or musl), macOS, Windows — downloads the correct binary, drops it in ~/.local/bin, and auto-configures your PATH. it checks for .bashrc, .bash_profile, .zshenv, .profile, writes a source line to the right files, and skips what doesn’t exist. no “add this to your PATH manually” step. no debugging shell configs.
then it runs mx init, which auto-detects which AI agents you have installed — Claude Code, Cursor, Windsurf, Codex — and installs skills for each one. Claude Code gets a SKILL.md in ~/.claude/skills/mandex/. Cursor gets rules appended to ~/.cursor/rules. Codex gets an AGENTS.md entry. each skill is tailored to how that specific agent consumes instructions. one install, and every agent on your machine knows how to use mx.
the alternative — “download the binary, add it to PATH, then clone the skills repo, copy the right file to the right directory for your agent” — is three steps too many. nobody’s doing that for a tool they haven’t tried yet.
it’s exhausting and it’s fair
I won’t pretend this isn’t a lot. building Mandex, the actual CLI logic was maybe 30% of the work. the rest was everything around it — the installer, the agent skills, the docs site, the onboarding flow, making sure it plays nicely with four different agents on three operating systems.
but honestly? this is how it should be. the old world where you could ship a half-documented CLI and expect people to figure it out was never great. it just felt normal because everyone did it.
the new bar is higher, but the tools that clear it are genuinely better to use. as a developer, I want every tool I install to just work — for me and my agent, with zero hand-holding. as a tool author, that means I have to build all of it.
The standard for dev tools in 2026 isn’t just “does it work.” It’s “does it work for me and my agent, with minimal friction, and enough context to trust it.” That’s a high bar. But it’s the right one.