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 rd create --title "Auth returns 403 on valid tokens" --type task --priority p0 created myproject-a1b # What needs attention right now? rd ready myproject-a1b p0 inbox 2m Auth returns 403 on valid tokens # Claim it — you're now the performer rd claim myproject-a1b claimed myproject-a1b # Close with a reason — the audit trail records why rd close myproject-a1b --reason "Was checking issuer, not audience" closed myproject-a1b

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 --title "..." --type task --priority p1`	Create a work item
`rd ready`	What needs attention now
`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 close <id> --reason "..."`	Close with reason (done, cancelled, or failed)
`rd update <id> --status <status>`	Change status, priority, ETA, or context

Agent integration

Tell Claude to use it

Add rd to your project's CLAUDE.md and Claude Code will use it to track work, check what's ready, and close items when done.

# In your project's CLAUDE.md: ## Work tracking This project uses `rd` for work management. - Check what needs attention: `rd ready` - When starting work: `rd claim <id>` - When done: `rd close <id> --reason "..."` - To create new items: `rd create --title "..." --type task --priority p1` - All commands support `--json` for structured output

That's it. Claude Code reads CLAUDE.md at session start, discovers rd on PATH, and uses it like any other CLI tool. No MCP server configuration, no special integration.

Or drop in the skill file

Download SKILL.md into your project's .claude/skills/rd/ directory. Claude Code will discover it automatically and gain full rd command knowledge — creating items, claiming work, closing with reasons, querying views.

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

Agents use the same commands

There's no separate agent API. rd create, rd claim, rd close work the same for a human at a terminal and a Claude session reading CLAUDE.md.

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

From solo to portfolio

Single project, multi-project, or org-wide

Start with one project. Add more when you need them. Registration is optional — every project works standalone.

Single project

One command. Your project gets a campfire that stores all work items locally.

cd ~/projects/myapp rd init --name myapp initialized myapp campfire: a7f3e2... declarations: 12 operations published # Start working rd create --title "Set up CI pipeline" --type task --priority p1 rd ready

What happens rd init creates a campfire at .campfire/root and publishes 12 convention operation declarations. These declarations make the campfire self-describing — any agent can discover what operations are available by reading the campfire.

Multi-project

# First project — creates the org home cd ~/projects/api rd init --name api rd register --org acme created home campfire: b8c4d1... registered cf://acme.ready/api # Second project — joins the existing org home cd ~/projects/frontend rd init --name frontend rd register found home campfire: b8c4d1... (acme) registered cf://acme.ready/frontend # See work across projects rd ready api-3f2 p0 inbox 5m Rate limiter dropping valid requests frontend-a1b p1 active 2h Dashboard loading state missing

What happens rd register --org acme creates a home campfire and a ready namespace under it. Subsequent projects in the same org auto-discover the home via your ~/.campfire/config.json. Each project keeps its own campfire — the home just links them for discovery.

Org-wide with delegation

Operators delegate to agents and humans. The attention engine routes work to whoever's doing it.

# Operator creates and delegates rd create --title "Implement OAuth PKCE flow" --type task --priority p0 \ --for baron@acme.dev --by claude-session-xyz created api-d4e # Agent's view — only sees work assigned to it rd ready --view my-work api-d4e p0 inbox now Implement OAuth PKCE flow # Agent claims, works, hits a decision point rd claim api-d4e rd gate api-d4e --type design --reason "PKCE vs device flow — need operator decision" # Operator sees the gate, resolves it rd ready --view delegated api-d4e p0 active GATE:design Implement OAuth PKCE flow rd approve api-d4e --reason "PKCE, we need browser redirect"

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.