The Lifecycle work makes engineering capacity nearly infinite — engineers dispatching 10–15 agents in parallel, 600+ agent runs/day, 10–30× the PR output. The next constraint is the input side: how fast can the 13 product boards generate agent-ready PRDs? Today the flow has 10 stages, 4 skills, 1 automation workflow, and ~10 known stuck-points. This page maps it concretely (with real file refs) and proposes a parallel set of loops to make PRDs as throughput-resistant as code-shipping.
/analyse-system · /write-prd · /assign-prds · /prd-to-planEvery stage has a trigger, an actor (human or agent), an output artifact, and a known stuck-point. This is the source-of-truth for the rest of the page.
Someone notices a feature gap, a customer ask, or a quality issue. They drop a one-liner in Slack, Roam, a GitHub issue, or a 1:1 doc. No centralized inbox — ideas live wherever they were dropped.
triage cron sees some but not all. We need an idea_intake agent that centralizes one-liners daily./analyse-system · research the existing surfaceEngineer runs the skill against a feature slug. Claude reads g8 codebase in 4 phases: backend modules, frontend features, shared infra, existing PRDs. Web-searches competitive context (Apollo · Outreach · Salesloft · Instantly). Outputs an 8-section brief.
/write-prd · draft with GTM scoring + Q&AAfter analysis, engineer runs /write-prd. Skill performs GTM scoring (3 scales: Manual Step Reduction · User Autonomy · Data Pipeline), warns if score < 8, runs 2 rounds of Q&A (scope · technical boundaries), generates the PRD from the template.
Human edits PRD frontmatter: status: approved, sets assignee: <github-username>. No automated approval flow yet. Thomas (Founder) typically does this for Studio/Copilot; Shaharyar for infra/MBM.
/assign-prds · engineer scoring + assignmentReads .claude/engineer-domains.json. Scores each engineer per PRD: +3 primary-domain match · +1 secondary · -5 if overloaded (>3 PRDs). Tiebreakers: lowest git output last month · domain score · capacity. Outputs assignment matrix.
/assign-prds. Should auto-fire on status-change-to-approved./prd-to-plan · PRD → implementation plan + GitHub issuesReads PRD. Analyzes tasks, dependencies, affected files. Explores g8 codebase for patterns. Generates one GitHub issue per task with: Context · Task · Files to modify · Acceptance criteria · Dependencies. Labels: prd + domain + complexity. Updates PRD frontmatter issues: [...] array.
prd-automation.yml · push triggers scriptOn every push to docs/prds/**/*.md: detect changed PRDs · call scripts/prd_workflow.py process <file>. Script reads frontmatter status: draft → validate (lint + headings + placeholders) · approved → create issues + commit PRD updates. Posts sticky PR comment.
Generated issues land with labels: prd + domain tags + surface tags + complexity. The task_planner agent (cron · daily 07:00 UTC) reads unassigned prd-labeled issues, produces a daily assignment digest in Roam for admin approval.
Engineer (or, after Lifecycle, an axon agent) opens a feature branch, implements against the issue acceptance criteria, opens PR with title [PRD] <slug>: <description>. PR links back to issue via Fixes #<number>.
Fixes #, the chain to the PRD breaks. No auto-link-back automation today./check-prds · status update (manual)Engineer or admin runs /check-prds. Lists PRDs by status. For in_progress: checks if all linked issues closed · counts checklist completion · suggests status: done if all green. Flags stale: approved > 7d unplanned · in-progress > 14d inactive.
prd_health cron (daily 05:30 UTC, between agent-health and triage).The same checklist scripts/prd_workflow.py enforces — codified so a human can self-audit before pushing.
title: non-empty, meaningfulstatus: one of draft · approved · in_progress · doneauthor: string (your name)assignee: valid GitHub username · non-null required to plancreated: YYYY-MM-DDapproved: YYYY-MM-DD (set when status changes to approved)domains: list of affected domains · non-emptyissues: empty before planning · populated by automationcomplexity: one of small · medium · largegtm_score: 3–15 · warning if < 8analysis_date: YYYY-MM-DD# {Title}## GTM Automation Assessment## Problem## Analysis Summary · subsections: Existing Code to Reuse · Data Dependencies · Integration Points · Competitive Context## Requirements · subsections: API (Backend) · UI (Frontend) · Data Model## Acceptance Criteria · min 2 items in - [ ] format## Out of Scope · explicit (not "nothing")## Dependencies## Existing Code to Reuse names concrete files (not "TBD")## Data Dependencies names entities and whether they exist or need creation## Integration Points lists other features and explicit API/event contracts## Out of Scope is explicitprd_workflow.py::collect_planning_blockerstask_plannerDiscovered by reading scripts/prd_workflow.py + the 4 PRD skills + a sample of real PRDs in docs/prds/. Numbered for cross-reference with the Loops section below.
Ideas scattered across Slack / Roam / GitHub issues / 1:1 docs. triage cron sees some. Many ideas never make it to /analyse-system.
/analyse-system Q&A is lost if not completedAnalysis lives in conversation context. If the engineer doesn't finish the Q&A in one session, the research evaporates. No "save draft analysis" path.
Approval is a frontmatter edit. No checklist · no audit log · no clear answer to "who's blocking this PRD." Often falls on Thomas alone.
/assign-prds is manualAfter a batch of approvals, admin must remember to run the skill. No auto-trigger on status-change-to-approved.
prd-automation.yml reports blockers serially. Fix "acceptance criteria too thin" → push → hit "assignee missing" → fix → push → repeat. Should batch all blockers in one comment.
Each generated issue has its own acceptance criteria, derived from "what files change." PRD-level acceptance is invisible to the engineer working on issue #3 of 5.
Fixes #No auto-link-back from PR to PRD. If the convention slips, the chain dies — issue stays open after PR merges, status stays in_progress forever.
/check-prds is a manual commandNo scheduled run · no alert. Approved-but-unplanned PRDs and abandoned-in-progress PRDs accumulate silently.
Phase 1 → Phase 2 dependencies live as a comment in the PRD body. If Phase 2 PRD is written first, no automatic warning.
/analyse-system does competitive search at write time. No refresh mechanism. A PRD approved 3 months ago has stale competitive context.
Each loop maps to one of the 10 gaps above. Same shape as the code-shipping loops: a closing question · a mechanism · a first step · effort. All shippable in days or weeks. Ship after the 7-day Lifecycle setup is in place.
idea_intake agent · centralizes one-liner ideas · 7 daysCloses Gap 1. Daily cron sweeps Slack, Roam, and GitHub issues for new feature/bug one-liners. Classifies (feature · bug · question · noise). Drops a single Roam digest at 06:00 with the top 5 unprocessed ideas + a "spawn /analyse-system" button.
idea_inbox Postgres table, posts Roam digest at 06:00 (before triage)./analyse-system output · 1 dayCloses Gap 2. Modify the skill to write the brief to docs/prds/_drafts/<slug>-analysis.md at every Q&A round. Engineer can resume across sessions; no analysis is ever lost.
g8/.claude/commands/analyse-system.md to add a "save draft" step after each Q&A round. Add docs/prds/_drafts/ to .gitignore.Closes Gap 3. New GitHub Action listens for status-change-to-approved commits on docs/prds/**.md. Requires an approved-by: @<handle> trailer in the commit message (enforced). Posts a "PRD approved" Slack message tagging the assignee.
g8/.github/workflows/prd-approval.yml · regex-validates the trailer · auto-tags the assignee./assign-prds on approval · 2 daysCloses Gap 4. The PRD-approval workflow (#3) triggers /assign-prds as a downstream agent run. Result posted as Roam digest for admin one-click confirm. No more "did anyone assign this?" Slack threads.
/assign-prds · result → Roam.Closes Gap 5. Modify scripts/prd_workflow.py::analyze_prd to collect ALL blockers in a single pass and emit one comment with the full checklist. Engineer fixes them all at once, pushes, done.
prd-automation.yml.Closes Gap 6. /prd-to-plan automatically copies the PRD-level acceptance criteria into each generated issue's body (with a "From PRD <slug>" header). Engineer working on issue #3 sees the full PRD acceptance bar.
/prd-to-plan skill prompt to include PRD acceptance criteria verbatim in each issue's body, prefixed with the PRD slug.Closes Gap 7. GitHub Action on PR open: if the PR title contains [PRD] or any linked issue has a prd label, parse the PRD slug from issue body and post a sticky comment "This PR contributes to PRD <slug>". On merge, close the issue and update PRD frontmatter.
g8/.github/workflows/pr-prd-link.yml · parse · comment · on merge: gh issue close + frontmatter update via PR.prd_health daily cron · 3 daysCloses Gap 8. Cron at 05:30 UTC (after agent-health, before triage). Scans all PRDs: flags approved-unplanned > 7d · in-progress > 14d inactive · approved without assignee. Posts daily digest to Roam with the action list. Auto-closes done PRDs whose issues all merged.
tenants/graph8-eng/agents/prd_health/prompt.md · cron entry · reads docs/prds/ frontmatter + GitHub issue status.Closes Gap 9. Add depends_on: [<prd-slug>] to PRD frontmatter. Validator refuses to plan a PRD whose dependencies aren't done. prd_health surfaces the graph in the daily digest with a topological-sort order ("ship in this order").
Closes Gap 10. Weekly cron walks all approved/in_progress PRDs > 30 days old. Re-runs the competitive search portion of /analyse-system. If anything material changed, opens a "PRD context drift" issue tagging the assignee.
Same pattern as the code-shipping lifecycle: every PRD-flow artifact (Roam ping, PR comment, validator error, missing acceptance criterion) is text that should feed back as a prompt. Today most of it doesn't. The 10 loops above are 10 places to wire output → input. Compound intelligence on the PRD side starts there — exactly like it does on the code side.
Today's PRD count is far below what the post-Lifecycle assembly line can consume. This table is the leading indicator we'll watch weekly once the trace ledger is live.
| Product board | Owner | PRDs in docs/prds/ today | Approved-unplanned | Target (PRDs/week) |
|---|---|---|---|---|
| Studio | Usjid · Thomas | (parse on commit) | — | 5–7 |
| Inbox | Hassan | (parse on commit) | — | 4–6 |
| Enrichment | Sadiq | (parse on commit) | — | 3–5 |
| Web Chat | Waleed + Muhammad I. | (parse on commit) | — | 3–5 |
| Copilot | Hamza + Huzaifa | (parse on commit) | — | 3–5 |
| Agents | Huzaifa | (parse on commit) | — | 2–4 |
| Signals | Oleksii | (parse on commit) | — | 2–4 |
| Voice AI | Eeshan | (parse on commit) | — | 2–4 |
| Dialer | Abdullah | (parse on commit) | — | 2–3 |
| Stripe / Credits | Ibrahim + Hassan | (parse on commit) | — | 1–2 |
| Engage / Sequencer | Musa | (parse on commit) | — | 2–3 |
| Mashup | Abdullah + Sadiq | (parse on commit) | — | 1–2 |
| UX / UI | Joaquin | (parse on commit) | — | 2–3 |
| All 13 boards · total | 15 eng + 3 QA | — | — | 33–53 / wk |
Note: "today" counts are placeholders pending a small script that parses docs/prds/*.md frontmatter — first ship of prd_health cron will populate them automatically. Target = what's needed to keep the post-Lifecycle agent fleet (10–15 parallel agents × 15 engineers + overnight runs) fed with concrete work, not just bug fixes.
Run this checklist 14 days after the 7-day Lifecycle setup completes (so total day-21 from now). If 6+ are green, declare PRD-flow shipped and move to the next horizon.
idea_intake livedocs/prds/_drafts/*.md exists; engineers can resume /analyse-system across sessions.approved-by: trailer enforced; assignee auto-tagged in Slack on approval./assign-prds runs needed; admin gets a one-click Roam confirmation digest.prd_health daily cronThe code side (week 1) and the PRD side (weeks 2–3) are both live. Engineering and product can both feed each other at scale. The only remaining bottleneck — and we should celebrate having to ask the question — becomes: what should we build next, that customers actually want? That's an enviable place to be. See the 10 Lifecycle horizons for what comes after.