@javimosch/quickstart-3
AInstall
agr install @javimosch/quickstart-3 --target claudeWrites 1 file into .claude/skills/, pinned to git-a9276690.
- .claude/skills/quickstart-3/SKILL.md
Document
---\nname: ag\ndescription: The Silver Searcher\n---\n# ag Plugin\nThe Silver Searcher
Repository README
Describes javimosch/supercli as a whole, which may contain artifacts other than this one. Where this artifact had no useful description of its own, its summary was taken from here.
10,000 tools. One command. Zero friction.
โก TL;DR
Turn any CLI, API, or workflow into a discoverable, executable capability โ with consistent inputs, outputs, and zero glue code.
# Discover what exists (JSON by default)
npx supercli skills search "deploy"
# Understand exactly how to use it
npx supercli skills get aws.cfn.deploy
# Execute with predictable output (JSON by default)
npx supercli aws cfn deploy --stack-name my-stack
# For human-readable output, add --human
npx supercli aws cfn deploy --stack-name my-stack --human
๐ Works the same across CLI tools, APIs, MCP servers, and workflows ๐ No glue code, no parsing, no guesswork
Table of Contents
- Quick Start
- For Humans
- For AI Agents
- What You Get
- CLI Usage Examples
- Architecture
- Capability Sources
- Output Envelope + Exit Codes
- Operating Modes
- Install
- Troubleshooting
- Tech Stack
- Community & Social
โก Example
npx supercli ask "list my tasks and recent commits"
{
"tasks": [...],
"commits": [...]
}
โ Combines multiple tools into one structured response.
The Problem
Every tool speaks a different language:
- CLIs โ flags & inconsistent output
- APIs โ schemas & auth
- MCP/tools โ custom protocols
- Workflows โ glue code everywhere
Humans waste time learning syntax. Agents fail because nothing is predictable.
Without supercli, integrating a new tool means:
- Finding and reading its documentation
- Learning its flag syntax and output format
- Writing glue code to parse and transform the output
- Handling edge cases and error states manually
- Repeating for every additional tool
For agents, the situation is worse โ every tool responds differently, errors are unstructured, and there's no way to discover capabilities dynamically.
The Solution
supercli turns everything into capabilities:
- Same structure โ
supercli <namespace> <resource> <action> - Same output โ deterministic JSON envelopes
- Same discovery โ searchable skill graph
- Same execution โ no custom integrations
With supercli:
- Discover what's available via
supercli skills search "backup"โ no docs needed - Inspect the exact interface via
supercli inspect <ns> <res> <act>โ see every argument, type, and default - Execute with
--jsonโ get structured output every time - Combine via
supercli ask "do X and Y"โ no shell scripting required - Extend via plugins โ add any CLI, API, or MCP server with one command
โก Quick Start
# Explore capabilities (JSON by default)
npx supercli help
npx supercli skills search "github"
# Run something real (JSON by default)
npx supercli beads issue list
npx supercli gh issue list
# For human-readable output, add --human
npx supercli beads issue list --human
# AI-driven execution
npx supercli ask "show my tasks and recent commits"
# Manage plugins
npx supercli plugins list
npx supercli plugins explore
npx supercli plugins install commiat
# Inspect a capability before using it
npx supercli inspect http check health
# โ Shows: args, types, defaults, required/optional, description
๐ก Install globally:
npm install -g superaclifor repeated use. Server mode: See docs/features/server-plugins.md
For Humans
| Instead of... | You do... |
|---|---|
| Installing 50 tools separately | One command: npx supercli |
| Reading man pages for flags | supercli skills get <tool>.* โ structured metadata |
| Parsing inconsistent output | JSON by default, --human for readable output |
| Gluing tools with shell scripts | supercli ask "do X and Y" |
What this means day-to-day:
- No install friction โ
npx supercli <tool>works immediately, noapt-get,brew, ornpm i -g - No syntax learning โ Every tool uses the same three-word command pattern, just change the namespace
- No output parsing โ JSON by default for scripts/pipes,
--humanfor terminal display - No context switching โ One terminal, one interface, 10,000+ tools available
๐ก Important: supercli is JSON-first by default. Add
--humanfor human-readable output in your terminal.
For AI Agents
- ๐ Discoverable โ
supercli skills search "database"returns machine-readable metadata (JSON by default) - ๐ฆ Deterministic โ Every tool returns JSON by default, accepts
--humanfor readable output,--silent(no interactive prompts) - ๐จ Predictable errors โ Standard error codes:
82(validation),105(integration),110(internal) - ๐ Composable โ
supercli ask "check status and send alert"chains tools automatically - ๐ Auditable โ Every call logs namespace, resource, action, inputs, outputs, duration
- ๐ง Self-describing โ
supercli inspect <ns> <res> <act>exposes full argument schemas with types and defaults - โป๏ธ Idempotent โ Same inputs always produce same output shape, enabling retry and reconciliation
# Agent workflow: discover โ inspect โ execute โ all machine-readable (JSON by default)
supercli skills search "deploy"
supercli skills get aws.cfn.deploy
supercli aws cfn deploy --stack my-stack
For agent developers: always start with supercli for self-documenting bootstrap โ it returns the full capability graph schema (JSON by default). Then use supercli skills search <query> to narrow down, and supercli inspect <ns> <res> <act> before calling any command to validate argument expectations.
What You Get
supercli turns any tool into a first-class capability with a consistent interface:
- ๐ Discover without docs โ
supercli skills search "database"returns every matching capability with descriptions, tags, and argument schemas. No man pages, no README hunting. - โก One command pattern โ Every tool follows
supercli <ns> <res> <action> [--flags]. Learn one pattern, access 10,000+ tools. - ๐ค Built for agents โ Every capability returns structured JSON by default, accepts
--humanfor readable output, and self-describes viainspect. No parsing, no guesswork. - ๐ Chain without glue โ
supercli ask "check status and send alert"composes multiple capabilities automatically. No shell scripts, no middleware. - ๐ฆ Extend anything โ Add CLIs, APIs, or MCP servers as capabilities with one command via the plugin registry.
- ๐ Full audit trail โ Every call logs namespace, resource, action, inputs, outputs, and duration. Know exactly what ran and how long it took.
- ๐จ Predictable errors โ Standard exit codes (
82validation,105integration,110internal) let scripts and agents handle failures deterministically.
๐ ๏ธ CLI Usage Examples
# Discovery (JSON by default)
npx supercli skills list
npx supercli skills search "database"
# Inspection (important for agents)
npx supercli inspect beads issue create
npx supercli skills get beads.issue.create
# Execution (JSON by default)
npx supercli beads issue create --title "Fix bug"
npx supercli beads issue list
npx supercli gwc drive files list
# For human-readable output, add --human
npx supercli beads issue list --human
# AI
npx supercli ask "do X and Y"
# Plugins
npx supercli plugins list
npx supercli plugins install commiat
npx supercli plugins show commiat
๐๏ธ Architecture
Capability Graph
supercli models every tool, API, and workflow as a capability โ a named, typed, executable unit with a consistent interface. Capabilities form a graph where each node represents a tool function and edges represent composition possibilities.
The capability graph is the core abstraction. Instead of learning N different tool interfaces, you interact with one graph that routes to the right underlying system. All 10,000+ tools are nodes in this graph, addressable by the same triple pattern.
The Router
The router is the central brain that connects user commands to capabilities:
- Discovers capabilities from every adapter (bundled plugins, remote registry, MCP servers, HTTP APIs), caches metadata for sub-millisecond lookup
- Routes commands to the correct execution harness based on
<namespace> <resource> <action>โ the same triplet for every tool - Executes with unified error handling, consistent JSON envelopes, and output formatting (
--json,--human,--compact) - Surfaces machine-readable descriptions so agents can inspect, plan, and chain capabilities without guesswork
The routing pipeline processes every command in four phases:
- Parse โ Extracts
<namespace> <resource> <action>and separates flags from positional arguments. The same parser handles every command, regardless of the underlying tool. - Resolve โ Looks up the capability in the metadata cache. For cached capabilities this takes <1ms. New capabilities are discovered from the appropriate adapter and cached for subsequent calls.
- Route โ Dispatches to the correct execution harness based on capability type: CLI wrapper, MCP bridge, HTTP adapter, or workflow engine. Each harness handles transport-specific concerns like timeouts, retries, and protocol negotiation.
- Execute โ Runs the underlying tool with unified error handling, timeout management, and structured output formatting. Returns a deterministic JSON envelope every time.
Adapter Layer
Four adapter types bridge external systems into the capability graph:
| Adapter | What It Wraps | When To Use |
|---|---|---|
| CLI | 10,000+ CLI binaries | Running shell commands with JSON output, timeout management, structured error handling |
| MCP | Model Context Protocol servers | Connecting MCP-compatible tools into the same routing graph |
| HTTP | REST endpoints | Turning any API into a callable capability with configurable methods, headers, and body schemas |
| Workflow | Multi-capability chains | Composing multiple tools via supercli ask "do X and Y", auto-resolving dependencies |
Each adapter normalizes its target into the same internal representation: a capability record with name, description, argument schema, and execution handler. Every tool โ whether a CLI binary, an MCP server, or a REST API โ looks identical to the router.
Plugin System
The plugin system keeps capabilities organized and discoverable:
- Each plugin bundles a manifest (
plugin.json) with metadata, checksums, commands, and dependency requirements - Installed plugins register in
~/.supercli/plugins/plugins.lock.json - The Zig binary (
sc-zig), the machin binary (sc-machin), and the Node.js runtime (sc) all read the same plugin storage โ they co-exist and share state - The remote registry at
plugins/catalog.jsontracks 10,000+ community plugins with checksum-verified updates - Every capability includes description, tags, argument schemas, and install guidance
Summary
supercli replaces tool-specific syntax with a queryable, executable capability graph โ one interface for every tool, discoverable by humans and agents alike.
๐ฆ Capability Sources
supercli draws capabilities from four source types:
| Source | Count | How to Add | Description |
|---|---|---|---|
| Bundled plugins | 10,000+ | Auto-discovered from plugins/ | CLI binaries wrapped with metadata, args, and tags |
| MCP servers | Unlimited | supercli mcp add <name> --url <url> | Model Context Protocol servers (stdio or SSE) |
| HTTP APIs | Unlimited | supercli http <method> <url> | REST endpoints as callable capabilities |
| Custom adapters | Unlimited | Server UI or supercli sync | User-defined JS in sandboxed vm2 runtime |
Every capability includes description, tags, argument schemas, and checksum-verified metadata.
๐ค Output Envelope + Exit Codes
Every command returns a consistent JSON envelope:
{
"version": "1.0",
"command": "http.check.health",
"duration_ms": 142,
"data": { "status": "ok" }
}
| Exit Code | Meaning |
|---|---|
0 | Success |
82 | Validation error |
105 | Integration error |
110 | Internal error |
All tools return JSON by default. Add --human for readable output, --silent for machine-consumable output without prompts.
โ๏ธ Operating Modes
| Mode | Command | What It Does | When To Use |
|---|---|---|---|
| Direct | <ns> <res> <act> [--flags] | Executes a specific capability with arguments | Running a known tool, scripting |
| Ask | supercli ask "do X and Y" | AI-driven composition chains multiple capabilities | One-shot tasks, complex workflows |
| Inspect | supercli inspect <ns> <res> <act> | Shows argument schema, types, descriptions, defaults | Before running an unfamiliar command |
| Discover | supercli skills search <query> | Searches all capabilities by name, description, tags | Finding what tools are available |
| Server | supercli server | Starts HTTP or MCP server exposing all capabilities | Remote access, IDE integration, API gateway |
All five modes return JSON by default. Add --human for readable display. Agents should always start with supercli for self-documenting bootstrap โ it returns the full capability graph schema (JSON by default).
๐ฆ Install
Three implementations, all co-exist and share plugin storage at ~/.supercli/plugins/plugins.lock.json. Pick one (or more):
Option 1: Zig Version (Fastest, Single Binary)
curl -sSL https://github.com/javimosch/supercli/releases/download/v0.1.0-zig/install.sh | bash
- โ Single static binary (~250KB), no Node.js required
- โ Fastest startup, native performance
- โ
Reads same
~/.supercli/plugins/plugins.lock.json
Option 2: Machin Version (MCP Server, Single Binary)
curl -sSL https://github.com/javimosch/supercli/releases/download/v0.2.0-machin/install.sh | bash
- โ Single binary (~71KB), no Node.js required
- โ
Built-in MCP server (
sc-machin mcp serve) โ expose all commands to AI agents - โ
skills.matchbuilt-in tool โ semantic skill discovery across all skill dirs - โ
rtkpassthrough โ token-reduced git/ls ops via MCP - โ Auto-detects OS/arch (linux-amd64, linux-arm64, darwin-arm64)
Option 3: Node.js Version (npx/npm)
# Run immediately โ no install needed
npx supercli skills list
# Install globally
npm install -g superacli
- โ Full feature parity (MCP client, HTTP adapter, plugin installs)
- โ Plugin installation from registry
Which to choose? sc-zig for daily use (fastest startup), sc-machin to expose SuperCLI to AI agents via MCP, sc (Node.js) for the reference implementation with full feature parity. All three share the same plugin state โ install one, two, or all three.
๐ง Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
command not found: supercli | Not installed | Run npx supercli (no install needed) or npm install -g superacli |
| Plugin not found | Not in registry | Run supercli plugins explore --name <query> to find it |
| Output is not JSON | Tool may not support JSON output | Use supercli inspect <ns> <res> <act> to check if the command supports JSON |
| MCP server not connecting | Server not running or wrong URL | See MCP diagnosis steps below |
| Zig binary not found | Wrong platform binary | Use npx supercli (Node.js) as fallback โ both share plugin state |
ask not available | LLM env vars not set | Set OPENAI_BASE_URL, OPENAI_MODEL, OPENAI_API_KEY โ see ask docs |
| Arguments rejected | Wrong arg names or types | Run supercli inspect <ns> <res> <act> to see the expected argument schema |
Quick diagnosis flowchart:
Problem?
โโ "command not found" โ Run `npx supercli` (zero-install) or `npm install -g superacli`
โโ "plugin not found" โ `supercli plugins explore --name <query>` to search registry
โโ Output not JSON โ Verify tool supports JSON; use `supercli inspect` to check adapter config
โโ MCP not connecting โ Follow MCP diagnosis steps below
โโ "ask" not available โ Set OPENAI_BASE_URL, OPENAI_MODEL, OPENAI_API_KEY env vars
โโ Zig binary missing โ Use `npx supercli` (Node.js fallback, shares plugin state)
โโ Arguments rejected โ `supercli inspect <ns> <res> <act>` to see expected schema
MCP Server Diagnosis
If an MCP adapter command fails to connect:
# 1. Check if the MCP server is registered
supercli mcp list
# 2. Verify the server URL is correct
# For HTTP/SSE: ensure the URL is reachable
curl -s <server-url> # Should return a response, not connection refused
# 3. For stdio servers, check the binary exists
which <command-from-adapterConfig>
# 4. Inspect the command to see the adapter config
supercli inspect <ns> <res> <act>
# 5. Run with verbose output for debugging
supercli <ns> <res> <act> --verbose
Common MCP issues:
- Connection refused: Server process not running. Start it first.
- Timeout: Server is slow. Increase
timeout_msinadapterConfig. - Tool not found: The
toolname inadapterConfigdoesn't match the server's tool list. Check withsupercli inspect.
For detailed debugging: supercli returns the full schema (JSON by default). Use supercli inspect <ns> <res> <act> to validate arguments before execution.
Getting Help
supercli helpโ list all commandssupercli help <namespace>โ commands in a namespacesupercliโ full capability graph schema (JSON by default)supercli plugins show <name>โ plugin details including version, source, tags- File an issue at github.com/javimosch/supercli/issues
๐งฑ Tech Stack
| Layer | Technology |
|---|---|
| Runtime | Node.js (sc), Zig (sc-zig), machin/MFL (sc-machin) โ co-exist, share plugin state |
| Router | Custom capability graph with sub-millisecond cache |
| Plugins | 10,000+ bundled โ each plugin.json + meta.json |
| MCP | Built-in MCP server adapter (supercli mcp add <name>) |
| HTTP | HTTP adapter for REST endpoints as capabilities |
| Registry | plugins/catalog.json โ checksum-verified updates |
| CLI | supercli <ns> <res> <action> [--flags] โ universal triplet |
| Output | Deterministic JSON envelopes with exit codes |
| AI | supercli ask "do X and Y" โ auto-resolves capability chains |
| Install | npx supercli (zero-install) or npm install -g superacli |
๐ Community & Social
| Channel | Link |
|---|---|
| GitHub | github.com/javimosch/supercli |
| npm | superacli on npm |
| Issues | GitHub Issues |
| Discussions | GitHub Discussions |
| Changelog | CHANGELOG |
Contributors
Contributions are welcome! See CONTRIBUTING.md for guidelines.
- Plugin authors โ Add your tool via
plugins/<name>/. - Core contributors โ Help with router, Zig binary, MCP adapter.
- Documentation โ Improve docs, examples, quickstarts.
โญ If supercli saved you time, star the repo. Takes one click, means the world to us.
Support
If supercli saved you time, consider supporting the project:
License
MIT โ Javier Leandro Arancibia
Trustgrade A
- passBody integrity
Whether the stored document is plausibly the kind of file the artifact declares, rather than something fetched by mistake.
- passType matchnot applicable to this artifact type
Whether the artifact is really the kind of thing its metadata claims it is.
- passFreshness
How long since the source repository was last pushed to.
- passPrompt injection
Scans the artifact's own text for instructions aimed at your agent rather than at you.
- passLicense
Whether the source repository declares an SPDX license permissive enough to redistribute.
How the grade is calculated
Each check contributes 0 points when it passes, 1 when it warns, and 2 when it fails. The total maps to a letter:
- Aevery check passed
- Bone warning
- Ctwo warnings
- Dprompt injection or body integrity failed, or three warnings
- Fone of those failed, and something else is wrong
These are automated hygiene checks, not a security audit, and not a dependency or vulnerability scan. A grade of A means nothing was flagged โ not that the artifact is safe.
Versions
git-a927669007f82026-07-31