project-stateby Atomic47 Labs
Operator guide

Drive it for a week. Then stop driving it.

Everything here is something you do by hand first. Once you have seen a report come out right three times, you put it on a cadence and stop thinking about it. That order matters — schedule a report you have never read and you will not trust what it sends.

Where you work

Three surfaces, one project.

The same skills run everywhere and write the same files, so there is no wrong choice and nothing to migrate between them. Pick by where you already are.

Claude Code

You are already in the repo

The terminal, where the work is. Best when you are mid-task and something needs recording without breaking stride — a decision made in a code review, a milestone that just landed.

Skills are namespaced: /project-state:project-orchestrator

Cowork / Desktop

You want to see it while you talk to it

The GUI. Same skills, but answers come back as rendered artifacts rather than terminal text. Best for the sessions where you are thinking out loud — onboarding, a status review, working through a risk.

Drop documents straight into the conversation

project-state.app

Someone else needs to look

The dashboard. Today, Kanban, Calendar, Documents, Processing. Best when the audience is not you — a PM checking milestones, a stakeholder reading a report — or when work must continue while nobody is at a keyboard.

The only surface that can run unattended
What you actually do with it

Five things worth learning first.

There are forty-two skills. You will not learn them, and you do not need to — the orchestrator knows which one to call. These five are the ones worth doing deliberately until they are habit.

“What needs me today?”

Any surface. In the app it is the Today view.

The orchestrator reads the calendar and the state, then ranks what is actually due.

Not a fixed routine — it knows what day it is, what is overdue, which gate is blocked, what is due this week, and what can wait. Everything it raises comes with the skill that handles it, so you can answer “yes, do the weekly report” and it delegates.

You say

What should I do today?

“This just happened — don’t let it get lost.”

Wherever you are when it happens — usually the terminal.

Say it in plain language. The record gets written, timestamped and logged.

A decision, a risk, a change of scope, a milestone moving. This is the habit the whole system rests on: if it is said once, in any surface, it is in the record and every report downstream regenerates from it. Nothing needs a form.

You say

Record this decision: we are going with Postgres over DynamoDB, because the reporting queries need joins.

“Someone is waiting on a report.”

Terminal or Cowork. It lands in the queue either way.

It is generated from state, not written from memory.

Weekly status, board pack, quarterly claim, client update. Because the report is derived, a wrong report means the state is wrong — you fix the record and regenerate, rather than editing the document and letting the two drift apart.

You say

Draft the weekly status.

“What happened while I wasn’t looking?”

Best in the app, where Processing shows the run live.

Harvest pulls from the tools your team already uses, then triage sorts it.

Slack, Gmail, Google Docs, Jira, Confluence, Linear, GitHub. It reads; it does not post. Everything lands in an inbox as classified items you accept or reject — the system never quietly decides that a Slack thread was a decision.

You say

Harvest signals, then triage the inbox.

“Where did this come from?”

Any surface.

Ask anything and the answer arrives with its sources.

Why a risk got re-scored, what a decision depended on, when a milestone actually slipped. This is the difference between a project you can query and a folder you have to read — and it is the reason recording things in the moment pays off later.

The turn

Anything you have done by hand three times is something the project should be doing without you.

Recording facts stays manual forever — that is your judgement and it does not automate. What moves to a cadence is the derived work: the weekly that always says the same shape of thing, the harvest you keep forgetting to run, the quarterly that sneaks up on you.

Scheduling

Three moves to hand it over.

1
Declare

Say who needs what, once.

The reporting matrix is one file holding a single sentence per stakeholder group: what report, at what cadence, in what format, on which surface, produced by which skill. Onboarding seeds it from your compliance pack, so you are usually editing a draft rather than writing from scratch.

2
Compile

Turn the matrix into a schedule.

The automator reads every matrix entry, works out what is time-fired and what is event-fired, spreads the fire times across your quiet window, and writes the cadence registry. Run it in update mode after any matrix change — it adds what is new and never overwrites a time you moved by hand.

/project-automator update
3
Arm

Give it something that is awake.

A schedule needs a host. The app has one built in, and a cron entry can wake it when the app is closed. This is the honest constraint of the whole feature: a laptop that is shut does not run your Monday report. If the cadence matters, the app belongs somewhere that stays on.

Change it by dragging, or by asking

The Calendar view is the one place to see and edit everything scheduled. Drag a card to move it; dependent items re-anchor with it. Or say what you want in the calendar’s chat — “move the weekly to Friday mornings” — and it edits the registry through the same guarded path the drag uses. Presets cover the common bundles if you would rather not assemble a cadence by hand.

It never sends

A fired task generates a draft and puts a card in the queue. Email is drafted, never sent. Calendar invites are proposed holds. Claims and public documents wait for sign-off. This is the promise that makes scheduling safe to turn on: the schedule decides when, and a person still decides whether.

If you want a plan

A first week that works.

Day one — onboard, and bring your documents

Run /project-onboarding and drop in whatever already exists — the proposal, last month’s minutes, the spreadsheet someone maintains. Grounding beats interviewing: a session with documents produces a real picture, a session without them produces plausible-sounding filler.

Days two to four — record things as they happen

Do not batch it up. Every decision, risk and progress change goes in when it occurs, in whichever surface you are already using. Ask “what should I do today” each morning so you learn what it notices.

Day five — generate the weekly by hand, and read it properly

If it is wrong, the state is wrong — fix the record, regenerate, and note what was missing. That gap is usually a habit, not a bug. Once the weekly comes out right without editing, it is ready to schedule, and so is everything shaped like it.

Install takes five minutes. The habit takes a week. After that the reporting is somebody else’s problem.

/project-onboarding