The daily routine — orchestrator, status, and the reporting matrix

What you need: A populated project-state/ substrate with milestones and a reporting matrix.

The substrate is populated. Milestones exist, risks are logged, the reporting matrix is configured. The daily question is: what should I do now?

The orchestrator brief

Run the orchestrator:

/project-orchestrator

Or just ask naturally:

What should I do today?

The orchestrator reads state.json, the reporting matrix, all milestones, all risks, and the calendar. It produces a prioritized brief:

# Orchestrator — 2026-05-28

## Urgent
- Weekly report overdue (last: 2026-05-19, 9 days ago)
  → /project-status-reporter

## This week
- 5 documents in inbox/ awaiting triage
  → /project-inbox
- Milestone M03 at 60% — planned end 2026-05-30 (2 days)
  → /project-milestone-manager

## On deck
- Blog post "typed-state-vs-wiki" in draft — review and publish
  → /project-blog-publisher
- Sprint retrospective due end-of-sprint
  → /project-review-meeting

## Quiet
- No gate transitions pending
- No claims due within 14 days
- No SC meetings scheduled

---
What would you like to do first?

Every line names the skill that handles it. Say "do the weekly report" and the orchestrator delegates to project-status-reporter. Say "triage the inbox" and it hands off to project-inbox. The orchestrator routes — it does not do the work itself.

The cadence model

The orchestrator tracks overlapping clocks:

Not every project uses every clock. An agile internal project might only care about daily and weekly. A grant-funded consortium project uses all of them. The reporting matrix determines which clocks are active.

The reporting matrix

The matrix is the central configuration. Here is project-state's own reporting-matrix.yaml:

schema_version: 2
manifest_kind: reporting_matrix

entries:

  - id: monday-tracker-email
    stakeholder_group: internal.team
    report: "Monday tracker email"
    cadence: { kind: weekly, day: monday, lead_time_hours: 8 }
    format: md
    surface: blog
    generator: project-status-reporter

  - id: sprint-retrospective
    stakeholder_group: internal.team
    report: "Sprint retrospective"
    cadence: { kind: sprint-aligned, timing: "last-day-of-sprint" }
    format: md
    surface: blog
    generator: project-review-meeting
    profile: agile-default.review-meeting

  - id: baseline-report-bundle
    stakeholder_group: internal.team
    report: "Baseline report bundle (docx + xlsx)"
    cadence: { kind: event-driven, trigger: "phase-transition, milestone-completion, on-demand" }
    format: docx+xlsx
    surface: website
    generator: project-doc-suite-generator

  - id: reference-docs
    stakeholder_group: public
    report: "Reference documentation"
    cadence: { kind: on-publish, trigger: "documents/published/" }
    format: mdx
    surface: website
    generator: project-website-publisher

Each entry answers five questions: who needs this report, what is it, when is it due, where does it go, and which skill generates it. The orchestrator reads these entries on every invocation to compute what's overdue, what's coming up, and what's quiet.

The profile field on the sprint-retrospective entry means the project-review-meeting skill loads its behavior from the agile-default pack's review-meeting profile. Different packs produce different profiles — a pic-pcais pack would have entries for quarterly SC meetings and annual questionnaires with their own cadences and formats.

The weekly report

When the orchestrator flags the weekly report as due and you say "do it," project-status-reporter reads the substrate and generates:

# Weekly Status — 2026-W22

**Phase:** 04-release (agile-default)
**Health:** green

## Milestones
| ID | Title | % | Status | Target |
|----|-------|---|--------|--------|
| M01 | v2→v3.2 plugin release | 100% | complete | 2026-05-12 |
| M02 | Starter pack hardening | 40% | in_progress | 2026-06-15 |
| M03 | Matrix editor | 60% | in_progress | 2026-05-30 |

## This week
- Published v3.2 release notes to blog
- Harvested 5 Slack signals, 3 Gmail threads
- Promoted 4 documents from inbox to references

## Risks
- R-01 single maintainer (high/high) — open, unmitigated
- R-03 no tests or CI (medium/high) — open

## Next week
- Complete M03 matrix editor
- Begin M04 pack registry research
- Triage 5 new inbox documents

The report publishes to whichever surface the matrix entry specifies — in this case, the blog. If the entry said surface: gmail, the report would appear as a Gmail draft for review.

The outbox

Every artifact that project-state generates for external delivery goes through a review step. The pattern depends on the surface:

• Blog — drafts appear on scsiwyg. You review and publish (or the publication_review_required flag in manifest controls whether auto-publish is allowed).
• Gmail — always a draft. The skill creates the draft; you review and send from Gmail.
• Slack — auto-posts to the configured channel (no review gate, by design — Slack is ephemeral).
• Calendar — proposed holds, not confirmed events.
• Website — publishes to the project site. The require_review_for_public flag controls whether auto-deploy is allowed.

The principle: the system does the work of generating the artifact. A human does the work of deciding to send it.

End-of-session routine

The orchestrator also supports an end-of-session pattern. When you're wrapping up a work session:

End of session

The orchestrator:

1. Logs what was accomplished to activity.ndjson
2. Updates any milestone percentages that changed
3. Notes what's still pending for next time
4. Optionally creates a git checkpoint via project-git

This keeps the substrate current without requiring you to remember what changed.

Next step

The orchestrator reads state and tells you what to do. But what does that state actually look like? Working state shows how milestones, risks, and decisions are stored as individual YAML files and how they drive the reports the orchestrator dispatches.