Nine quiet minutes and a screenshot

Watch a non-technical person work with a coding agent for an hour and you'll see the same small failure over and over. They ask for something ordinary — make the cards bigger, send the follow-up email, fix the thing that looks broken on my phone — and what comes back is a wall: a branch name, four file paths, a note about a lint rule, a cheerful report that 47 tests pass, and, somewhere near the bottom, the answer to the question they actually asked.

The output isn't wrong. It's just addressed to the wrong person. It's written for whoever would have done the work by hand — a shoulder-surf, a narration of the route. If you're the one who asked, you wanted two things: did you make the thing, and can I see it?

So we wrote a skill that answers those two questions and nothing else. It's called everybody-vibes, it's open source, and it installs in one line.

Five rules

Results only. Every message is a finished thing or a question. Not a status, not a plan about to be executed, not a list of what was tried. The route is invisible.

Auditions, not verdicts. When the question is a matter of taste — how a screen looks, how a headline reads, one page or three — the agent doesn't ship one take and defend it in a paragraph. It puts two to four labeled options side by side in a single picture, holds everything else constant, includes the current version as a control, and says which one it would pick and why in one sentence. Then it asks once. This turns out to be the whole game for non-technical authority: choosing between things you can see beats approving a description of things you can't.

Quiet work. Long silences are correct. No tool calls announced, no passing tests reported, no green checkmarks — nine quiet minutes and one screenshot beats nine updates. What's banned is unprompted narration, not process itself: the agent always tells you a result, always gives you a heads-up before it goes quiet for a while, always flags anything that changes what you should expect (what it'll cost, that it'll take two rounds, that it needs your login) — and if you ask what it's doing, you get a straight answer at whatever length you want. A quiet mode that dodges a direct question is just an evasive one.

Show a picture. Anything with a visible result ships a screenshot of the actual screen. And if a picture couldn't be taken, the agent says so plainly instead of describing what it probably looks like — a confident description standing in for a picture is the most common way this mode quietly fails.

Draft pull requests, and all the shop talk lives there. Every change ends as an open draft. Never ready-for-review, never auto-merged, never merged — a human flips it after looking. In the conversation that's one sentence and a link. Everything technical goes on the pull request itself, written out in full: what changed, the tradeoff taken, the thing that broke and how it got fixed, the part the agent is least sure about, what it couldn't verify.

That last rule is the one people underestimate. It isn't censorship — nothing gets dropped. The detail is relocated to the place where it's genuinely useful, addressed to whoever reviews the code, and it stops competing for attention with the screenshot.

Why draft-only is the load-bearing part

The rest of the rules are about legibility. Draft-only is about consent.

If you can't read the diff, "all checks passed" is not information you can act on — it's a green light from a system you have no way to audit. An agent that merges on green in that situation has quietly moved the decision from you to the test suite. Draft-only puts it back: the change exists, it's complete, it's reviewable, and someone who can read it decides when it counts. The agent will even tell you when it thinks something is ready — and then leave it in draft anyway.

It's a mode, not a task

This is the design detail that makes it work in practice. Once everybody-vibes is loaded, it governs every interaction for the rest of the session — every follow-up, every unrelated next request, every repository touched. It survives context compaction. It layers on top of whatever else the agent has loaded and wins where they conflict, including our own house style, which otherwise tells agents to open pull requests ready for review and arm auto-merge on green.

The one thing it never overrides is a real safety rule. Privacy, consent, spend, and confirmation before anything destructive all still apply — just said in plain words.

It ends when you say so.

Install it

With the agent-skills CLI — works across Claude Code, Codex, Cursor, and friends:

bashnpx skills add VibesDIY/everybody-vibes

As a Claude Code plugin:

/plugin marketplace add VibesDIY/everybody-vibes
/plugin install everybody-vibes@everybody-vibes

Or vendor it: copy skills/everybody-vibes/ into your own repo's .claude/skills/ and commit it. That's the right move for repos whose cloud or CI sessions don't load global plugins — and it's how it runs here.

Then either say "everybody vibes" (or "quiet mode", or "keep it non-technical") at the start of a session, or wire the included SessionStart hook and have it always on for everyone who opens the project.

The case we actually built it for

The interesting configuration isn't a team where everybody wants the calm mode. It's a mixed team: a couple of engineers who read diffs for a living and want the play-by-play, working in the same repository as the people who asked for the feature and just want to see it. Turning this on repo-wide would fix the second group by breaking the first — everybody-vibes deliberately overrides the conventions engineers rely on, opening every pull request as a draft and moving the technical detail out of the conversation.

So the switch belongs to the person, not the project. Commit the skill and register its SessionStart hook, then guard the hook so it only fires for people who ask for it:

json{
  "type": "command",
  "command": "{ [ -n \"${EVERYBODY_VIBES:-}\" ] || [ -f \"$CLAUDE_PROJECT_DIR/.claude/everybody-vibes.on\" ]; } && bash \"$CLAUDE_PROJECT_DIR/.claude/skills/everybody-vibes/hooks/session-start.sh\" || true"
}

Two signals rather than one, for a boring reason: an environment variable exported from your shell profile reaches sessions you start from a terminal, but an app launched from the dock doesn't necessarily source that profile, so the variable can quietly fail to arrive. A file always works. Add .claude/everybody-vibes.on to .gitignore, and opting in is one command that nobody else can see:

bashtouch .claude/everybody-vibes.on

Delete the file to opt back out. Neither signal present means the hook exits without printing anything — your teammates' sessions never learn the mode exists.

The two signals also divide up neatly by surface, which turned out to matter more than we expected. A cloud session — the same account working from the phone, or a session you kick off from the web — starts from a fresh clone, so the marker file, being gitignored, isn't there. The environment variable is the one that travels: put it in the default environment settings on that person's account — the same settings that decide which repository their cloud sessions start from — and it arrives in every session they open, phone included.

That pairing is the whole trick. One account setting supplies both halves the gate needs: the repository, which carries the skill and the hook, and the variable, which says this particular person wants the calm version. We set it on a non-technical teammate's account and it carried over on the first try, with nothing to install on the phone and nothing for them to configure twice — which is the right shape anyway, since the person who wants this mode is the least likely one to enjoy setting it up at all.

So: the marker file for a checkout on a laptop, the account's default environment for everything else.

You can read the whole thing — it's four short files. It's developed in our own monorepo, in the same reviewed daily workflow it describes, next to beast-mode — the skill we wrote for the opposite problem, where the failure mode is dropped threads rather than unreadable ones. Every merge upstream republishes the mirror, so an install always gets the latest state.

The honest caveat

A calm agent is not a correct agent. This mode makes work legible to people who can't read the diff; it does not make the diff good. That's what the draft state is for, and why every technical claim still gets written down somewhere a reviewer will find it. The goal was never to hide the engineering — it was to stop making it the price of admission.