The lifecycle

Create → Claim → Close

Every work item follows the same three-step lifecycle. Humans and agents use the same commands.

# Create a work item — returns the item ID directly rd create "Ship login page" --priority p1 --type task myproject-45e # What needs attention right now? rd ready myproject-45e p1 inbox 3h Ship login page # Claim it — you're now the performer rd claim myproject-45e claimed myproject-45e # Close with a reason — the audit trail records why rd done myproject-45e --reason "Login page ships with JWT auth" closed myproject-45e (done)

Delegation is explicit

Every item has for (who needs the outcome) and by (who's doing it). Delegation is an act, not an assumption.

rd delegate myproject-a1b --to atlas/worker-3 delegated myproject-a1b to atlas/worker-3 # See what you've delegated rd ready --view delegated

The attention engine

Named views filter by who you are. rd ready shows what's actionable. Priority drives ETA — P0 is now, P3 is 72 hours.

# Views: ready, work, pending, overdue, delegated, my-work rd ready --view overdue rd list --status active --priority p0,p1 rd list --by atlas/worker-3 --all --json

Full command reference

`rd init --name <project>`	Create a work campfire with convention declarations
`rd create "..." --type task --priority p1`	Create a work item (returns item ID when piped)
`rd ready`	What needs attention now (bare IDs when piped)
`rd list [--status ...] [--by ...] [--all]`	List items with filters
`rd show <id>`	Item details + audit trail
`rd claim <id>`	Accept work, become the performer
`rd delegate <id> --to <identity>`	Assign to a person, agent, or automaton
`rd done <id> --reason "..."`	Close with reason — records to the audit trail
`rd invite`	Generate a one-use invite token for this project
`rd join <token>`	Join a project via invite token (auto-syncs items)
`rd dep add <id> <blocker-id>`	Wire a dependency (works across projects you own)
`rd gate <id> --gate-type design`	Escalate to a human for a decision
`rd update <id> --status <status>`	Change status, priority, ETA, or context

Agent integration

Recipes for Claude Code

Drop one of these into your project and Claude Code starts tracking work immediately. No MCP server, no special integration — just rd on PATH.

Recipe 1: Add to CLAUDE.md

Paste this into your project's CLAUDE.md. Claude reads it at session start and uses rd like any other CLI tool.

# Add to your CLAUDE.md: ## Work tracking This project uses `rd` for work management. - Start every session: `rd ready` (what needs attention) - Resuming after context loss: `rd ready --view work` (find your in-progress item) - When starting work: `rd claim <id>` - When done: `rd done <id> --reason "..."` - To create new items: `ITEM=$(rd create "..." --type task --priority p1)` - Pipe-friendly: `for id in $(rd ready); do rd show $id; done` - All commands support `--json` for structured output

Recipe 2: Drop in the skill file

Download SKILL.md into your project's .claude/skills/rd/ directory. Claude Code discovers it automatically and gains full rd command knowledge.

mkdir -p .claude/skills/rd curl -fsSL https://ready.getcampfire.dev/SKILL.md -o .claude/skills/rd/SKILL.md

Recipe 3: Multi-agent swarm

Spawn parallel Claude Code agents that share a work queue. Each agent gets its own identity via invite token. The filesystem handles isolation — no env vars needed.

# Owner sets up the project rd init --name myproject rd create "Build auth" --priority p0 --type task rd create "Build API" --priority p1 --type task rd create "Write tests" --priority p1 --type task # Generate invite tokens for each agent TOKEN_A=$(rd invite) TOKEN_B=$(rd invite) # Each agent joins from its own worktree mkdir -p worktree-a/.cf && cd worktree-a rd join $TOKEN_A joined d8301552... via invite token (expires in 1h59m) # Agent claims from the shared queue ITEM=$(rd ready | head -1) rd claim $ITEM rd done $ITEM --reason "Auth module complete"

Recipe 4: Agent escalation to human

Agent hits a decision point it can't resolve. Posts a gate. Human approves from their terminal. No dashboard, no ticket system — just campfire messages.

# Agent: "I need a ruling on this" rd gate myapp-d4e --gate-type design \ --description "PKCE vs device flow for mobile auth" {"id":"myapp-d4e","gate_type":"design","status":"waiting"} # Human: sees it from anywhere rd gates myapp-d4e p1 design PKCE vs device flow Migrate auth rd approve myapp-d4e --reason "PKCE. Need browser redirect." # Agent: item is back to active, continues work

Recipe 5: Zero-config agent identity

rd walks up the directory tree to find identity and project config. Agents in worktrees get isolated identities automatically. No CF_HOME, no env vars, no flags.

# Project root has .campfire/root (project) and .cf/ (owner) # Each worktree has its own .cf/identity.json myproject/ .campfire/root ← project campfire (shared) .cf/identity.json ← owner identity worktree-a/.cf/identity.json ← agent A identity worktree-b/.cf/identity.json ← agent B identity # Agent A: just cd and run. Walk-up handles everything. cd myproject/worktree-a rd ready # Identity: worktree-a/.cf/ Project: myproject/.campfire/root # Agent B: same project, different identity, zero config cd myproject/worktree-b rd ready

Agents use the same commands

There's no separate agent API. rd create, rd claim, rd done work the same for a human at a terminal and a Claude session reading CLAUDE.md. Output is pipe-friendly — bare IDs when piped, tables when interactive.

MCP for deeper integration

For agents that speak MCP, campfire itself is the integration point. rd operations are campfire convention messages — any MCP-connected agent can read and write them.

npx @campfire-net/campfire-mcp

Scale as you grow

From one project to your whole org

Same tool at every level. No migration, no import/export. Each tier adds capability without changing the commands you already know.

For one project

Solo

Free · Local

One campfire per project
Filesystem transport
Works offline
Full CLI — create, claim, close
Named views & attention engine
JSONL audit trail

rd init --name myproject initialized myproject campfire: 6ef132115eed... declarations: 16 operations published ITEM=$(rd create "Ship login page" --priority p1 --type task) rd ready myproject-45e p1 inbox 3h Ship login page rd claim $ITEM && rd done $ITEM --reason "..." claimed myproject-45e closed myproject-45e (done)

No account. No server. Just rd init and go.

For an individual

Multi-Project

Free · Local

Everything in Solo
One identity, many projects
Center campfire for delegation
Cross-project queries
Context key auto-discovery
Project-scoped views

cf init # Each project gets its own campfire cd ~/api && rd init --name api cd ~/frontend && rd init --name frontend # Query across projects rd ready --project api rd list --project frontend

Your center campfire links your projects. Walk-up discovery does the wiring.

For your team

Collaboration

Free · Hosted or Git

Everything in Multi-Project
Shared campfires — real-time sync
Delegation: for / by routing
Gate escalations & approvals
Agent + human on same queue
Git-backed or hosted persistent

# Owner creates project and invites a teammate rd init --name backend TOKEN=$(rd invite) rdx1_eyJ2IjoxLCJjYW1... (one-use, expires in 2h) # Teammate joins with one command rd join $TOKEN joined d8301552... via invite token (expires in 1h59m) # Items auto-sync. No rd sync pull needed. rd ready backend-a1b p1 inbox 3h Build auth API

Owner runs rd invite. Teammate runs rd join <token>. Items auto-sync. No key exchange, no manual pull.

Enterprise

Org-Wide

Hosted · Contact us

Everything in Collaboration
Org home — cross-project discovery
Operator provenance levels
Convention gate enforcement
Compaction-safe audit trail
Bridge integration (Teams, Slack)

# Org-wide registration rd register --org acme # Agent hits a decision point — escalates rd gate myapp-d4e --gate-type design \ --description "PKCE vs device flow" {"id":"myapp-d4e","gate_type":"design","status":"waiting"} # Human sees it, approves from anywhere rd gates myapp-d4e p1 PKCE vs device flow Migrate auth layer rd approve myapp-d4e --reason "PKCE, need browser redirect" # Full audit trail survives compaction rd show myapp-d4e

Provenance-gated operations. Cryptographic audit trail. Bridge to existing tools.

Built on campfire

Convention, not application

Ready isn't a project management app. It's a convention — a structured vocabulary of operations that any campfire can speak.

How it works underneath

When you run rd create, Ready posts a work:create message to your project's campfire with a structured payload. rd claim posts work:claim with a causal link to the create message. State is derived from the message log — there's no separate database.

Convention operations are declared in the campfire itself. When rd init runs, it publishes 12 convention:operation declarations that describe every operation, its arguments, and its constraints. Any agent reading the campfire knows what's possible.

10 operations, complete vocabulary

work:create — new item with full payload work:claim — accept work, become performer work:status — transition status work:delegate — assign/reassign performer work:block — wire a dependency work:unblock — remove a dependency work:gate — request human escalation work:gate-resolve — resolve a gate work:update — modify fields work:close — terminal close with reason

Federation topology

Projects are independent campfires. An org home links them for discovery. Names make them addressable. Work stays local — the home is just a registry, not a database.

Home Campfire (org root) ├ beacon:registration for each project ├ └ Project: api (work:* messages) └ Project: frontend (work:* messages) └ Project: infra (work:* messages)

Compaction-safe history

Campfires compact old messages to stay readable, but Ready marks structural events as non-compactable. Creates, closes, blocks, and gates survive forever. Status changes and claims compact after the item closes.

The audit trail survives Every state change is a campfire message. The message log IS the audit trail. Compaction archives operational noise, not structural decisions.

Part of the campfire ecosystem

Ready is one convention on a protocol designed for many. Campfire handles identity, encryption, transport, and federation. Ready adds work management semantics on top.

Create, claim, close. That's the whole tool.

Real demos, real output