The `/yarnt` agent skill

The loop the tools are meant to drive.

The MCP server gives an agent the tools to work your board. It does not tell the agent what to do with them. An agent handed seventeen tools and no shape will cherry-pick, re-litigate, and stop early. /yarnt is a skill for Claude Code that supplies the shape: work your queue until it is empty, then halt.

What it does, once you invoke it:

Reads the repo's .yarnt file to learn which Yarnt project this checkout is.
Pulls every ticket in that project assigned to its own robot, never yours and never unassigned ones.
Reads each description and its comments as the spec, then does the work or dispatches it to subagents.
Tests, commits, merges, and finishes the ticket. Publishing (pushing, releasing, deploying) is left to whatever runs the skill.
Hands back anything it is genuinely blocked on: a comment saying why, unstart_ticket, reassigned to you.
Re-checks for work assigned while it was busy, then halts. No polling, no timers.

Setup

1. Connect the MCP server

In Claude Code, add the server and authorize it. Full details on the MCP page.

claude mcp add --transport http yarnt https://mcp.getyarnt.com

The consent screen asks you to pick or create a robot: a least-privilege workspace member the agent acts as. Name it for the agent. Robots are exempt from the in-flight cap and are not paid seats.

2. Install the skill

mkdir -p ~/.claude/skills/yarnt
curl -o ~/.claude/skills/yarnt/SKILL.md https://getyarnt.com/docs/yarnt-skill.md

Or read it first: yarnt-skill.md. It is a plain Markdown file. Edit it to match how your team works. It stops at a committed, merged ticket, so if you want the agent to push or deploy, add that step yourself.

3. Tell the repo which project it is

Commit a .yarnt file at the repo root naming its Yarnt project:

project: Yarnt

Which project a repo belongs to is a fact about the repo, like its remote, so it belongs in the repo. Without the file the agent guesses from the directory name and asks you when the guess is ambiguous, then writes the file itself. Committing it also gives a human somewhere to override a bad guess, and lets a coordinator map projects to checkouts by globbing */.yarnt.

4. Assign it work

The agent only ever picks up tickets assigned to its robot. Assign them in the app, or over the tools:

whoami                     -> abcd1234-...  Claude (integration)
update_ticket id=<ticket> assignee=abcd1234-...

5. Run it

/yarnt

With an empty queue it says so and stops. It ends because there is no work left, not on a timer.

The robot works only its own queue. Tickets on your plate, or on nobody's, are never picked up, no matter how relevant they look. Assigning is the handoff.

Why it is shaped this way

Rule	Why
Work the whole batch before re-checking	Left free to choose, an agent takes the easy tickets and leaves the queue's real work untouched.
Read the body, not the title	`list_tickets` shows one line. The spec is in the description and comments; designing from a title invents a different feature.
Blocked work escalates, never lingers	A ticket left in `doing` burns a WIP slot and makes every later run re-dispatch an agent onto the same dead ticket. Comment, `unstart_ticket`, reassign, and it is off the robot's queue by construction.
Comment before unstarting	`unstart_ticket` clears the `blocked` flag and its reason, so the comment is the only durable record of why the agent gave up.
Halt, don't poll	An agent that waits for work burns tokens watching an empty queue. Re-invoke it when you have assigned something.

Other agents

The skill is written for Claude Code, whose skills are Markdown files with a name and a description. Nothing in the loop is Claude-specific. Any agent that can call the MCP tools can follow the same instructions as a system prompt.

Questions about agents on Yarnt: [email protected].

The /yarnt agent skill