Navigation
Getting Started
Guides
Integrations
AI & Agents
AI Agents & Coding Assistants
How to use Yorker from Claude Code, Cursor, Codex, and other agents: the agent skill, the JSON-first CLI, Markdown docs, and the REST API.
Yorker is built to be driven by an agent. Monitors are plain YAML in your repo, the CLI covers the whole lifecycle from scaffold to incident triage, every command returns structured JSON, and every page of these docs is available as Markdown.
That means the agent that writes your endpoint can also write its monitor, prove it works, and ship both in the same pull request.
Set up in two commands
npm install -g @yorker/cli && yorker login
yorker skills installThe first command installs the CLI and signs you in through your browser. The second adds the Yorker agent skill to your project so your agent knows the config schema, the safe order of operations, and how to investigate a failure.
Then ask for what you want:
Add a Yorker monitor for our
/api/healthendpoint. Run it every five minutes and email oncall@example.com if it fails twice in a row.
For a full walkthrough with prompts and the resulting config, see Agentic Workflows.
Pick your path
| You are using | Use | Why |
|---|---|---|
| A coding agent with a shell and your repo (Claude Code, Cursor, Codex, Copilot) | Agent skill + CLI | The agent edits yorker.config.yaml, then validates, tests, diffs, and deploys. Changes land in a pull request you can review. |
| A coding agent that does not support skills | yorker skills show + CLI | Prints the same instructions for you to paste into AGENTS.md or your agent's rules file. |
| An agent in CI | CLI with --json | YORKER_API_KEY for auth, exit codes for control flow, a JSON envelope for everything else. |
| Your own agent or automation, no shell | REST API | Everything the CLI does goes through the same API, authenticated with a Bearer key. |
| A chat assistant you paste context into | Markdown docs | Copy any page as Markdown, or hand it llms.txt. |
| No agent, just a sentence | Natural language creation | Describe the monitor in the web UI and Yorker drafts it. |
What makes the CLI agent-friendly
Structured output everywhere. Add --json to any command. Success is { "ok": true, "data": ... } and failure is { "ok": false, "error": { "code", "message" } }, on stdout, with nothing else mixed in. The two streaming commands, yorker results tail and yorker incidents watch, write one JSON object per line instead.
Exit codes that mean something. An agent can branch without parsing text:
| Code | Meaning | What an agent should do |
|---|---|---|
0 | Success | Continue. |
1 | Validation or API error | Read the message, fix the config, retry. |
2 | Not authenticated | Ask you to run yorker login or set YORKER_API_KEY. |
3 | Plan or quota limit | Stop and tell you. |
4 | Partial failure, or a new monitor failed its first run | Inspect the failing result. |
5 | Drift: something was changed outside the CLI | Stop and ask you which side wins. |
10 | yorker status found an unhealthy monitor | Investigate. |
A dry run for everything that matters. yorker validate checks the config with no network call. yorker test sends each HTTP monitor's request from your machine. yorker diff shows the plan. Nothing changes remotely until yorker deploy.
No interactive dead ends. Every prompt has a flag. yorker init --url ... scaffolds without questions, and destructive commands take --yes.
Keeping an agent on a short lead
An agent with your API key can change what gets monitored and who gets paged. A few habits keep that safe:
- Review the plan, not the YAML. Ask the agent to show you
yorker diffbefore it deploys. The plan lists every create, update, and delete. - Let CI do the deploying. Have the agent open a pull request and let your pipeline run
yorker deployon merge. The agent's job then ends at the pull request, and it never needs to run a deploy itself. - Be deliberate with
--pruneand--force.--prunedeletes remote resources missing from the file, and--forceoverwrites edits made in the web UI. The skill tells agents not to use either unless you ask. - Keep secrets in the environment. Config references secrets as
{{secrets.NAME}}. The value never needs to appear in the repo or the conversation.
Next steps
- Agentic Workflows: a worked example from empty repo to monitored service.
- Agent Skill: what the skill contains and how to install it for your agent.
- Markdown & llms.txt: every way to get these docs into a context window.