em-team-sentinel v0.6.0 Delivery

A team-health sentinel for one engagement - it watches the team's recurring ceremony signals (daily standups + sprint retros) and raises deterministic, defensible flags for the EM's 1:1s and daily plan. Every other people plugin develops the individual; this one reads the team.

Problem it solves: the highest-value team signals - someone stuck on the same ticket all week, a blocker that has carried, a member who never speaks, a retro issue that keeps recurring - are buried in ceremony transcripts and decay within days. The sentinel reads every ceremony deterministically and surfaces the flags with verbatim lines, so the EM walks into 1:1s with the week's signals instead of missing them.

em-standup-loggerUser skillMedium · ~20-80k

Reads one daily standup transcript and writes a Standup Log row: actual attendees + present count, duration, a per-person machine-readable work anchor string (the line the weekly report parses), blockers with big-blocker classification, and a deterministic red-flag multi-select. Logs one ceremony; never compares across days. Idempotent on the transcript id.

Reference - what it brings, its process, and what it needs
BringsA stable, queryable per-standup record whose anchor string makes the headline repeated-status detection possible.
Process
  1. Pull the Fireflies transcript + summary.
  2. Extract attendees, anchors, blockers, announcements.
  3. Compute the per-standup red flags deterministically.
  4. Write one readable Standup Log row (idempotent).
NeedsFirefliesNotionmanifest em-team-sentinel block
em-retro-loggerUser skillLight · ~5-20k

Reads one sprint retrospective transcript into a Retro Log row: what went well / what didn't, every owner's dated action items (EM-owned subset routed to the task DB), plus two deterministic backward comparisons against the prior 2-3 retros - recurring issues and prior-action follow-through - and a red-flag multi-select. Self-contained backward look; idempotent on the transcript id.

Reference - what it brings, its process, and what it needs
BringsA retro record that measures change, not catharsis - it knows which themes keep recurring and whether last retro's actions actually got done.
Process
  1. Pull the Fireflies summary + transcript.
  2. Extract the rich record + every owner's action items.
  3. Compare against the prior 2-3 retros for recurrence + follow-through.
  4. Write the Retro Log row + set red flags (idempotent).
NeedsFirefliesNotionmanifest em-team-sentinel block
em-standup-weekly-reportUser skillLight · ~5-20k

The Friday team-health routine. Reads the week's Standup Log rows, runs the deterministic cross-day detections - repeated status per person (same anchor with no progress, with the verbatim lines), persistent blockers, silent / dominated members, timebox overruns - writes a Weekly Standup Report row, renders a Qualitara-branded HTML team-health report, and returns an envelope the routine uses to surface red flags for 1:1 prep. Reads the standup rows; never writes them.

Reference - what it brings, its process, and what it needs
BringsThe cross-day intelligence the loggers can't see - who has been stuck all week, in their own words - delivered as a printable report so the EM walks into every 1:1 with the week's signals.
Process
  1. Read the week's Standup Log rows.
  2. Walk the per-person anchor sequences; apply run-length thresholds.
  3. Detect persistent blockers, silent / dominated, timebox overruns.
  4. Write the Weekly Standup Report row, render the HTML, return the 1:1-prep envelope.
NeedsNotionPython rendererRead/Write/Bashmanifest em-team-sentinel block
em-ceremony-loggerUser skillLight · ~5-20k

Captures one named internal sprint ceremony (sprint planning, sprint review, or backlog refinement) into a ceremony log row - full-transcript extraction, per-kind structured details, a deterministic red-flag list reusing the standup definitions, and EM-owned action items surfaced to the caller (never auto-written to tasks). Agent mode only.

Reference - what it brings, its process, and what it needs
BringsThe sentinel's coverage extends past standups and retros to planning, review and refinement - the same deterministic red-flag lens applied consistently.
Process
  1. Pull the ceremony transcript and summary.
  2. Extract per-kind structured details (stories, decisions, demos, etc).
  3. Compute the deterministic red-flag list.
  4. Write one em.ceremony_logs row via em_db.ceremony.log (idempotent).
NeedsFirefliesBashReadem_db.ceremony
em-kickoff-loggerUser skillLight · ~5-20k

Logs a project kickoff meeting from a Fireflies transcript or pasted notes - project, goals, stakeholders, milestones, risks mentioned (handed off to em-risk-detector, never logged directly), and the comms cadence - then offers to spawn selected goals as follow-up tasks.

Reference - what it brings, its process, and what it needs
BringsA durable kickoff record with a clean handoff into risk tracking and task follow-up, instead of a kickoff's context evaporating after the call.
Process
  1. Extract project, goals, stakeholders, milestones, risks, cadence.
  2. Preview; write only after an explicit yes via em_db.kickoff.log.
  3. Append an account-changelog entry.
  4. Offer em_db.kickoff.spawn for selected goals, previewed separately.
NeedsBashReadem_db.kickoff
em-postmortem-loggerUser skillLight · ~5-20k

Logs an incident postmortem from a retro transcript or pasted notes - incident summary, timeline, impact, root cause, contributing factors, and action items - with a blameless-language gate that rejects any draft that name-blames an individual and forces a systems-language re-draft.

Reference - what it brings, its process, and what it needs
BringsA structured, blameless incident record plus a clean path to follow-up tasks, instead of an incident retro that fades into hallway memory.
Process
  1. Structure the incident: summary, timeline, impact, root cause, factors.
  2. Enforce the blameless-language gate on the draft.
  3. Preview; write only after an explicit yes via em_db.postmortem.log.
  4. Append the changelog entry; offer follow-up tasks separately.
NeedsBashReadem_db.postmortem