Project Briefing Workflow

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

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

Trigger

Run daily, 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 configured by the automation run. Do not assume a legacy local path if the workspace has a current checkout. Resolve in this order:

Explicit project/repo in Kevin's request.
Automation target_repo or run config.
Current working tree if the agent is already inside a project.
Known local checkout under ~/Documents/GitHub/.
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 Workflow Run Contract: 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-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. Source: User request, 2026-07-01
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. Source: User request, 2026-06-18
2026-05-31 | Workflow page created from project-briefing automation. Source: automations/project-briefing.md, 2026-05-31

Source: automations/project-briefing.md, 2026-05-31

Source: User request, 2026-07-01