---
title: 'AI Agents & Coding Assistants'
description: '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.'
section: 'AI & Agents'
canonical_url: 'https://yorkermonitoring.com/docs/ai/overview'
---

# AI Agents & Coding Assistants

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

```bash
npm install -g @yorker/cli && yorker login
yorker skills install
```

The first command installs the CLI and signs you in through your browser. The second adds the [Yorker agent skill](/docs/ai/skills) 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/health` endpoint. 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](/docs/ai/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](/docs/ai/skills) + [CLI](/docs/reference/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](/docs/reference/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`](/docs/guides/ci-cd) | `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](/docs/reference/api) | Everything the CLI does goes through the same API, authenticated with a Bearer key. |
| A chat assistant you paste context into | [Markdown docs](/docs/ai/markdown-access) | Copy any page as Markdown, or hand it `llms.txt`. |
| No agent, just a sentence | [Natural language creation](/docs/guides/create-monitor#natural-language) | 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 diff` before 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](/docs/guides/ci-cd) run `yorker deploy` on merge. The agent's job then ends at the pull request, and it never needs to run a deploy itself.
- **Be deliberate with `--prune` and `--force`.** `--prune` deletes remote resources missing from the file, and `--force` overwrites 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](/docs/ai/agentic-workflows): a worked example from empty repo to monitored service.
- [Agent Skill](/docs/ai/skills): what the skill contains and how to install it for your agent.
- [Markdown & llms.txt](/docs/ai/markdown-access): every way to get these docs into a context window.