Create implementation phase PRDs from pre-existing research for the telemetry agent. Translates already-complete research into focused, bounded PRDs. Use when the user says "prd-phase N" or wants to create a PRD for a specific build phase (1-7). Do NOT use for new feature discovery — use prd-create for that.
Create implementation phase PRDs for the telemetry agent by assembling content from existing research documents. All research is complete. The job is to route to the right documents, extract the right details, and produce a focused PRD.
"type": "module"erasableSyntaxOnlyimportallowJs: trueParse the phase number (1-7) from the user's command.
Read the specific phase section from docs/specs/research/implementation-phasing.md. Each phase contains:
Also read these cross-cutting sections (they apply to every phase):
Skip this step for Phase 1 — it has no predecessor.
For Phase 2+, read the previous phase's PRD file (prds/[id]-phase-[N-1]-*.md). Focus on:
docs/architecture/design-document.md defines for the Phase N-1 → Phase N boundaryInclude deviations in the new PRD's Dependencies section as:
Phase N-1 delivered [interface/type] (with these modifications from plan: [list changes]).
If the previous phase's decision log and design document agree (no deviations), note: "Phase N-1 delivered interfaces as planned in the design document."
Read ONLY the sections relevant to this phase.
The phase definition contains a "Spec Sections" table. For each row:
docs/specs/telemetry-agent-spec-v3.9.mdNote: The spec was renamed from v3.5.md → v3.6.md → v3.7.md → v3.8.md → v3.9.md as content versions evolved.
Spec section landmarks (line numbers for the 1,791-line spec):
| Section | Line | Key Subsections |
|---|---|---|
| Architecture | 55 | Coordinator+Agents 57, Coordinator API 130, Error Handling 160, Interfaces 193, Tech Stack 220, Weaver Integration 253 |
| Init Phase (Required) | 290 | What Init Does 294, Prerequisites 324 |
| Complete Workflow | 334 | (diagram through ~397) |
| How It Works | 397 | Input 399, Processing (per file) 404, Output 420, Agent Output Format 424, System Prompt Structure 438, Known Failure Modes 468, Elision Detection 484 |
| File/Directory Processing | 494 | File Revert Protocol 506, Periodic Schema Checkpoints 512 |
| What Gets Instrumented | 528 | Priority Hierarchy 530, Review Sensitivity 543, Patterns Not Covered 560 |
| What the Agent Actually Does to Code | 573 | Path 1: Auto-Instrumentation 577, Path 2: Manual Span 647, Decision: Which Path? 711 |
| Attribute Priority Chain | 721 | Schema Extension Guardrails 731 |
| Auto-Instrumentation Libraries | 745 | Why Libraries First 749, Detection Flow 755, Library Discovery 774 |
| Validation Chain | 874 | Per-File Validation (with fix loop) 878, End-of-Run Validation 983 |
| Agent Self-Instrumentation | 1020 | |
| Handling Existing Instrumentation | 1079 | |
| Schema as Source of Truth | 1097 | |
| Result Data | 1106 | Result Structure 1116, Run-Level Result 1211, PR Summary 1241, Schema Hash Tracking 1255 |
| Configuration | 1261 | What Goes Where 1312, Dependency Strategy 1352, Cost Visibility 1367 |
| Minimum Viable Schema Example | 1381 | |
| PoC Scope | 1577 | In Scope 1579, Out of Scope 1626 |
| Evaluation & Acceptance Criteria | 1642 | Two-Tier Validation Architecture 1676, Required Verification Levels 1710 |
Read references/tech-stack-by-phase.md (bundled with this skill) to find which sections of docs/architecture/tech-stack-evaluation.md to read for this phase. Extract:
The phase definition lists rubric rule IDs (e.g., NDS-001, CDQ-003). Look up each rule's full definition in research/evaluation-rubric.md. The code-level rules are in Part 2: Code-Level Evaluation (line 136), organized as:
| Dimension | Location | Rules |
|---|---|---|
| Gate Checks | ~line 140 | NDS-001, NDS-002, NDS-003, API-001 |
| Non-Destructiveness | ~line 189 | NDS-004, NDS-005 |
| Coverage | ~line 218 | COV-001 through COV-006 |
| Restraint | ~line 282 | RST-001 through RST-005 |
| API-Only Dependency | ~line 337 | API-002, API-003, API-004 |
| Schema Fidelity | ~line 374 | SCH-001 through SCH-004 |
| Code Quality | ~line 422 | CDQ-001 through CDQ-008 |
For each rule, extract: Rule ID, name, impact level, evaluation scope, full description including evaluation method, and automation classification (summary at ~line 514).
For Phase 2+, classify rules as Tier 1 (structural/blocking) vs Tier 2 (semantic/blocking or advisory) using the "Two-Tier Validation Architecture" section of implementation-phasing.md.
Read relevant sections of docs/architecture/recommendations.md:
Read relevant sections of docs/architecture/design-document.md. This document defines cross-phase interface contracts, module organization, and a consolidated decision register.
All phases — read these sections:
Phase-specific interface contracts:
| Phase | Section | Line | Key Types/Contracts |
|---|---|---|---|
| 1 | Phase 1 → Phase 2: Instrumentation Output | 29 | instrumentFile interface, InstrumentationOutput type |
| 2 | Phase 2 → Phase 3: Validation Results | 84 | validateFile interface, ValidationResult/CheckResult types, ValidateFileInput |
| 3 | Phase 3 → Phase 4: File-Level Result | 151 | instrumentWithRetry interface, FileResult evolution, schema re-resolution |
| 4 | Phase 4 → Phase 5/6: Run-Level Result | 211 | coordinate interface, RunResult type, CoordinatorCallbacks |
| 5 | Phase 5: Schema Integration Extensions | 254 | Schema integration extensions to RunResult |
| 6 | Phase 6: Interface Layer | 262 | CostCeiling, CoordinatorCallbacks (wiring focus) |
| 7 | Phase 7: Deliverables | 290 | RunResult consumption for git/PR, advisoryAnnotations flow |
Also read the Interface Contract Summary table (line 294) for a quick reference of all contracts.
Extract from the design document into the PRD:
Read references/phase-prd-template.md (bundled with this skill) for the output template.
Fill in each section using content gathered in Steps 2-3. Key rules:
Tech Stack section:
Rubric Rules section:
Acceptance Gate section:
Milestones:
Spec Reference section:
Follow the same workflow as /prd-create:
Create GitHub Issue with label "PRD":
## PRD: Phase N — [Phase Name]
**Problem**: Implementation phase N of the telemetry agent — [what gets built]
**Solution**: [1-2 sentence summary from phasing document]
**Detailed PRD**: Will be added after PRD file creation
**Priority**: High
Create PRD file at prds/[issue-id]-phase-N-[phase-name].md
Update GitHub Issue with PRD link
Commit with [skip ci] flag:
docs(prd-[issue-id]): create Phase N PRD — [phase-name] [skip ci]
Before presenting the PRD to the user, verify:
| Document | Path | Purpose |
|---|---|---|
| Implementation Phasing | docs/specs/research/implementation-phasing.md | Phase definitions, spec section maps, cross-cutting architecture |
| Telemetry Agent Spec | docs/specs/telemetry-agent-spec-v3.9.md | Source of truth for what to build |
| Tech Stack Evaluation | docs/architecture/tech-stack-evaluation.md | Version numbers, API patterns, library choices |
| Evaluation Rubric | research/evaluation-rubric.md | Full rule definitions for acceptance criteria |
| Architectural Recommendations | docs/architecture/recommendations.md | Preserve/change verdicts, evidence base |
| Design Document | docs/architecture/design-document.md | Interface contracts, module organization, decision register |
| Tech Stack by Phase | references/tech-stack-by-phase.md (skill-bundled) | Routing table: which tech stack sections per phase |
| Phase PRD Template | references/phase-prd-template.md (skill-bundled) | Output template |
erasableSyntaxOnly). ts-morph handles JavaScript target files via allowJs: true. Agent code samples use TypeScript; target file examples remain JavaScript.Note: If any gh command fails with "command not found", inform the user that GitHub CLI is required: https://cli.github.com/