graph8 lifecycle
PRDs · the new bottleneck
Once engineering throughput is unlocked · PRDs become the bottleneck

From idea to assigned agent in 30 minutes. Agent-ready PRDs at graph8 scale.

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.

Stages today
10
idea → analyse → write → approve → assign → plan → automate → dispatch → ship → close
Skills involved
4
/analyse-system · /write-prd · /assign-prds · /prd-to-plan
Required frontmatter fields
11
title · status · author · assignee · created · approved · domains · issues · complexity · gtm_score · analysis_date
Required headings
13
Problem · Analysis · Requirements · Acceptance · Out of Scope · Dependencies · etc.
Known stuck-points
10
see Gaps section · idea capture · approval RACI · planning blocker hell · etc.
Target after Lifecycle
3–5/board/wk
new approved PRDs per product board per week · feeds the assembly line
1 The 10-stage PRD flow today

How an idea becomes a dispatched agent task. With file refs.

Every 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.

1

Intent capture · idea hits the team

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.

human no formal tool Trigger: human attention
Stuck-point: ideas scattered across 4 surfaces. triage cron sees some but not all. We need an idea_intake agent that centralizes one-liners daily.
2

/analyse-system · research the existing surface

Engineer 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.

claude g8/.claude/commands/analyse-system.md Output: conversation context (not persisted)
Stuck-point: if the Q&A isn't completed, analysis is lost. No "save draft" path. Add a write-the-brief-to-disk step so analysis survives the session.
3

/write-prd · draft with GTM scoring + Q&A

After 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.

claude g8/.claude/commands/write-prd.md Output: docs/prds/<slug>.md
4

Approval · status: draft → approved (manual gate)

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.

