Claude Code hooks for VibeFlock
By Soumen Sarkar · October 2026
Playbook. How Claude Code hooks bring team context to every session: the moments that matter, how to write safe hooks, and what Campfyrr's work hook does.
What do Claude Code hooks do for a VibeFlock team?
Hooks let a team's context reach every Claude Code session without anyone remembering to ask for it. Claude Code runs a command you configure at fixed moments in a session, such as after a tool is used, when a prompt is sent, or when the session stops, and anything the command returns as additional context goes into what the agent knows. For a team, that means the right knowledge arrives at the moment it's needed: when an agent first touches a part of the code, at every turn, at commit, and when work stops.
This playbook explains how hooks work, which moments matter for a team, how to write your own, and exactly what Campfyrr's work hook does at each one.
Who is this for?
Developers and leads running several Claude Code sessions at once in a shared codebase, who want each session to start knowing what's happening around it, and to leave its work ready for whoever comes next.
What do you get?
- Sessions that learn about a part of the code the first time they touch it, before they change anything.
- News delivered at the next turn: answers to assumptions, work that landed.
- Work that explains itself at commit and at the end of a session, without anyone writing it up.
How do hooks work in Claude Code?
Hooks are configured in a settings file: ~/.claude/settings.json for everything you run, or .claude/settings.json inside a repository for everyone who works in it. Each hook is listed under the event it runs on. A tool event can take a matcher naming the tools it applies to, and each hook is a command with a timeout in seconds:
{
"hooks": {
"PostToolUse": [
{
"matcher": "Read|Edit|Write",
"hooks": [
{ "type": "command", "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/area-summary.mjs\"", "timeout": 10 }
]
}
]
}
}When the event fires, Claude Code runs the command and sends it a JSON object on standard input. It always carries the event name, the session id, the working folder and the path to the session's transcript. Tool events add the tool's name and its input, such as the file path or the shell command. Prompt events add the prompt.
If the command prints a JSON object with hookSpecificOutput.additionalContext, that text is added to the agent's context. If it prints nothing, nothing changes.
Which moments matter for a team?
Four moments carry most of the value. Each maps to a VibeFlock habit:
- The first time a session touches a part of the code. This is when an agent should learn what's being changed there now, what was decided, and what was tried. It's the area brief, and it belongs after a file is read or edited.
- Every new prompt. Between turns is when news should arrive: an assumption was corrected, work this session built on has landed.
- A commit or pull request. This is when the change's reasons should be written for whoever reviews it.
- When work stops. The session ends, is compacted, or stops responding. This is when a handoff should be left for whoever continues.
How do you write team hooks that never get in the way?
Hooks run inside every session, so a bad one is felt everywhere. These rules keep them safe:
- Never block. Exit successfully on every path. A hook that fails or hangs should leave the session exactly as it was.
- Keep it fast. Set a short timeout and give any network call its own shorter one. If the service can't be reached, print nothing.
- Add context once. Remember per session what you've already told it, in a small file named after the session id in the temp folder, and stay quiet the second time.
- Throttle the stop event. Stop runs at the end of every response, not only at the end of a session. Do expensive work at most every so often, and skip it when the input says a stop hook is already active, so hooks don't loop.
- Keep secrets out of committed files. A repository's
.claude/settings.json can be committed; a token can't. Read it from an environment variable. - Send only what's needed. If a hook reads the transcript, take the end of it and only the parts you need.
What's a hook you can write today?
Here's a small hook that needs no service. If each folder keeps an area summary in an AREA.md file, this adds it to the session's context the first time the session reads or edits a file in that folder:
#!/usr/bin/env node
// PostToolUse: the first time this session touches a folder, add its AREA.md.
import { existsSync, readFileSync, writeFileSync } from "node:fs";
import { tmpdir } from "node:os";
import path from "node:path";
try {
const input = JSON.parse(readFileSync(0, "utf8") || "{}");
const file = input.tool_input?.file_path;
if (file && input.session_id) {
const dir = path.dirname(path.resolve(input.cwd ?? ".", file));
const seenFile = path.join(tmpdir(), `areas-${String(input.session_id).replace(/[^\w-]/g, "_")}.json`);
let seen = [];
try { seen = JSON.parse(readFileSync(seenFile, "utf8")); } catch {}
const summary = path.join(dir, "AREA.md");
if (!seen.includes(dir) && existsSync(summary)) {
writeFileSync(seenFile, JSON.stringify([...seen, dir]));
process.stdout.write(JSON.stringify({
hookSpecificOutput: { hookEventName: "PostToolUse", additionalContext: readFileSync(summary, "utf8") },
}));
}
}
} catch {}
process.exit(0);Save it as .claude/hooks/area-summary.mjs and register it with the settings above. Now a session that opens lib/billing/refunds.ts reads the Billing area's summary, "money is stored as integer cents", before it writes a line.
What does Campfyrr's work hook do, event by event?
Campfyrr ships one work hook script for Claude Code. It runs on these events, and only these:
After a file is read or changed (PostToolUse on Read, Edit, Write, MultiEdit and NotebookEdit). The first time the session reads or edits a file in an area of the code, the hook adds that area's brief to the session's context: work in progress there, the decisions that apply, recent changes, approaches tried and dropped, and open assumptions. An area is named from its folder, such as "Billing · lib/billing", and can be renamed. An edit also tells teammates the area is being changed. After that, more reads in the same area make no call at all.
After a shell command (PostToolUse on Bash). When the command is a git commit or gh pr create, the hook asks Campfyrr to write the change's reasons for its reviewer and adds the link to the context. On a pull request, the agent is told to add the link to the description now; on a commit, to add it when it opens one. For commits, this happens at most every ten minutes.
When a prompt is sent (UserPromptSubmit). The session's first request becomes the one-line goal of its work in progress, visible to the team. Every turn, the hook adds anything new for this work: answers and corrections to its assumptions, work it was waiting on that landed and how it differs from the plan, and decisions that clash or were settled. Each item arrives once.
When work stops (PreCompact, Stop at most every 30 minutes, and SessionEnd). If the session changed files, the hook sends the end of the session as plain text (requests, replies, and which files were touched) and Campfyrr writes a handoff from it: what's done, what's unfinished, the next step, open questions and traps. If the work was finished, it's marked finished instead. A session that only read files leaves nothing. The transcript itself isn't kept.
The hook only ever adds context. It never blocks the session, stays quiet when Campfyrr can't be reached, and exits successfully on every path. It reads the token from ~/.claude/campfyrr/config.json, or from the CAMPFYRR_TOKEN and CAMPFYRR_URL environment variables, which win.
The same setup adds two separate hooks: a SessionStart hook that puts the team's brief into context before the first message, and an optional work log at Stop and SessionEnd.
How do you install it?
The one-line paste on /connect checks your token first, saves it where only you can read it, adds the hooks to ~/.claude/settings.json while keeping everything else there (and a backup of the old file), registers the tools for all your projects, and prints the brief your next session will see. Running it twice still leaves one of each hook.
For sessions that start from a fresh checkout, such as Claude Code on the web, the same paste with --repo writes the hooks into the repository's .claude/ folder, the connection into .mcp.json, and a short note into CLAUDE.md. None of those files holds the token, so they can be committed; set CAMPFYRR_TOKEN where the sessions run.
What instructions should agents still get?
Hooks bring context in; agents still act on it. Keep these lines in CLAUDE.md:
- Read the brief at the start of the session before starting.
- Follow the decisions the area brief lists, and build on work in progress there
rather than around it.
- When something is unclear, state your assumption and keep going. Corrections
arrive at a later turn.
- Say what you're working on when others might touch the same area.
- Put the change's reasons link in the pull request description.
What should you watch for?
- Slow hooks. If sessions feel sluggish after a tool call, a hook is waiting too long on the network. Shorten its timeout.
- Too much context. A hook that adds the same text every turn drowns the agent. Add once, then only what's new.
- Duplicate hooks. Installing by hand twice can stack two copies. Check the settings file has one of each.
- Tokens in committed files. Only environment variables should hold them.
- Hooks are Claude Code only. Codex, Cursor and other clients don't run them. See Codex, Cursor and other MCP clients.
How do you know it's working?
- Agents mention decisions from an area before you've told them about it.
- Sessions pick up corrections at the next turn and change course on their own.
- Pull requests carry a reasons link without anyone asking.
- When a session stops unfinished, the next person continues from its handoff in minutes.
- People stop pasting context into sessions by hand.
Hooks are the most direct way to practise keep moving in Claude Code: the context comes to the work, so neither the agent nor the person directing it has to stop and go looking for it. What Claude Code hooks are useful for in a team has a shorter version.
The principle behind this: Keep moving: The work never waits, and neither do we.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).