← All craftbooks

Standup / Team Update Summary

Comms and ops automationevalv1.0.0released 2026-06-05workflow: build-loop

Condense a pile of raw team updates (standup messages, async check-ins, channel dumps) into one clean summary grouped by person or workstream, surfacing blockers and decisions. Scopes the grouping axis and summary shape FIRST (by-person vs by-project, what counts as a blocker, the yesterday/today/blockers frame), then a copywriter compresses every raw update into that frame without dropping anyone. The scope-first step prevents a 4B model from rambling and guarantees blockers get their own callout section instead of being buried. Use for daily standup summaries, async update rollups, team check-in digests, and turning Slack threads into a readable recap.

Steps

Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.

  1. Scope the summaryplannerentry

    lock the grouping axis, frame, and blocker definition

    Show working prompt
    Decide the summary's shape before compressing anything. (1) Pick the grouping axis — by person or by workstream/project — based on the raw input. (2) Lock the per-item frame (default: Yesterday / Today / Blockers, or Done / Doing / Blocked). (3) Define what counts as a blocker (an explicit ask, a dependency on someone, the words blocked/stuck/waiting) so blockers can be lifted into a dedicated top section. (4) Decide a Decisions callout if the updates contain any. Write an acceptance-criteria checklist ('every contributor/workstream from the input appears', 'each item uses the locked frame', 'all blockers are also collected into one top Blockers section', 'no raw update is dropped', 'one line per update item') plus the grouping + frame to notes/scope.md via write_task_note AND the produces path. No summarizing yet.
  2. Summarizecopywriter

    compress every update into the locked frame

    Show working prompt
    Write summary.md from the raw updates using the locked grouping and frame. (1) Open with a 'Blockers & asks' section that lifts EVERY blocker (per the locked definition) to the top, each tagged with who is blocked and who they need. (2) Then one block per person/workstream in the locked frame, one tight line per item — strip filler, keep the signal (what shipped, what's next, hard numbers). (3) Add a Decisions section only if the input contains decisions. Include every contributor from the input even if their update was thin (write '(no update)'). Invent nothing; if an item is ambiguous, keep it verbatim-ish rather than guessing. On a loop-back, fix only the flagged blocks. Write the path and a count (contributors covered, blockers surfaced) to notes via write_task_note.
  3. Evaluatereviewer

    Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

    Show working prompt
    QA summary.md against the locked criteria. (1) Cross-check the contributor/workstream list against the raw input — every one present? FAIL on any drop. (2) Confirm a top Blockers section exists and that every blocker matching the locked definition appears there, attributed. (3) Confirm each item uses the locked frame and is one tight line (no paragraphs). (4) Spot-check 3 items against the raw input for accuracy and no fabrication. (5) Confirm Decisions appears iff the input had decisions. Write PASS/FAIL per criterion with the specific gaps.
    
    Then route — this is the whole point of the loop:
    
    - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`.
    - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "summarize" })` to loop back. The builder fixes exactly those gaps.
    
    Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.
  4. Finishdeveloper

    All acceptance criteria met. Stamp a short summary and report DONE.

    Show working prompt
    Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

Source

View this craftbook on GitHub · MIT license