agent-status-hub
Skill0 starsChanged 7 days agoMITView on GitHub
Keep an AI coding agent oriented across sessions without a bloated status.md — a hard-capped now hub (docs/status.md, 40 lines / 3 KB, four fixed headings) injected by a Claude Code SessionStart hook, an append-only docs/log.md of which only the latest entries are injected, per-topic plans deleted when done, ADRs, a manual /handoff skill and a CI cap check. Use when status.md or PROGRESS.md keeps growing, when CLAUDE.md has filled up with next actions and strikethrough history, when a new or sandboxed container session has to rediscover where the project stands, or when asked how to carry progress and handoff notes between Claude Code sessions.
In this repository23 other files it gives its agents.
- skills/vercel-react-best-practices/AGENTS.mdAGENTS.md
- claude-code-docker-sandboxSkill
- cloudflare-api-token-permissionsSkill
- cloudflare-cron-to-discordSkill
- cloudflare-d1-drizzle-migrationSkill
- cloudflare-d1-keyless-host-backupSkill
- cloudflare-d1-weekly-backup-via-prSkill
- cloudflare-mcp-claude-toolingSkill
- cloudflare-r2-private-image-uploadSkill
- cloudflare-workers-bot-scan-defenseSkill
- cloudflare-workers-builds-keyless-deploySkill
- cloudflare-workers-deploy-skeletonSkill
- cloudflare-workers-e2e-playwrightSkill
- cloudflare-workers-host-synthetic-checkSkill
- cloudflare-workers-passkey-authSkill
- cloudflare-workers-pat-bearer-authSkill
- cloudflare-workers-space-membership-inviteSkill
- cloudflare-workflows-for-long-tasksSkill
- playwright-e2e-in-docker-sandboxSkill
- sandboxed-agent-github-token-via-1passwordSkill
- sandboxed-agent-git-relaySkill
- snr-writingSkill
- vercel-react-best-practicesSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 1 is distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 22
NOT for: team task tracking with assignees and due dates (use the issue tracker.
- Very specific: line 64
All four live in the repository, so a sandboxed container session (bind-mounted repo, committed .claude/settings.json) behaves exactly like …
- Very specific: line 74
Add the hooks.SessionStart block to the committed .claude/settings.json (not settings.local.json, or the container won't get it).
- Distinctive: line 75
Add the CI step before dependency install.
- Very specific: line 77
Verify: bash .claude/hooks/check-status.sh prints OK.
- Very specific: line 79
If the headings are translated, change them in both status.md and check-status.sh — the script pins them literally.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Agent status hub: repository context across sessions
Every agent session starts empty. The usual fix — "read status.md first, update it as you go" — works for a month and then the file is 200–370 lines of mixed plans, research dumps and completed-phase history, loaded in full at every start and edited in half of all commits. This skill replaces the single file with three files of different lifetimes, puts a hard cap on the only one that is loaded every session, and makes loading and write-back mechanical instead of an instruction the agent may or may not follow.
First applied to kokemusu on 2026-08-23 (PR #6). The measurements below come from the author's own repositories.
When to use this skill
- A repo has a
status.md/PROGRESS.md/docs/project-status.mdthat keeps growing, or a CLAUDE.md that has become a progress file (strikethrough history, "next actions" with dates) - A sandboxed / autonomous agent (see
claude-code-docker-sandbox) must pick up where the last session stopped without a human re-explaining - You are asked "how should Claude remember where this project stands between sessions?"
- NOT for: team task tracking with assignees and due dates (use the issue tracker; this skill is the agent's orientation layer on top of it), or per-file coding conventions (those belong in CLAUDE.md /
.claude/rules/)
The problem, measured (2026-08-23)
| Repo | File | Size | Commits touching it |
| portfolio | status.md | 368 lines / 20 KB — research notes, a docker-compose template, Phase 1.0–1.4 completion records | — |
| mazuoboeru | docs/project-status.md | 204 lines; biggest sections "what is needed" 41, "roadmap" 40, "what runs in prod" 32 | 44 of 88 |
| nyalog | docs/status.md | 50 lines after a 2026-08-05 rewrite into a hub, but its "completed phases" section is append-only and grows again | 54 of 97 |
| kokemusu | CLAUDE.md | 69 lines but 14.4 KB, lines of 1,319 chars; a "next actions" section of 3.3 KB with | 6 of 14 |
Root cause: three kinds of information with different lifetimes share one file, and a "read it first" rule loads all of it every session.
| Kind | Changes | Belongs in |
| now, next step, blockers | every session, rewritten | a small hub with a hard cap |
| plans, research results | written once, read when executing | one file per topic, deleted when done |
| completed history | append-only, grows forever | git log / PRs / a one-line log that is never loaded in full |
Design
CLAUDE.md conventions and pointers only — no progress, no history, no "next actions"
docs/status.md the NOW hub. Hard cap 40 lines / 3 KB. Four fixed H2 headings:
phase / next 3 moves / blockers & waiting-on-human / open PRs
docs/log.md append-only, newest first, one line per milestone (date, what, #PR / ADR / skill).
Never loaded in full (the hook injects the latest 5 entries); `head -20 docs/log.md` on demand
docs/plans/<topic>.md created when work on a topic starts; deleted when done (the conclusion lives in an ADR or one log line)
docs/adr/, CONTEXT.md decisions and vocabulary (unchanged; see `grill-with-docs`)
docs/roadmap.md phases and checkboxes only; no narratives of how things got doneThree rules keep it from regrowing:
- A finished item in
status.mdis deleted and moved to the top oflog.mdas one line. Strikethrough is forbidden — it is the first symptom of bloat. - A
status.mdsection longer than 8 lines becomesdocs/plans/<topic>.mdplus a one-line pointer. - "Done" is recorded in exactly three places: git, PRs,
log.md. Never instatus.mdor CLAUDE.md.
The cap is enforced by a script (check-status.sh: ≤ 40 lines, ≤ 3,000 bytes, no ~~, exactly the four headings) that both the write-back skill and CI run. 40 lines is enough for a solo project's "now"; 3 KB keeps Japanese text (3 bytes/char) honest.
Mechanisms (Claude Code)
All four live in the repository, so a sandboxed container session (bind-mounted repo, committed .claude/settings.json) behaves exactly like the host. Templates for every file: references/templates.md. Doc-verified facts behind the choices: references/claude-code-facts.md.
- SessionStart hook injects the hub.
.claude/hooks/session-start.shprintsdocs/status.md, the latest 5 entries ofdocs/log.mdandgit log --oneline -5; registered in the committed.claude/settings.jsonunderhooks.SessionStart(no matcher → fires on every source:startup,resume,clear,compact,fork). A SessionStart hook's stdout is added to Claude's context; thecompactsource means the "next 3 moves" survive compaction without relying on the summary. This replaces "read status.md first" (advisory) with something that always happens (deterministic). /handoffskill writes it back..claude/skills/handoff/SKILL.mdwithdisable-model-invocation: true(only the human triggers it, at the end of a session). Steps: gather state → add finished milestones to the top oflog.md→ rewritestatus.md(never append) → delete finished plans, tick roadmap boxes → runcheck-status.shuntil OK → commit on the working branch (branch off if onmain) → report the first "next move" as the next session's starting point.- CI gate.
bash .claude/hooks/check-status.sh docs/status.mdas the first step of the required CI job: a PR that pushes the hub over the cap cannot merge. Cheap, and the only enforcement that survives an agent ignoring instructions. - CLAUDE.md diet. Move "next actions" to
status.md, completion notes tolog.md, long decision bullets to one-line pointers at the ADR / docs. Add two lines: the hub rules and "update via/handoff". No compaction-steering line: compaction is automatic, the SessionStart hook re-injects the hub oncompact, and current best practices list aggressive context management under "What you can stop doing" (removed in 0.2.0). kokemusu went from 69 lines / 14.4 KB to 45 lines / 7.8 KB; the official target is under 200 lines, and/doctorproposes trims.
Install (≈ 15 minutes)
- Copy the templates:
docs/status.md,docs/log.md(seed it with the last few milestones fromgit log),.claude/hooks/session-start.sh,.claude/hooks/check-status.sh(chmod +xboth — git keeps the bit),.claude/skills/handoff/SKILL.md. - Add the
hooks.SessionStartblock to the committed.claude/settings.json(notsettings.local.json, or the container won't get it). Use${CLAUDE_PROJECT_DIR}/.claude/hooks/session-start.shas the command with"args": [](exec form, so the path placeholder needs no quoting). - Add the CI step before dependency install.
- Diet CLAUDE.md and point
roadmap.md/ any "current state" section atstatus.md. - Verify:
bash .claude/hooks/check-status.shprintsOK;CLAUDE_PROJECT_DIR=$PWD bash .claude/hooks/session-start.shprints the hub; in a new session/hookslists SessionStart and the first message shows the injected hub;/contextshows CLAUDE.md shrank.
If the headings are translated, change them in both status.md and check-status.sh — the script pins them literally.
Inside a Docker sandbox
- The repo is bind-mounted at
/workspaceandCLAUDE_PROJECT_DIRresolves there, so the hook, the skill and the check script need no rebuild and no extra mount. - Auto memory does not cross the boundary. The container's
CLAUDE_CONFIG_DIR(/home/node/.claude, a named volume) holds its ownprojects/<repo>/memory/; the host has another. Anything both sides must know goes in the repo — the hub — never in memory. Keep auto memory for preferences and corrections. - Session transcripts are per machine too:
claude --continueinside the container resumes container sessions only. The hub is what makes a host session and a container session interchangeable. - Hooks run under
bypassPermissions(the container default fromclaude-code-docker-sandbox) like anywhere else; deny rules are unaffected.
Alternatives considered
- GitHub Issues / Projects as the primary store — fine for a human backlog, but a sandbox token scoped to Contents + Pull requests cannot write issues, and
gh apiis typically denied. Public repos can still be read unauthenticated. Use issues for backlog items that don't need to be in context; keep the agent's "now" in the repo. @docs/status.mdimport in CLAUDE.md — imports load at launch, so it costs the same context, and there is no re-injection after/compactbeyond CLAUDE.md's own reload; the hook is explicit about when it fires.- Sharing auto memory between host and container (
autoMemoryDirectory) — absolute paths differ per environment and a repo-relative path isn't allowed; the value doesn't cover the friction. - A Stop / PreCompact hook that forces a status update — blocking every turn end is heavy-handed; a manual
/handoffplus the CI gate is enough. (A PreCompact hook's stdout becomes instructions for the compaction summary, and a Stop hook can returnadditionalContextsince 2.1.163; the hub needs neither.)
Verified on kokemusu (2026-08-23) — and what is still open
- Hub 23 lines / 1.5 KB; CLAUDE.md 69 → 45 lines, 14.4 → 7.8 KB;
check-status.shgreen locally and as the first CI step of PR #6 (cipassed in 27 s with the step). - The hook invoked through the exact settings command string (
${CLAUDE_PROJECT_DIR}/.claude/hooks/session-start.sh) prints hub + log + git on the host. - UNVERIFIED: the hook firing inside the sandbox container on the next
claudestart (settings.json is bind-mounted; nothing suggests otherwise, but it has not been observed yet). - UNVERIFIED: the first real
/handoffrun end to end (the skill text was written with the deployment, not exercised). - UNVERIFIED: whether SessionStart output on the
compactsource alone keeps the agent on track in a long autonomous loop. 0.2.0 dropped the CLAUDE.md compaction instruction because current best practices no longer recommend compaction-steering lines. If an agent repeatedly loses the first next move after compaction, add a PreCompact hook that prints that line (its stdout becomes instructions for the compaction summary) rather than a CLAUDE.md line.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

