Status Snapshots and Change Analysis

Monitoring in the system is built on dated snapshots: capture the project state on a date — and afterwards any "what changed?" is computed between snapshots, not recalled from memory. This distinguishes snapshots from the daily walk (/manage, see Daily operations): the walk is "what to do now", the snapshot is "the state on a date".

Work snapshot: /status-snapshot

Type /status-snapshot — the agent collects the state as of a date (today by default):

• Work state — the distribution of issues by status;
• Issues sample — key issues with statuses, sprints, and dates;
• Blockers — what is blocking work;
• Plans and sprints — active and upcoming periods;
• Timeline — the state of the plan (if timeline.md or a live schedule exists);
• Milestones — MVP, releases, charter dates: with target dates and sources;
• Themes / epics — work grouping, when it is set up;
• Sources and gaps — what was collected and what was missing.

Result — the file status-snapshot-YYYY-MM-DD.md. If data is missing, the agent honestly records the gap instead of inventing rows.

Budget snapshot: /budget-snapshot

Type /budget-snapshot (optionally: approved_budget, actuals, or current_position). The agent collects dated budget lines: positions, amounts, total — in a single unit (currency, person-days, or story points).

Important: the agent does not invent figures. If the charter says the budget is "unknown" and there are no tables, the agent asks you to paste the data (or records a snapshot without figures on your request). It does not pull ERP data on its own: figures come from your documents or a paste.

Result — the file budget-snapshot-YYYY-MM-DD.md.

The delta: /status-delta

Type /status-delta — the agent takes two snapshots (by default the latest and the previous one) and computes what changed:

Section	What it holds
New	issues and blockers that were not in the prior snapshot
Changed	status changes, date shifts, plan and milestone moves
Resolved	what became Done / resolved
Still watching	what remains in flight and needs attention

Honesty rules of the delta:

• it is computed from the snapshots only — not from conversation memory and not "by eye on the tracker";
• plans and milestones are checked always, even when the work is flat;
• a quiet week is a short honest answer — "no material changes" — not invented progress.

Result — the file status-delta-<date1>_to_<date2>.md. The first snapshot can be fixed as a baseline edition (/status-delta baseline) — then the delta is computed from it.

How the cycle comes together

end of period:
  /status-snapshot            → work snapshot for the date
  /budget-snapshot            → budget snapshot (if figures exist)
  /status-delta               → what changed since the prior snapshot
  /report                     → the management report based on the delta (see the reporting guide)

Snapshots are the input for reports: /report requests a fresh delta on its own if there is none for the current date.

Good to know

• Snapshots are markdown documents you can open and correct (for example, refine a blocker wording) through review.
• One snapshot per date: a same-day re-run updates the existing snapshot.
• Snapshots do not replace the walk: "what to do today" is /manage; "how the project changed since last week" is snapshots + delta.

Where to continue

• Reporting for management — how snapshots and the delta become a report.
• Daily operations: walkthroughs and meetings — the daily mode.
• Scope control and change management — when the delta shows "new" work outside the scope.