Project Briefing Workflow

Executive briefing of the last 24 hours of commits, PRs, and repo activity for the active project (default: Dedalus monorepo).

A project briefing gives Kevin a scannable "what changed overnight" view without reading every diff. Source: retired project-briefing automation, 2026-05-31

Trigger

Its scheduled automation was retired on 2026-11-03 (no run since 2026-07-03); run the workflow on request. Run it before a standup or handoff, after a dense PR burst, or when Kevin asks "what changed in this project?" The briefing is repo/project scoped. It should not become a personal productivity summary; use Daily Work Summary Workflow for that.

Scope selection

Default target is the active project Kevin names or the repo set in the run config. Do not assume a legacy local path if the workspace has a current checkout. Resolve in this order:

1. Explicit project/repo in Kevin's request.
2. target_repo in the run config.
3. Current working tree if the agent is already inside a project.
4. Known local checkout under ~/Documents/GitHub/.
5. GitHub repo via gh or GitHub MCP in cloud runs.

If multiple repos match, report the ambiguity instead of briefing the wrong one.

Data sources

• GitHub: commits, merged PRs, open PRs, issue activity (via gh CLI or GitHub MCP in cloud runs)
• Focus: last 24h window, grouped by area (website, DCS, SDK, infra, docs)
• Local git: git log, git show, git diff, branch status, and test/config changes
• CI: failing checks, skipped checks, deploy state, or review comments when available
• Wiki: existing project page so the briefing updates compiled truth instead of restating known context

Output format

• Shipped : merges and notable commits with one-line impact
• In flight : open PRs needing review or blocked
• Risk : failing checks, large diffs, or areas with no activity when expected
• Optional wiki touch: related project pages if a ship changes compiled truth

Cloud runner uses GitHub MCP; local runner uses gh against the linked repo.

Wiki update rule

A briefing is ephemeral unless it changes durable project truth. Update the project page when the run reveals:

• a launch, demo, customer/event milestone, or production incident
• architecture or stack change
• ownership change
• metric that changes project status
• repeated failure mode that should become a postmortem, workflow, or style rule

Otherwise write the briefing output to outputs/<date>/project-briefing/ and append only a concise log entry if Kevin needs a record.

Quality bar

Good briefings are short but not shallow. They explain impact, not just commit titles. Prefer "billing ledger now records expiring grants before wallet debits" over "update billing." Link PRs/commits when available. Call out uncertainty directly when the evidence is incomplete.

Validation

A complete briefing names the repo, time window, sources queried, and evidence gaps. If GitHub/CI access fails, do not fill the missing section from memory. If a briefing changes a project page, run Build Index Workflow and QMD Embed Workflow before closing.

Run Contract

This workflow follows Wiki Brain Operating Model: name the sources, write output or no-op proof, promote only durable facts, update state only when the run really completed, refresh generated surfaces when durable pages or skills change, and log user-visible work.

---

Timeline

• 2026-11-03 | Retired the scheduled project-briefing automation, last run 2026-07-03; the workflow runs on request. Source: Kevin approval, 2026-11-03
• 2026-07-01 | Added trigger boundaries and validation expectations so project briefings stay scoped to repo evidence and refresh generated surfaces when they promote durable project truth. private page
• 2026-06-18 | Added scope-resolution order, local/CI/wiki data sources, wiki-update rule, and quality bar so briefings do not depend on stale default repo paths. private page
• 2026-05-31 | Workflow page created from project-briefing automation. Source: automations/project-briefing.md, 2026-05-31