human · admin docs/prds/*.md frontmatter Output: PRD with status: approved + assignee
Stuck-point: no RACI · no review checklist · no audit log. A PRD waiting for approval has no clear "who's blocking" answer.
5

/assign-prds · engineer scoring + assignment

Reads .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.

claude infra/.claude/commands/assign-prds.md Output: PRD frontmatter updated with assignee
Stuck-point: manual trigger. After a batch of approvals, admin must remember to run /assign-prds. Should auto-fire on status-change-to-approved.
6

/prd-to-plan · PRD → implementation plan + GitHub issues

Reads 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.

claude infra/.claude/commands/prd-to-plan.md Output: GitHub issues + PRD frontmatter updated
Stuck-point: PRD acceptance criteria are NOT copied into the issues. Engineers sometimes end up with 5 issues that don't quite match the PRD. Need automatic propagation.
7

prd-automation.yml · push triggers script

On 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.

GitHub Actions g8/.github/workflows/prd-automation.yml scripts/prd_workflow.py
Stuck-point: blockers reported one at a time. Fix one → push → next blocker appears. Need grouped feedback.
8

Labels + dispatch · axon agents pick up the issues

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.

task_planner cron tenants/graph8-eng/agents/task_planner/prompt.md Output: Roam briefing message
9

PR generation · engineer (or agent) ships against the issue

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>.

engineer + axon agent after Lifecycle Output: PR linked to issue · joins the code-shipping delivery loop
Stuck-point: if engineer forgets Fixes #, the chain to the PRD breaks. No auto-link-back automation today.
10

/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.

manual command g8/.claude/commands/check-prds.md Output: status report
Stuck-point: no scheduled run. Stale PRDs accumulate unless someone remembers to check. Convert to prd_health cron (daily 05:30 UTC, between agent-health and triage).
2 Agent-ready PRD · the checklist

If your PRD passes these 5 gates, an agent can run it end-to-end.

The same checklist scripts/prd_workflow.py enforces — codified so a human can self-audit before pushing.

Frontmatter · 11 required fields
  • title: non-empty, meaningful
  • status: one of draft · approved · in_progress · done
  • author: string (your name)
  • assignee: valid GitHub username · non-null required to plan
  • created: YYYY-MM-DD
  • approved: YYYY-MM-DD (set when status changes to approved)
  • domains: list of affected domains · non-empty
  • issues: empty before planning · populated by automation
  • complexity: one of small · medium · large
  • gtm_score: 3–15 · warning if < 8
  • analysis_date: YYYY-MM-DD
Required headings · 13 sections
  • # {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
Content quality · 5 gates
  • No template placeholders ("what problem are we solving" · "YYYY-MM-DD" · empty sections)
  • ## 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 explicit
5 gates · in order
  • Draft gate · GTM ≥ 8 (or documented exception) · 2+ acceptance criteria · author + created date set
  • Approval gate · status: approved · assignee non-null
  • Planning gate · all frontmatter present · all headings present · no placeholders · complexity set
  • Issue creation gate · issues array empty · no blockers in prd_workflow.py::collect_planning_blockers
  • Dispatch gate · issues labeled with domains + surfaces + complexity · picked up by task_planner
3 The 10 known stuck-points

Where PRDs get stuck today · each one is a Lifecycle loop to close.

Discovered 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.

Gap 1 · Intent capture

No centralized inbox for one-liner ideas

Ideas scattered across Slack / Roam / GitHub issues / 1:1 docs. triage cron sees some. Many ideas never make it to /analyse-system.

Gap 2 · Analysis paralysis

/analyse-system Q&A is lost if not completed

Analysis lives in conversation context. If the engineer doesn't finish the Q&A in one session, the research evaporates. No "save draft analysis" path.

Gap 3 · Approval RACI

No explicit "who approves what"

Approval is a frontmatter edit. No checklist · no audit log · no clear answer to "who's blocking this PRD." Often falls on Thomas alone.

Gap 4 · Assignment timing

/assign-prds is manual

After a batch of approvals, admin must remember to run the skill. No auto-trigger on status-change-to-approved.

Gap 5 · Planning blocker hell

One error at a time

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.

Gap 6 · Acceptance criteria don't inherit

PRD criteria not copied to issues

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.

Gap 7 · PR → PRD linkage

Breaks if engineer forgets 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.

Gap 8 · Stale PRD detection

/check-prds is a manual command

No scheduled run · no alert. Approved-but-unplanned PRDs and abandoned-in-progress PRDs accumulate silently.

Gap 9 · Multi-PRD coordination

No explicit dependency tracking

Phase 1 → Phase 2 dependencies live as a comment in the PRD body. If Phase 2 PRD is written first, no automatic warning.

Gap 10 · Competitive context locks

Research happens once

/analyse-system does competitive search at write time. No refresh mechanism. A PRD approved 3 months ago has stale competitive context.

4 Loops to close the PRD gaps

Mirror of Lifecycle's horizon — but for PRDs.

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.

1 · idea_intake agent · centralizes one-liner ideas · 7 days

Closes 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.

First step: 7 days · cron at 05:45 UTC reads from the 3 sources, dedupes, writes to a new idea_inbox Postgres table, posts Roam digest at 06:00 (before triage).
Effort
Medium

2 · Persist /analyse-system output · 1 day

Closes 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.

First step: 1 day · edit g8/.claude/commands/analyse-system.md to add a "save draft" step after each Q&A round. Add docs/prds/_drafts/ to .gitignore.
Effort
Small

3 · PRD approval workflow · 3 days

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.

First step: 3 days · workflow g8/.github/workflows/prd-approval.yml · regex-validates the trailer · auto-tags the assignee.
Effort
Small

4 · Auto-run /assign-prds on approval · 2 days

Closes 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.

First step: 2 days · webhook from approval workflow → axon TaskSpawner with skill /assign-prds · result → Roam.
Effort
Small

5 · Batched planning blockers · 2 days

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.

First step: 2 days · refactor the validation loop to non-stop · emit a markdown checklist comment in prd-automation.yml.
Effort
Small

6 · Acceptance-criteria propagation · 3 days

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.

First step: 3 days · edit /prd-to-plan skill prompt to include PRD acceptance criteria verbatim in each issue's body, prefixed with the PRD slug.
Effort
Small

7 · Auto-link PR → PRD · 2 days

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.

First step: 2 days · workflow g8/.github/workflows/pr-prd-link.yml · parse · comment · on merge: gh issue close + frontmatter update via PR.
Effort
Small

8 · prd_health daily cron · 3 days

Closes 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.

First step: 3 days · new agent prompt at tenants/graph8-eng/agents/prd_health/prompt.md · cron entry · reads docs/prds/ frontmatter + GitHub issue status.
Effort
Small

9 · PRD dependency graph · 7 days

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").

First step: 7 days · extend frontmatter schema + validator · add a small graph-rendering helper that outputs Mermaid for the digest.
Effort
Medium

10 · Competitive-context refresh cron · 14 days

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.

First step: 14 days · new agent prompt + cron · scoping: start with PRDs in Studio + Inbox (the most competitive surfaces) and expand from there.
Effort
Medium
The meta-observation

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.

5 Per-product-board PRD throughput

3–5 approved PRDs per board per week · the target after Lifecycle.

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 boardOwnerPRDs in docs/prds/ todayApproved-unplannedTarget (PRDs/week)
StudioUsjid · Thomas(parse on commit)5–7
InboxHassan(parse on commit)4–6
EnrichmentSadiq(parse on commit)3–5
Web ChatWaleed + Muhammad I.(parse on commit)3–5
CopilotHamza + Huzaifa(parse on commit)3–5
AgentsHuzaifa(parse on commit)2–4
SignalsOleksii(parse on commit)2–4
Voice AIEeshan(parse on commit)2–4
DialerAbdullah(parse on commit)2–3
Stripe / CreditsIbrahim + Hassan(parse on commit)1–2
Engage / SequencerMusa(parse on commit)2–3
MashupAbdullah + Sadiq(parse on commit)1–2
UX / UIJoaquin(parse on commit)2–3
All 13 boards · total15 eng + 3 QA33–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.

6 Acceptance · when this is shipped

8 metrics. 6 green = the PRD side keeps up with the code side.

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.

Metric 1
idea_intake live
Daily Roam digest at 06:00 listing the top 5 new ideas from Slack + Roam + GitHub.
Metric 2
Analysis drafts persisted
docs/prds/_drafts/*.md exists; engineers can resume /analyse-system across sessions.
Metric 3
Approval workflow live
approved-by: trailer enforced; assignee auto-tagged in Slack on approval.
Metric 4
Auto-assignment on approval
No manual /assign-prds runs needed; admin gets a one-click Roam confirmation digest.
Metric 5
Batched blocker comments
PRD push with N blockers produces one comment with N items, not N runs of one each.
Metric 6
Acceptance propagation
Every generated issue body includes the PRD-level acceptance criteria header.
Metric 7
prd_health daily cron
Stale PRDs surface in Roam at 05:30 UTC; auto-close on all-issues-merged.
Metric 8
Per-board count ≥ 1/wk
Every product board ships at least 1 approved PRD per week (across all 13). Target ramps to 3–5/board/week over the following 30 days.
After day 21

The 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.

On this page