em-routines v0.5.1 Foundation

The platform's daily autonomy loop. A deterministic morning driver sweeps every assigned account and stages the day's judgment as tick-to-approve proposals; a deterministic evening driver applies the approved ticks and closes the plan. Everything is Postgres - the plan, the proposals, the signals - and judgment always goes to proposals, never straight to rows.

Problem it solves: run the whole toolkit on a schedule without letting an autonomous loop write anything consequential unattended - the Python drivers own the deterministic pipeline, the skills only narrate and stage, and every judgment call waits for the EM's tick.

em-platform-morning-runUser skillLight · ~5-20k

The flagship morning routine. The deterministic driver (lib/em_routines/morning.py) owns the whole pipeline - sweep every assigned account via em_db.morning.sweep, fuse cross-domain composite signals, emit persisted hygiene, risk and composite signals via em_db.signals.emit, stage judgment items as proposals via em_db.proposals.stage (it never writes risks or feedback directly), and upsert today's daily plan via em.daily_plan_upsert leading with what changed since yesterday. The skill only narrates the plan and proposal prose on top of it. The run ends with trust suggestions and factual maintenance (proposals.expire, signals.expire).

When to use it
run my morningmorning runplatform morning runrun the morning routine
Reference - what it brings, its process, and what it needs
BringsOne deterministic pass that turns overnight change into a prioritized, change-led daily plan plus a proposal queue the EM ticks - autonomy without an unattended write.
Process
  1. Resolve the acting EM and assigned accounts; read the clock from em.em_clock (EM timezone).
  2. Sweep accounts, fuse composites, emit hygiene / risk / composite signals.
  3. Stage judgment items as proposals (risk review, commitments, blocker recurrence).
  4. Upsert the daily plan leading with "what changed since yesterday"; expire stale proposals and signals.
NeedsBashReadem_db.morningem_db.proposalsem_db.daily_plan
em-platform-closerUser skillLight · ~5-20k

The evening closer. The deterministic driver (lib/em_routines/closer.py) auto-approves and applies only trust-ladder 'auto' proposals, applies every human-approved proposal via em_db.proposals.apply, turns apply failures into 'act' signals, and closes today's plan via em.daily_plan_close with a structured EOD summary. On top of the driver the skill auto-logs the day's factual meeting captures (delegating to the 1:1 / standup / retro / profile logger skills) and stages the day's client conversation logs and directed follow-ups as proposals (conversation.create / carry_forward.create) for the EM's tick. It never writes risks, feedback, or conversation logs outside apply().

Reference - what it brings, its process, and what it needs
BringsA clean end-of-day close: the factual work is logged, the approved ticks are applied, failures surface as act signals, and the plan is closed with an EOD summary.
Process
  1. Auto-log the day's meeting captures via the domain logger skills.
  2. Stage conversation-log and carry-forward proposals for the EM's tick.
  3. Trust-auto decide + apply 'auto' proposals; apply every approved proposal.
  4. Turn apply failures into act signals; close today's plan with an EOD summary.
NeedsBashReadem_db.proposalsem_db.daily_plan
em-platform-backfillUser skillMedium · ~20-80k

A date-ranged historical replay of the closer's factual-capture step for one account: it replays each historical Fireflies meeting through the domain logger skills over its true date, bypassing all judgment. It never creates risks, feedback, tasks, daily plans, act-severity signals, or proposals - purely a ledgered, idempotent factual backfill.

When to use it
run the backfillbackfill the platformreplay historical meetingsbackfill Acme Robotics
Reference - what it brings, its process, and what it needs
BringsA way to populate the platform's factual history for a newly-onboarded account without inventing judgment - so profiles, 1:1s and ceremonies read as if the platform had been running all along.
Process
  1. Resolve one account and a historical date range from the manifest.
  2. Replay each Fireflies meeting through the matching logger skill over its true date.
  3. Ledger every replayed unit for idempotency; skip anything already captured.
  4. Stop at the factual layer - no risks, tasks, plans, proposals, or act signals.
NeedsBashReadFireflies