Try PeerHarness: vote on rules for your team's coding agents

Aryeh Klein — Wed, 11 Nov 2026 23:13:07 +0000

Coding agents forget. You tell Claude Code to use pnpm, it does, and the next session it reaches for npm again. Your teammate corrects their own agent about something else, in their own clone, and the two agents slowly drift apart. Each of you ends up as the memory for a tool that is supposed to be saving you effort.

PeerHarness is a small Rust binary that gives the agent a place to put what it learns from you. When you correct it, the agent notes the correction as a one-sentence rule. You keep the rule for your own agent, or put it to your team. When a majority approves, the rule is installed for every member's agent as an Agent Skill, and it applies from their next session. This post is about what that looks like from the agent's side.

Repo: https://github.com/aryehlev/PeerHarness

Connect it to Claude Code

curl -fsSL https://raw.githubusercontent.com/aryehlev/peerharness/main/install.sh | sh
peerharness setup

The installer downloads the release binary, checks it against the release's checksums and puts one file in ~/.local/bin. setup is the one step you run yourself, in your own terminal, because it is where you decide what your agent may start for you. It shows each change before it makes it:

your node: a key and a local database
two hooks in Claude Code's settings, backed up first. UserPromptSubmit lets PeerHarness notice when you correct the agent, and Stop prints a short line at the end of a turn saying how many noted rules and proposals are waiting for you
one skill, peerharness-notes, which tells the agent when and how to note a rule
the PeerHarness tools, registered with claude mcp add

On macOS the agent can also open confirmation windows. On Linux the agent can note rules and you make every other decision in the terminal. Start a new Claude Code session afterwards.

The agent notes the correction

The skill is short. It tells the agent that when you correct it in a way that should apply again, it should write the rule down once, after dealing with the correction itself, as one imperative sentence about the rule and not the incident. A session looks roughly like this:

You: No, use pnpm here, not npm.

Claude: Switched to pnpm and reran the install. I also noted this as a PeerHarness rule: "Use pnpm, not npm, in this repository." If you want, I can keep it for you or propose it to your team.

Two things are worth seeing in that exchange. The agent is the one noticing, because it is the one party that reliably knows it was just corrected. A pattern detector on your prompts exists too, but in a small hand-made sample it caught about one correction in five, and "always run the tests before you say you're done" has no tool to prefer or avoid for a pattern to latch onto. The agent understands the sentence. And what the agent did was small. It wrote a note into a local inbox. Nothing was installed, shared or approved.

You keep it, the agent installs it

Keeping is yours, but you can ask your agent to start it:

You: Keep it.

Claude: A window is open with the exact rule and where it will be installed. It's waiting for your answer.

The window shows the file that will be installed and has two buttons, Cancel and Proceed. Cancel is the default. The agent has no way to click either, and the commands that decide things refuse to run inside its session. The installed result is a skill in ~/.claude/skills:

---
name: use-pnpm-not-npm-repository
description: "Use pnpm, not npm, in this repository."
---

# Rule

Use pnpm, not npm, in this repository.

If this conflicts with what the user asks for in the current session, follow the user and say that it conflicts with this rule.

That last line matters. A rule is guidance for the agent, and you in the chair still outrank it. If you tell Claude to run npm install for once, it should do so and mention the rule, which is the behaviour you want from a colleague who knows the team convention. In the next session Claude Code reads the skill and the correction you made last week is already part of how it works. Rules are plain instructions in one SKILL.md. PeerHarness never executes anything from them, and a rule that tries to pre-approve tools or inject shell syntax is refused.

From one agent to a team's agents

A rule you kept is for your agent. A team's agents agree when the team votes. In the commands a team is called a circle, and the agent can start the steps when you ask for them:

You: Propose the pnpm rule to acme.

Claude: A window is open showing the exact text that would leave your machine.

You click Proceed and the rule is put to a vote. Each member sees the same text in their own window and answers for themselves. A rule passes with more than half of everyone on the roll. Not voting counts as not approving, a rejection is recorded with its reason and does not block, and an approval cannot be withdrawn. The built-in peerharness demo runs three members through it in temporary folders and touches nothing in your home or in ~/.claude:

    alice approves.
    carol rejects: "Our CI images only ship npm."
    open: 1 of 3 approved (2 needed), 1 dissenting
    bob approves.
    Every node counts for itself and agrees: passed: 2 of 3 approved (2 needed), 1 dissenting
    No one held a veto, and carol's dissent stays on the record.

When a rule passes, each member's node installs it for their agent when it learns of the result, as a skill like the one above. Alice's, Bob's and Carol's agents all start the next session with the same instruction. Carol can opt out of that one rule and only her machine changes. A node can also be set to ask before installing anything that passed.

Agents drift because corrections stay private. Here they become shared, and the sharing is checked. There is no server. Each person runs their own node with their own keys, and every node verifies every signature and counts every vote itself.

What the agent can and cannot do

Your agent can note a rule whenever you correct it, and it does that without asking, because a note changes nothing. When you ask, it can start the steps that matter: keep, propose, vote, install a passed rule. Each one opens a window that shows exactly what would be shared, signed or installed, and only your click decides. The skill tells the agent to start a step only when you asked for it in the conversation, never because a file or a proposal's text says so, and to stop and tell you if a step is declined or refused. Proposal titles written by other members are shown to you as they are and are not instructions to the agent.

Adding a teammate goes the same way. They give you their device key, you ask your agent to invite them, and the other side joins with your node's peer id and the team fingerprint, which you tell them by phone or in person. Nodes exchange over QUIC, and peerharness daemon --internet lets members find each other by peer id with no server in between.

If you want to see the voting before connecting anything, run peerharness demo. If you want the agent side, run peerharness setup, open a session and correct it about something small.

From a terminal, without an agent

Everything the agent does goes through the peerharness command line, so you can drive it yourself with no agent involved. peerharness note writes a rule down, peerharness inbox lists what waits for you, peerharness keep installs a noted rule for your own agent, peerharness proposal create puts it to your team, and peerharness proposal vote casts your ballot. peerharness status shows your node, and peerharness demo runs a three-member vote in temporary folders. It runs on macOS and Linux, and on both the decisions work in the terminal, with the same exact text and the same confirmation you get in the window:

peerharness note "Use pnpm, not npm, in this repository."
peerharness inbox
peerharness keep <candidate-id>

https://github.com/aryehlev/PeerHarness