Solo automate
Portable AI-agent skills for Claude Code, Codex, OpenCode, and Grok: Fan Solo — multi-agent orchestration, processes, and durable state for Solo (SoloTerm) — plus WebAuthn/passkey browser testing for Stellar smart accounts
npx -y skills add kalepail/skills --skill solo-automateAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 28 days oldThe repository was created 28 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Automate and integrate Solo through MCP, CLI, local HTTP API, hosted API v1, documentation resources, prompts, and solo:// deep links. Use when scripting Solo, discovering live schemas, configuring MCP clients, consuming Solo docs programmatically, or choosing an integration surface. Do not use for normal interactive Solo work already owned by a focused skill.
SKILL.md
4.2 KB, as published. Nobody here has run it
Automate Solo
Choose supported Solo surface, discover current contract, then perform smallest authorized action.
Route Request
- Use local Solo MCP for local projects, processes, output, services, agents, coordination, todos, scratchpads, prompts, and timers.
- Use
soloCLI for shell scripts and CI-like local automation. Require--json; branch on documented exit codes. - Use local HTTP API for editors, plugins, and programs needing REST. Read current discovery file; never hard-code port, token, capabilities, or schemas.
- Use hosted
https://soloterm.com/api/v1/docsfor machine-readable product documentation and hosted/api/v1only for documented web services. - Use
solo://links for human navigation and scratchpad/todo MCP resource addressing.
Do not treat local /api and hosted /api/v1 as same API.
Discover Before Acting
- Call
whoamito inspect identity and effective project. - Call
list_projectsandselect_projectonly when scope remains missing or user names another project. - Call
help()for capability overview, then relevant topic. - Call
mcp_tools_summary()or use client tool discovery before relying on any remembered tool name, schema, feature toggle, or documented category. - Inspect target state before mutation. Use IDs returned by Solo, never OS PIDs or another orchestrator's IDs.
Read MCP discovery and protocol before using MCP tools, prompts, resources, session identity, project scope, timers, or feature catalogs.
Execute Conservatively
- Prefer read-only discovery and inspection when intent is ambiguous.
- Request explicit authority before deletion, output clearing, self-close, process-wide/bulk control, cross-project mutation, agent spawning, terminal input, feedback submission, or hosted admin action.
- Preserve command trust, optimistic revisions, lock ownership, and project boundaries.
- Verify mutations through fresh state, not request acceptance alone.
- Report surface used, target scope, observed result, and unresolved manual step.
Read safety and authority before any mutation or side effect.
Use Scriptable Interfaces
For CLI or local REST work:
- Confirm Solo app runs and HTTP API is enabled.
- Prefer CLI unless caller needs direct REST schemas or endpoint control.
- Parse JSON envelopes and stable error codes; keep stderr separate.
- Page until
hasMoreis false. - Re-read discovery after authentication, connection, or version failure.
Read CLI and local HTTP API before writing commands, scripts, HTTP requests, retries, pagination, or error handling.
Use Hosted Surfaces and Links
Read hosted API, docs, and deep links before fetching docs, calling hosted /api/v1, handling admin abilities, generating installer/update requests, or constructing solo:// URIs.
Hand Off Focused Work
- Use
solo-run-processesfor straightforward start, stop, restart, spawn, input, or restart policy. - Use
solo-observe-servicesfor read-only status, output, resources, ports, URLs, and readiness. - Use
solo-set-up-projectsfor import,solo.yml, execution profiles, and trust setup. - Use
solo-troubleshootfor unexplained failures or diagnosis. - Use
solo-work-with-agentsfor one agent lifecycle andsolo-orchestrate-agentsfor multi-agent coordination. - Use
solo-track-todos,solo-keep-scratchpads, orsolo-save-promptsfor feature-focused work. - Use coding, browser, GitHub, or deployment skills when Solo only hosts process context; do not turn general work into Solo orchestration.
Stop Conditions
Stop before acting when target scope is unresolved, live tools contradict assumed contract, user has not authorized side effect, command is untrusted, revision is stale, lock belongs to another actor, or requested operation belongs to another skill.