Make agent handoffs useful with Rimewire.

Install in the harness you use.

Rimewire runs a local MCP server and a browser board. It needs Node.js 24 or newer and npm; no model API or cloud account is required. Install from its public source repository:

git clone https://github.com/frostdev-ops/rimewire.git
cd rimewire
npm ci
npm run build
npm install --global .

Register the installed runtime with your harness. Run the matching command below; you only need the harness you actually use.

rimewire install codex --user
rimewire install opencode --user
rimewire install pi --user

User scope is the default. For checkout-specific registration, run the command inside that project with --project. Codex uses ~/.codex/config.toml or .codex/config.toml; OpenCode uses its user or project JSON/JSONC configuration; Pi uses its user settings or .pi/settings.json. Environment overrides are documented in the installation reference.

Claude Code uses the bundled plugin. From the built Rimewire checkout, run:

claude plugin marketplace add "$PWD/plugins"
claude plugin install rimewire@rimewire-local

Restart your harness in the project. Ask it to run rimewire-setup, or /rimewire:rimewire-setup in Claude Code. The skill surveys your plans and conventions, adapts the tracker and config, and adds managed agent instructions. Accept the harness's project trust requirements where needed.

Define work someone can review.

Start with one independently reviewable deliverable. Give it a stable ID, a concrete title, a status, dependencies and an acceptance condition. “Improve parsing” is vague; “Reject malformed input without changing valid callers” tells a reviewer what to check.

The default tracker is docs/board/README.md. Second-level Markdown headings become lanes. Tables beneath a lane with a Status column become packages; ordinary scheduling tables can stay in the same document.

# Project tracker

## Foundation

| ID | Title | OS | Depends on | Status | Branch |
|---|---|---|---|---|---|
| [TASK-1](TASK-1.md) | Reject malformed input | any | — | planned | — |

## Delivery

| ID | Title | OS | Depends on | Status | Branch |
|---|---|---|---|---|---|
| TASK-2 | Verify the release | any | TASK-1 | planned | — |

TASK-1 and TASK-2 are demonstration IDs throughout this guide. Use existing IDs from your tracker when posting real updates. The linked TASK-1.md is a sibling spec: put the problem, scope, constraints and acceptance checks there. The tracker path determines the spec directory.

Keep implementation and delivery separate when they need different evidence. A parser change may pass local checks while an installed release still needs verification. Record that dependency instead of folding both into an ambiguous “done.”

Keep the project and its history local.

Setup writes .rimewire/config.toml. A small project configuration can preserve your existing tracker and branch convention:

name = "Example project"
tracker = "docs/board/README.md"
idPattern = 'TASK-[0-9]+'
branchPrefix = "task"
journalDir = ".rimewire/journal"

[statuses]
done = ["shipped"]
active = ["building"]
blocked = ["waiting"]

Custom status prefixes extend the built-in categories. Paths must be relative and remain inside the project. IDs must match your pattern and be safe filenames of at most 48 characters. Invalid expressions and unknown configuration keys produce errors.

Version the configuration, tracker and specs. Add .rimewire/journal/ to .gitignore. Each checkout appends its own notes.jsonl; the board combines journals across linked Git worktrees. Updates retain checkout identity, so parallel work stays attributable.

Ask for board_url to get the actual address. MCP sessions share a daemon bound to 127.0.0.1, with a project URL based on the canonical main repository path. Linked worktrees register the same project. Closing the last MCP session eventually stops the daemon; an open browser does not keep it running.

Read the shared picture before starting.

1. Read the board.

   Use board_overview to see phases, active packages and blockers. Check what depends on the package you intend to change.

2. Read the package.

   Call get_package with its wp ID. Review the spec, branch, worktree and acceptance condition.

3. Read recent updates.

   Use list_updates, optionally filtered by wp. On resuming work, check for decisions or newer evidence before repeating an old approach.

Keep the tracker synchronized when scope, dependencies or branch ownership change. Managed agent instructions should tell future workers to read and update the board, use real package IDs and keep checkout journals ignored. Pass those instructions to delegated workers too.

Choose a package small enough to describe its result clearly. Dependencies express the order of work; acceptance criteria express the proof required. Neither should need the reader to reconstruct a conversation.

Post an update that earns its place.

A useful update says what changed, what was checked and what remains. A percentage can help you scan a board, but “Parser implemented; caller checks remain” gives the next worker an action.

rimewire list TASK-1 --limit 10
rimewire progress TASK-1 --percent 50 \
  --text "Parser implemented; existing caller checks remain"
rimewire note TASK-1 \
  --text "Decision: retain the current valid-input format"

Run these from the checkout that owns the work. From elsewhere, add --checkout /absolute/path/project. If rimewire is unavailable on PATH, substitute node /absolute/path/rimewire/dist/cli.js. This fallback lets sandboxed workers append updates without a network connection.

MCP exposes the same reporting through post_update. For example, ask the agent to submit wp: "TASK-1", kind: "progress", percent: 50 and the text above. Supported kinds are note, progress, blocker, unblock and ready. Notes preserve context without changing completion.

Post at meaningful changes: a decision, a completed check, a blocker or a review handoff. Keep credentials, private prompts, transcripts and application data out of updates. Link to approved source and evidence instead.

Name the blocker. Make the handoff concrete.

Describe a blocker in terms someone can resolve: the missing decision, input or evidence, and how it affects acceptance. Once resolved, record what changed.

rimewire blocker TASK-1 \
  --text "Need a decision: reject or ignore incomplete records"
rimewire unblock TASK-1 \
  --text "Decision recorded: reject incomplete records"
rimewire note TASK-1 \
  --text "Review handoff: task/TASK-1, commit abc1234; parser and callers checked. Release verification remains TASK-2."

The revision above is a placeholder. A real handoff should identify the actual branch or revision, affected files, resulting behavior, checks run and unresolved questions. Include a failing check's relevant error and its effect on acceptance. The reviewer should be able to start without your chat history.

Record the result of a dependency decision in the tracker or spec as well as the update. That keeps the durable plan understandable after the original worker leaves.

Complete the package with evidence.

Use ready only after the work and the package's required checks pass. Say which behavior was verified and against which revision.

rimewire ready TASK-1 \
  --text "At the reviewed revision: malformed records rejected; valid callers preserved; required parser checks passed. Release acceptance tracked in TASK-2."

A passing build proves the build. It does not prove deployment, an installed app's behavior or an external provider's response. If those are required, keep the package open or track them in a clearly named dependent package. When new evidence invalidates readiness, post the remaining work and let the board reflect it.

Keep the board useful over time.

If startup fails after an update or move, check Node's version and the registered runtime path, then rebuild and rerun installation. Restart the harness so it loads the current registration and skill. Repeated installation preserves unrelated settings; an unowned conflicting registration requires review.

If the board URL stops responding, reopen an MCP session and ask for board_url again. The daemon prefers port 8737 and tries alternatives when occupied. For a standalone board, run rimewire serve --repo . --port 0 in the project and use the address it prints. Avoid assuming a fixed port.

If packages are missing, check the configured tracker path, second-level lane headings, Status column and ID pattern. If updates appear on the wrong branch, verify the checkout used for the write. Keep journals local and ignored; use a supported local filesystem for concurrent journal appends.

Optional activity hooks start disabled. Enable them only when useful, with the harness's required trust and [hooks] enabled = true in project configuration. They route to a uniquely matched branch package or an explicit package override. Activity and Git snapshots help explain work; they never replace acceptance.