project-stateby Atomic47 Labs
Terminal guide

The whole thing, from a terminal.

No app, no browser, no server. Claude Code, a folder, and five slash commands that take you from an empty project to a finished report — then a way to stop running the routine ones yourself.

Two commands

Install.

Run these in your shell — not inside Claude. The identifier ends in -public; the private repo of the same name will fail in a way that reads like a typo.

claude plugin marketplace add Atomic-47-Labs/project-state-plugin-public
claude plugin install project-state@project-state-plugin

Then turn on auto-update. /plugin → Marketplaces → project-state-plugin → Enable auto-update. It is off by default for any non-Anthropic marketplace, and installs four releases behind have been found in the wild.

Skills are namespaced under the plugin — /project-state:project-orchestrator — and the short form below works wherever the name is unambiguous. Everything writes plain files under project-state/ in the folder you ran it from, so git is your sync, your history and your backup.

Onboarding to reporting

Five slashes, in order.

There are forty-two skills. These five are the arc — everything else is something the orchestrator reaches for on your behalf when it needs to.

1/project-onboarding

Set it up, once

Day one, then never again

Run it from the root of the project folder. It asks about the work, picks a compliance pack, and writes project-state/. Drop in whatever documents already exist first — a proposal, last month’s minutes, a spreadsheet someone maintains. A session with documents produces a real picture; a session without them produces plausible filler.

2/project-state

Record what just happened

Constantly, in the moment

The habit everything else rests on. You do not need to name the skill — say the fact in plain language and it gets written, timestamped and logged. This is the one step that never automates, because it is your judgement about what mattered.

Or just say

Record this decision: Postgres over DynamoDB — the reporting queries need joins.

3/project-harvester

Pull in what happened elsewhere

Daily or weekly

Sweeps Slack, Gmail, Google Docs, Jira, Confluence, Linear and GitHub for signals about this project and drops them into the inbox as classified items. It reads; it never posts. Follow it with /project-inbox to accept or reject each one — the system never quietly decides a thread was a decision.

4/project-orchestrator

Find out what is actually due

Every morning

Reads the calendar and the state, then ranks what needs you — overdue milestones, a blocked gate, a report due this week, a deadline inside its warning window. Every line names the skill that handles it, so you answer “yes, do the weekly” and it delegates.

Or just say

What should I do today?

5/project-status-reporter

Produce the thing someone is waiting for

On the cadence your stakeholders need

Weekly status, board pack, quarterly claim, client update — generated from the records, not written from memory. If the report is wrong the state is wrong: fix the record and regenerate rather than editing the document and letting the two drift apart. Nothing sends; it stops at a draft.

Steps 3 to 5 are the loop you repeat forever. Step 2 happens between all of them, whenever something worth remembering occurs.

Automating it

Three ways to stop typing it.

project-state has its own scheduler, but it lives in the app — so from a terminal you reach for Claude Code’s automation instead. The three differ in one thing only: what has to be running.

/loop
While the session is open

Re-runs a prompt or slash command on an interval, or lets the model pace itself. Best for a watch you want during a working session — polling a build, holding a review window open, re-checking a deadline you are close to.

/loop 30m /project-orchestrator
Ends when the session ends. Not a substitute for a schedule.
/schedule
Cloud, on cron

Creates a scheduled cloud agent that runs whether or not your terminal is open. The closest thing to real unattended automation without standing up a server of your own — and the right default for a weekly that must not depend on your laptop being awake.

/schedule
Runs in the cloud, so it needs your state reachable there — git-synced, not laptop-local.
cron + claude -p
A machine you control

The headless path. A cron entry runs the orchestrator tick without a session, under a budget cap, logging where you can read it afterwards. Use it when the substrate lives on a box that stays on and you want the schedule next to it.

claude -p "/project-orchestrator tick" \
  --permission-mode bypassPermissions \
  --max-budget-usd 2 >> logs/cron-tick.log 2>&1
bypassPermissions means it will not stop to ask. Cap the budget and read the log.

/loop and /schedule are Claude Code features, not project-state ones — they will run any prompt, and they work the same whether or not this plugin is installed. Preview what a scheduled run would actually do before you arm one: /project-orchestrator tick --dry-run prints the due-list without invoking anything.

What to hand over

And what to keep.

Automate

The morning orchestrator tick

Cheap, read-only, and the thing you most reliably forget on a busy week.

The harvest sweep

Pure collection. Nothing it does is irreversible, and skipping it is how a Slack decision gets lost.

A report you have generated by hand three times

By then you know its shape, so a bad one is obvious instead of invisible.

Deadline warnings on a fixed external date

Filing windows and board dates do not move because you were busy.

Keep doing yourself

Recording decisions, risks and progress

This is judgement. An agent guessing what mattered today is how the record stops being trustworthy.

Anything that sends

It cannot, by design — but do not build around it either. A human sends.

A report you have never read

Automating an output you have not checked just produces wrong things faster, on a schedule.

A scheduled run drafts and queues. It never sends. Email is drafted, calendar entries are proposed holds, claims and public documents wait for sign-off. That is what makes automation safe to turn on at all — the schedule decides when, and you still decide whether.

Start in the folder you already work in. It writes plain files, so nothing here is hard to undo.

/project-onboarding