Trigger: CLI¶
The explicit, no-webhook way. Useful for testing the config, for dev iteration, and for one-off runs.
Basic invocation¶
Reads agentsmith.yml from the current directory, looks up todolist under projects:, fetches ticket #54 from that project's tracker, runs the fix-bug pipeline. Output streams to stdout; exit code is zero on success.
Other pipelines work the same way — first arg is the pipeline shortcut, rest is the natural-language "what":
agent-smith feature "#62 in todolist — add an export-to-csv button"
agent-smith init "todolist"
agent-smith security-scan "todolist"
agent-smith api-security-scan "todolist — scan https://api.todolist.dev"
agent-smith legal-analysis "contract.pdf in legal-todolist"
Pipeline shortcuts map 1:1 to the pipeline names — fix → fix-bug, feature → add-feature, init → init-project, etc.
Pass an explicit config path¶
Or set the env var once:
Headless approval¶
The approval gate is on by default — the agent prints the plan and waits for y. To skip:
For CI / cron / scripted runs, this is what you want.
Scope to one repo in a multi-repo project¶
Only touches todolist-api. The rest of the multi-repo project is ignored. Useful when you know the ticket only needs changes in one repo, or when you're testing the config for a single repo before turning on the full multi-repo flow.
Run against a local checkout¶
Skip the clone-from-remote step and use a local working directory instead:
agent-smith fix "#54 in todolist" \
--source-type local \
--source-path ~/code/todolist-api \
--repo todolist-api
The agent does its work in the local checkout. Useful for offline iteration and when you don't want to push to a remote.
What lands on disk¶
A run directory under .agentsmith/runs/{run-id}/ with plan.md, result.md, and decisions.md. Same shape as a webhook-triggered run. See First run for the walk-through.
Skip-trigger mode¶
The CLI doesn't write the framework lifecycle labels back to the tracker by default when run interactively. To behave exactly like a webhook-triggered run (write lifecycle labels, close ticket on success):
Don't set this when iterating on the config — you'll churn the ticket history with status changes you didn't mean.
What the CLI doesn't do¶
- It doesn't listen for webhooks. The CLI is one-shot; webhooks need a long-running process. For that, go to Host it: docker-compose.
- It doesn't poll. Same reason.
- It doesn't do approval-via-comment. The interactive
y/Nprompt is on stdin only.