The companion to the weekly-status walkthrough — but this time we build the whole PM bench. Set up your context once, then watch the same Frames and Cogs get reused across six recurring rituals. Each ritual starts where you are today and ends at a functional, human-gated Op, with the prompt you paste and the file it produces.
Built on the tools you already live in — GitHub & GitHub Projects, Slack, Google Drive, Notion (and Gemini, where your notes land). No Intelligence Hub required; this runs today on Claude Code. The payoff isn't six scripts — it's seeing how Frames are inherited, where Cogs are reused, and how every Op stops at your gate.
atlas/ ← one git repo = the context home for every Op ├── CLAUDE.md ← imports the Frames (auto-loaded every session) ├── .mcp.json ← GitHub · Slack · Drive · Notion connectors ├── frames/ ← FRAMES · built once, inherited by all six Ops │ ├── company.frame.md parent (inherited) │ ├── pmo-standards.frame.md how we run programs here │ ├── atlas-program.frame.md your program: goals, terms, sources │ ├── audience-profiles.frame.md exec / team / external │ └── compliance.frame.md policy, attached by Legal ├── .claude/agents/ ← COGS · briefed, tool-fenced workers │ ├── status-report.md risk-triage.md transcript-miner.md │ ├── kickoff-builder.md audience-writer.md │ └── capacity-analyst.md retro-synth.md ├── .claude/commands/ ← OPS · orchestration + your gate │ ├── weekly-status.md project-kickoff.md stakeholder-update.md │ └── risk-review.md capacity-check.md retro-synthesis.md └── status/ kickoffs/ retros/ … ← drafted outputs (git history = your memory)
Seven Cogs, six Ops, five Frames — but you only author the context once. The reuse is the whole point; the lineage explorer at the bottom lets you trace exactly what inherits from what.
Before any single ritual, you do two things that the other six all stand on: connect your tools, and write the context Frames. Do these well and each Op below is mostly assembly.
Claude Code reaches your tools through MCP servers. Add one connector per source, each with a read-only token — least-privilege scoping is your governance layer today. Set up once, shared by every Cog in the repo.
# GitHub — PRs, issues, AND Projects v2 boards (one read-only PAT covers all three)
$ claude mcp add --transport http github https://api.githubcopilot.com/mcp/ \
--header "Authorization: Bearer $GITHUB_TOKEN"
# Slack — project channels & async updates (bot token, channels:history scope)
$ claude mcp add slack --env SLACK_BOT_TOKEN=$SLACK_BOT_TOKEN \
-- npx -y @modelcontextprotocol/server-slack
# Google Drive — meeting transcripts, recordings' transcripts, and docs (read-only)
$ claude mcp add gdrive -- npx -y @modelcontextprotocol/server-gdrive
# Notion — project pages & notes (hosted connector, read access)
$ claude mcp add --transport http notion https://mcp.notion.com/mcp
$ claude mcp list # confirm all four are connectedA Frame is a versioned markdown file that captures context. The fastest first draft is to have Claude Code read what you already produce. Write three that nest — a PMO standard, your program Frame (which extends it), and a compliance policy — plus the company Frame you already have.
Review, fix anything wrong, and you've got the program Frame — note the Sources map pointing at your real tools, and the two places it overrides the PMO standard:
scope: program
name: Project Atlas
version: 0.1.0
extends: frame://acme/pmo/standards # PMO lineage -> Acme Company
---
## Goals
Migrate billing to the new platform by Dec 15 with zero customer-facing downtime.
## Workstreams
- platform — owner: Lena (the migration itself)
- data — owner: Omar (backfill + reconciliation)
- frontend — owner: Priya (checkout UI)
## Terminology
"Slip" = a milestone moved more than 3 business days.
RAG: green = on track; amber = at-risk with a recovery plan; red = blocked or slipped, needs a decision. # overrides the PMO default
## Norms
Blockers escalate same-day — never held for the readout. # overrides PMO "within one business day"
## Sources
- platform: github://acme/billing-svc · project:Atlas/Status · slack://atlas-eng · drive://Atlas/Transcripts · notion://Atlas/Platform
- data: github://acme/billing-data · project:Atlas/Status · slack://atlas-data · drive://Atlas/Transcripts · notion://Atlas/Data
- frontend: github://acme/checkout-ui · project:Atlas/Status · slack://atlas-product · drive://Atlas/Transcripts · notion://Atlas/FrontendAdd the compliance policy as its own file (it hangs off Legal, not the PMO chain) and wire all of it into CLAUDE.md so every session is pre-oriented:
# CLAUDE.md — auto-loaded into every Claude Code session in this repo
@frames/company.frame.md
@frames/pmo-standards.frame.md
@frames/atlas-program.frame.md
@frames/compliance.frame.md$ git add frames CLAUDE.md && git commit -m "frames: PMO + Atlas + compliance v0.1.0" # git history = audit trailEach ritual follows the same arc: where you are today, what it inherits or reuses vs. what's new, the prompt to paste, the file produced, and the functional result. Watch how little is new each time — that's inheritance and reuse doing the work.
Frame: nothing new — the Op inherits everything it needs from the Atlas program Frame you wrote in Part 1 (the RAG criteria, the status format, the Sources map). On to the Cogs.
Cog 1 · status-report — a subagent that gathers signal and assigns RAG. Its tools: allowlist is the governance fence; "draft only" is baked into the prompt.
---
name: status-report
description: Drafts the weekly RAG status for Project Atlas from GitHub, Projects, Slack, Drive transcripts, and Notion. Use for the weekly status only.
tools: Read, Write, mcp__github__list_pull_requests, mcp__github__list_issues, mcp__github__list_project_items, mcp__slack__conversations_history, mcp__gdrive__search, mcp__gdrive__read_file, mcp__notion__search
model: sonnet
---
You are the Status-Report Cog for Project Atlas, oriented by atlas-program.frame.md —
follow its vocabulary, RAG criteria, and status format exactly. Window: last 7 days.
For each workstream in the frame's Sources map:
1. GitHub: merged PRs, open PRs, issues opened/closed in the window.
2. Projects: items whose status changed; flag any item past its target date.
3. Slack: scan the workstream channel for async updates and "blocked".
4. Drive: open the most recent transcript; extract decisions and risks.
5. Notion: read the workstream's notes page for context.
Assign RAG per workstream per the frame's criteria. Surface the top-3 risks + decisions.
Rules:
- DRAFT ONLY. Never post to Slack, Notion, or Drive. Write only under status/.
- Cite evidence for every RAG call (PR #, message link, transcript line).
- If a workstream has no signal, mark it "no-signal" — never invent status.Cog 2 · risk-triage — smaller; it only reasons over the risks the first Cog surfaces, and it inherits the compliance Frame too, so policy gates the scoring. Remember this one — risk-review reuses it later.
---
name: risk-triage
description: Scores, de-dupes, and assigns owners to Project Atlas risks. Invoked by the weekly-status and risk-review Ops.
tools: Read, mcp__github__list_issues, mcp__github__list_project_items
model: sonnet
---
You are the Risk-Triage Cog for Project Atlas, oriented by atlas-program.frame.md and
compliance.frame.md. Given candidate risks, you:
- merge duplicates and phrase each as "risk -> impact -> next step"
- score severity (high / med / low) using the frame's "slip" and "blocked" definitions
- assign an owner from the workstream's owner in the frame
- output the top-3 by severity
You are read-only: you never modify issues or post anywhere.Op · the workflow + your gate. A slash command runs both Cogs, composes their output into your format, writes a draft, and stops.
---
description: Draft this week's Project Atlas status for review (no publish)
allowed-tools: Read, Write, Task
---
Compose the Project Atlas weekly status for the window: the last 7 days ending today.
1. Use the status-report subagent to gather signal and produce RAG-per-workstream.
2. Use the risk-triage subagent to score, de-dupe, and assign owners to the risks.
3. Merge into the format defined in atlas-program.frame.md.
4. Write the result to status/$(date +%G-W%V).md as a DRAFT.
5. Print a 3-line summary, then STOP. Do not post to Slack, Notion, or Drive.Result. Run /weekly-status and it drops this into status/ for your Monday review — your format, evidence behind every call:
# Project Atlas — Weekly Status · 2026-W39
## RAG by workstream
- platform GREEN — on track. billing-svc cutover PR #482 merged; staging green (transcript 09-21).
- data AMBER — at-risk. backfill 2 days behind; recovery plan posted in slack://atlas-data (Omar).
- frontend RED — blocked. checkout-ui waiting on the data contract; decision needed.
## Top-3 risks
1. [HIGH] Data contract unresolved blocks frontend -> owner Omar -> lock schema by Wed
2. [MED] Backfill slip threatens the Dec 15 milestone -> owner Omar -> add a second runner
3. [MED] Load test not yet scheduled -> owner Lena -> book a window this week
## Decisions needed
- Approve the schema freeze for the billing data contract — frontend is blocked on it.Want it before standup? 0 9 * * 1 cd ~/atlas && claude -p "/weekly-status" >> logs/status.log 2>&1 — the gate never moves, because the Op only ever writes the file.
---
description: Draft a new-project skeleton from an approved charter (no creation)
allowed-tools: Read, Write, Task
argument-hint:
---
From the charter at $1:
1. Use the kickoff-builder subagent to draft RACI, milestone skeleton, and risk log.
2. Have it PROPOSE the GitHub Projects epics, Slack channels, and Drive folder layout.
3. Write everything to kickoffs// as DRAFTS.
4. Print the proposed board/channel/folder checklist, then STOP. Create nothing. # Project Borealis — RACI (draft from charter, PMO template)
| Deliverable | Accountable | Responsible | Consulted | Informed |
| Data model sign-off | Omar | Omar, Lena | Legal | Sponsor |
| Migration runbook | Lena | platform | SRE | PM |
# Proposed (NOT created — confirm before I make these):
# Projects epics: Data Model · Migration · Cutover
# Slack: #borealis-eng #borealis-data Drive: /Borealis/TranscriptsNew Frame. The audience profiles hang off a Comms branch, not the PMO chain — proof a worker can compose two lineages at once.
scope: team
name: Audience Profiles
version: 1.0.0
extends: frame://acme/comms/standards # Comms lineage, not PMO
---
## exec Terse — outcomes, risks, asks only. No implementation detail.
## team Full detail with owners and dates.
## external Redact roadmap dates and confidential lines before sending.exec.md → "Atlas on track for Dec 15. One red: frontend blocked on a data
contract — need a schema-freeze decision this week."
team.md → full RAG table + owners + the three risks with next steps.
external.md → progress narrative, NO dates, NO internal owner names. # redacted by complianceNew Cog · transcript-miner — pulls candidate risks out of Drive transcripts (and Gemini notes saved to Drive/Notion). It feeds the existing risk-triage Cog. It gets reused again in ritual 6.
---
name: transcript-miner
description: Extracts decisions, risks, and action items from Drive meeting transcripts (incl. Gemini notes saved to Drive/Notion). Used by risk-review and retro-synthesis.
tools: Read, mcp__gdrive__search, mcp__gdrive__read_file, mcp__notion__search
model: sonnet
---
You are the Transcript-Miner Cog for Project Atlas. Given a date window, find the
relevant transcripts/notes and extract: decisions (with who decided), risks (phrased
as risk -> impact), and action items (owner + date if stated). Quote verbatim with a
timestamp or line reference so nothing is misattributed. Read-only; you never post.---
description: Refresh the Atlas risk register for the steering meeting (no writes to the board)
allowed-tools: Read, Write, Task
---
1. Use transcript-miner to surface candidate risks from transcripts + notes since last review.
2. Add open GitHub issues / Projects items labeled "risk".
3. Use the risk-triage subagent (REUSED) to score, de-dupe, and assign owners.
4. Diff against risks/register.md; mark NEW, CHANGED, and STALE entries.
5. Write risks/review-.md as a DRAFT and STOP. I re-score at the meeting. # Capacity flags · 2026-W39
- OVER-ALLOCATED: Omar is on the data backfill AND the schema freeze, both due this week.
Proposal: move the load-test prep (Lena) earlier; pull a second runner onto backfill.
- CONTENTION: platform + data both need the staging env Wed-Thu. Decision needed.# Atlas Retro · 2026-09-30
## Went well Cutover rehearsal caught the data-contract gap early (transcript 11:40).
## Went poorly Backfill estimate was 2x optimistic — no buffer for reconciliation.
## Actions [Omar] add reconciliation buffer to all future estimates (by next kickoff)
# Proposed append to frames/atlas-program.frame.md (0.1.0 -> 0.2.0):
+ ## Lessons
+ Estimate data backfills with a reconciliation buffer; the naive estimate runs ~2x short.Approve the diff and commit — now atlas-program.frame.md is at 0.2.0, and the next project-kickoff inherits the lesson automatically. The loop is closed.
This is the whole point of building once and reusing. Pick any Cog or Op below: its inheritance path lights up across the Frame graph, and the panel underneath resolves the merged context it's oriented by — every section, which Frame it came from, and where a more-specific Frame overrode a less-specific one. Compare /project-kickoff (pure inheritance, no overrides) with /weekly-status (the program Frame overrides two company/PMO defaults).
That's the lesson. The expensive, drift-prone part — your vocabulary, RAG criteria, status format, sources, and policy — lives in a handful of Frames written in Part 1. After that, each ritual is mostly assembly, and the most valuable Cogs get reused across several Ops.
| Built once | Reused by | Why it matters |
|---|---|---|
| atlas-program.frame | All six Ops (via CLAUDE.md) | One definition of "RAG", "slip", and the sources map — no drift. |
| risk-triage Cog | weekly-status · risk-review | Scoring logic written once, applied identically in two ceremonies. |
| transcript-miner Cog | risk-review · retro-synthesis | Transcript/notes extraction shared across rituals. |
| status-report Cog | weekly-status · stakeholder-update | The week's facts assembled once, retargeted per audience. |
| compliance.frame | weekly-status · stakeholder-update · risk-review | Policy attaches to whatever touches it — redaction, retention, checkpoints. |
These artifacts port cleanly: the Frame files become real Frames, the subagents become Cogs, the slash commands become installable Ops, and your git history becomes Organizational Memory. Same shapes — more governance and reproducibility around them.
Sensible next steps:
frames/you.frame.md) for your own preferences — terser output, how you like risks grouped — and import it in CLAUDE.md.New here? Start with the concepts, see the single-Op Build Guide, or browse the cross-functional use-case gallery →