Prd
- 19 installs
- 22 repo stars
- Updated May 28, 2026
- acedergren/agentic-tools
prd is a Claude Code skill that produces drift-proof Product Requirements Documents through codebase-aware interactive discovery.
About
prd is a Claude Code skill for creating, updating, validating, and phasing a Product Requirements Document. It runs interactive discovery, scans the codebase before asking questions, and writes a living PRD with Given/When/Then acceptance criteria and a phasing DAG. A developer uses it when planning a feature and needing requirements that will not drift from the real architecture. It bundles a template, validation checklist, drift-prevention rules, and phase-listing scripts.
- Drives interactive discovery to produce a drift-proof Product Requirements Document
- Scans the codebase first, then asks max 4 questions per round before drafting
- Builds a phasing DAG and can emit an orchestrate-ready task plan via --to-plan
Prd by the numbers
- 19 all-time installs (skills.sh)
- Ranked #2,032 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Jul 28, 2026 (Skillselion catalog sync)
prd capabilities & compatibility
- Capabilities
- prd generation · requirements discovery · phasing · spec validation
- Use cases
- planning · project management · documentation
- Pricing
- Free
What prd says it does
Produce drift-proof Product Requirements Documents through iterative discovery.
Never generate a PRD without scanning the codebase first
npx skills add https://github.com/acedergren/agentic-tools --skill prdAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 19 |
|---|---|
| repo stars | ★ 22 |
| Last updated | May 28, 2026 |
| Repository | acedergren/agentic-tools ↗ |
What it does
Create, update, validate, or phase a drift-proof Product Requirements Document through interactive discovery.
Who is it for?
Producing, updating, validating, or phasing a full PRD with testable acceptance criteria and a phasing DAG.
Skip if: Lightweight notes or issues, code reviews, or when a final spec exists and only implementation planning is needed.
When should I use this skill?
Creating, updating, validating, or phasing a PRD.
What you get
A living PRD at .claude/reference/PRD.md with testable criteria, architecture decisions, and a valid phasing DAG.
- PRD.md requirements document
- phasing DAG
- orchestrate-ready task plan
By the numbers
- Max 4 discovery questions per round
- 2 to 4 discovery rounds
- Four-wave phasing model (foundation to polish)
Files
PRD Skill
Produce drift-proof Product Requirements Documents through iterative discovery.
Output: .claude/reference/PRD.md (living requirements document for the project).
Do NOT load when
- user has a final spec and only wants implementation planning (use
/orchestrateor/prd --to-plan) - task is a code review or repo health check
- request is a lightweight note or issue, not a full requirements document
NEVER
- Never generate a PRD without scanning the codebase first — requirements that contradict existing architecture produce unimplementable specs
- Never write acceptance criteria as "should work correctly" — use Given/When/Then; untestable criteria cannot be verified at phase completion
- Never skip dependency analysis — untracked dependencies produce phases that can't be parallelized safely
- Never batch all discovery questions into one wall of text — max 4 questions per round; users disengage from interrogations
- Never assume a library version — check
package.jsonand npm; version assumptions produce broken phase plans - Never write phasing without dependency arrows — phases must be a DAG; implicit ordering creates unmergeable parallel work
- Never leave `[NEEDS CLARIFICATION]` markers in a finalized PRD — they signal a spec that cannot drive implementation
Mode routing
| Argument | Mode | Description |
|---|---|---|
| _(empty)_ | Create | Interactive PRD creation from scratch |
<feature text> | Create | Start with context, then iterate |
--update | Update | Incremental update to existing PRD |
--validate | Validate | Run validation checklist on existing PRD |
--audit-deps | Audit | Dependency/drift analysis only |
--to-plan | Plan | Generate orchestrate-ready task plan |
Create mode
Phase 1 — Codebase scan (automatic, before any questions)
Launch an Explore agent to map relevant codebase areas. Read roadmap/changelog for prior decisions. Check for outdated dependencies in scope. This prevents asking questions the codebase already answers.
Phase 2 — Interactive discovery (2–4 rounds, max 4 questions each)
- Round 1: Problem, who, success criteria, personas
- Round 2: MoSCoW priorities, explicit out-of-scope, interactions
- Round 3: Architecture constraints, database, auth, performance
- Round 4 (if needed): Phasing, parallelization risks
Never draft before Round 2. Never ask what the codebase scan already answered.
Phase 3 — Draft
Read template.md. Write to .claude/reference/PRD.md. Mark gaps [NEEDS CLARIFICATION: ...]. Populate Architecture Decisions (AD-N entries). Build phasing DAG with explicit arrows.
Phase 4 — Validation
Read validation.md, run every check. Present pass/fail. Iterate until critical gates pass.
Phase 5 — Finalize
Remove all markers. Commit: docs(prd): add <feature-name> requirements.
Update mode (--update)
1. Read existing PRD 2. Ask what changed (new requirement, scope change, dependency update) 3. Launch Explore agent to detect codebase drift since last PRD update 4. Generate diff-style updates: [ADDED], [CHANGED], [REMOVED], [DRIFT DETECTED] 5. Present for approval, apply, re-validate
Plan mode (--to-plan)
Transforms PRD phasing into an /orchestrate-ready task plan at docs/plans/<feature-name>-plan.md.
Wave assignment rules:
- Wave 1: Schemas, types, migrations, config (foundation)
- Wave 2: Routes, services, repositories (implementation)
- Wave 3: Wiring, UI, end-to-end flows (integration)
- Wave 4: Error handling, edge cases, docs (polish)
Agent assignment rules:
haiku: Type definitions, config, simple CRUD, test writingsonnet: Business logic, complex integrations, security-sensitive code
Requires V5 (DAG) validation to pass before generating the plan.
Validate mode (--validate)
Read validation.md and run all gates. Print pass/fail with line references.
Audit-deps mode (--audit-deps)
Read drift-prevention.md and run dependency freshness + architectural drift checks.
Scripts
bash scripts/check-prd-assets.sh skills/prd
node scripts/list-prd-phases.js .claude/reference/PRD.mdArguments
/prd— interactive creation/prd Workflow Designer— start with context/prd --update— incremental update/prd --validate— run validation only/prd --audit-deps— dependency audit only/prd --to-plan— generate orchestrate-ready task plan
Drift Prevention Reference
Loaded during /prd --update and /prd --audit-deps modes.
Dependency Freshness Checks
Commands
# Check all workspaces for outdated packages
pnpm outdated --recursive # or: npm outdated
# Security audit
pnpm audit # or: npm audit
# Check a specific package
npm view <package-name> version deprecatedWhat to Flag
| Severity | Condition | Action |
|---|---|---|
| Critical | Package has known CVE | Upgrade immediately or find alternative |
| Critical | Package is deprecated on npm | Plan migration to replacement |
| High | Major version behind | Evaluate breaking changes |
| Medium | Minor version behind with relevant fixes | Schedule update |
| Low | Patch version behind | Update opportunistically |
New Dependency Evaluation
Before adding a dependency:
1. Last published: >12 months ago? May be abandoned. 2. Open issues: High count with no maintainer response? Risk. 3. License: Compatible with project license? 4. Bundle size: Check bundlephobia.com 5. Alternatives: Lighter or more maintained option? 6. Tree-shaking: ESM support?
Architectural Drift Detection
File Path Verification
Compare PRD-referenced file paths against actual codebase. Verify each "Affected Files" entry still exists.
Pattern Matching
Check PRD architecture decisions align with codebase:
| Decision Area | Check |
|---|---|
| Middleware order | Compare PRD against actual entry point |
| Route structure | Compare PRD routes against routes directory |
| Component hierarchy | Compare PRD against components directory |
| Package exports | Compare PRD against index.ts exports |
Common Drift Indicators
- Orphaned imports: Module imports a symbol no longer exported
- Unused config: Env var referenced in PRD but not in code
- Stale types: Interface in PRD doesn't match actual definition
- Dead routes: Route in PRD has been removed
- Missing migrations: Database change without migration file
Drift Report Format
Dependency Drift Report
=======================
Critical:
[!] package-a v5.0.0 → v6.1.0 available (breaking changes)
High:
[~] package-b v0.4.2 → v0.6.0 available (new API)
Architectural Drift:
[!] PRD references src/routes/foo.ts — file moved to src/routes/foo/index.ts
[~] PRD lists 58 exports — module now has 63 (5 added without PRD update)#!/usr/bin/env bash
set -euo pipefail
ROOT="${1:-skills/prd}"
for file in "$ROOT/SKILL.md" "$ROOT/template.md" "$ROOT/validation.md"; do
if [ -f "$file" ]; then
echo "OK $file"
else
echo "MISS $file"
exit 1
fi
done
if [ -f "$ROOT/drift-prevention.md" ]; then
echo "OK $ROOT/drift-prevention.md"
else
echo "WARN $ROOT/drift-prevention.md"
fi
#!/usr/bin/env node
import { existsSync, readFileSync } from 'node:fs';
import { resolve } from 'node:path';
const file = resolve(process.argv[2] || '.claude/reference/PRD.md');
if (!existsSync(file)) {
console.error(`Missing PRD: ${file}`);
process.exit(1);
}
const text = readFileSync(file, 'utf8');
const lines = text.split('\n');
for (let index = 0; index < lines.length; index += 1) {
const line = lines[index];
if (/^##\s+Phase\s+/i.test(line) || /^###\s+Phase\s+/i.test(line)) {
console.log(`${index + 1}\t${line.replace(/^#+\s*/, '')}`);
}
}
PRD: [Feature Name]
Status: Draft | In Review | Approved | Superseded
Author: [name]
Created: [date]
Last Updated: [date]
---
Validation Checklist
Run /prd --validate to check these gates. All Critical gates must pass before approval.
| # | Gate | Severity | Status |
|---|---|---|---|
| V1 | Every Must-Have has Given/When/Then acceptance criteria | Critical | [ ] |
| V2 | Every Must-Have maps to at least one test file | Critical | [ ] |
| V3 | Architecture Decisions have alternatives evaluated | Critical | [ ] |
| V4 | No deprecated dependencies in scope | Critical | [ ] |
| V5 | Phases form a valid DAG (no circular dependencies) | Critical | [ ] |
| V6 | Success metrics are measurable (number, %, duration) | High | [ ] |
| V7 | All personas referenced in at least one user story | High | [ ] |
| V8 | No [NEEDS CLARIFICATION] markers remain | High | [ ] |
| V9 | Risk mitigations are actionable (not "be careful") | Medium | [ ] |
| V10 | Open Questions section is empty or tracked | Medium | [ ] |
---
1. Product Overview
Vision
[NEEDS CLARIFICATION: What is the long-term vision this feature supports?]
Problem Statement
[NEEDS CLARIFICATION: What specific problem does this solve? Who experiences it and how often?]
Value Proposition
[NEEDS CLARIFICATION: Why is this worth building now? What's the cost of not building it?]
---
2. User Personas
Persona: [Name]
| Attribute | Detail |
|---|---|
| Role | [NEEDS CLARIFICATION] |
| Goal | [NEEDS CLARIFICATION] |
| Pain Point | [NEEDS CLARIFICATION] |
| Tech Comfort | Low / Medium / High |
---
3. User Journey Maps
Journey: [Name] — [Goal]
[Entry Point] → [Step 1] → [Step 2] → [Decision Point]
├── [Happy Path] → [Success State]
└── [Error Path] → [Recovery Action]---
4. Feature Requirements
Must Have (P0)
M1: [Feature Name]
User Story: As a [persona], I want to [action] so that [benefit].
Acceptance Criteria:
Given [precondition]
When [action]
Then [expected result]Affected Files: [path/to/file.ts] Test File: [path/to/feature.test.ts]
Should Have (P1)
S1: [Feature Name]
Could Have (P2)
C1: [Feature Name]
Won't Do (Explicit Exclusions)
- W1: [What and why it's excluded]
---
5. Architecture Decisions
AD-1: [Decision Title]
| Aspect | Detail |
|---|---|
| Context | [What situation requires a decision?] |
| Decision | [What was decided?] |
| Rationale | [Why this option over alternatives?] |
Alternatives Evaluated:
| Option | Pros | Cons | Rejected Because |
|---|---|---|---|
| [Option A] | [pros] | [cons] | [reason] |
| [Chosen] | [pros] | [cons] | Selected |
---
6. Dependency Analysis
Current State
| Package | Current | Latest | Status | Notes |
|---|---|---|---|---|
| [package-name] | [x.y.z] | [a.b.c] | Up to date | [context] |
New Dependencies
| Package | Version | Purpose | License | Size |
|---|---|---|---|---|
| [package-name] | [version] | [why needed] | [license] | [bundle size] |
---
7. Phasing & Dependencies
Phase 1: [Title]
Goal: [One sentence] Prerequisites: None Delivers: M1 Parallelizable with: Nothing (foundation phase)
Phase 2: [Title]
Goal: [One sentence] Prerequisites: Phase 1 complete Delivers: M2, S1
---
8. TDD Protocol
Test File Mapping
| Requirement | Test File | Test Type |
|---|---|---|
| M1 | src/tests/m1.test.ts | Unit + Integration |
---
9. Risks & Mitigations
| # | Risk | Probability | Impact | Mitigation |
|---|---|---|---|---|
| R1 | [specific risk] | Low/Med/High | Low/Med/High | [specific, actionable mitigation] |
---
10. Success Metrics
| Metric | Target | Measurement Method | Timeframe |
|---|---|---|---|
| [Adoption metric] | [number] | [how to measure] | [when] |
---
11. Open Questions
- [ ] [Question 1]
---
12. Changelog
| Date | Change Type | Description |
|---|---|---|
| [date] | Created | Initial PRD |
PRD Validation Checklist
Run each gate against the PRD. Report pass/fail with specific line references for failures.
Critical Gates (must all pass)
V1: Acceptance Criteria Quality
Check: Every Must-Have requirement has acceptance criteria in Given/When/Then format.
Fail indicators:
- Criteria that say "should work correctly" or "should handle errors"
- Missing
Givenprecondition - Missing
Thenassertion - Vague actions in
When
V2: Test File Mapping
Check: Every Must-Have maps to at least one test file path following project conventions.
Fail indicators:
- Missing test file path
- Test type not specified (unit, integration, component)
V3: Architecture Decision Quality
Check: Every AD-N entry has context, 2+ alternatives, rationale, and consequences.
Fail indicators:
- Only one option listed
- "Because it's the best" as rationale
- Missing consequences section
V4: Dependency Health
Check: No deprecated packages in scope. No known CVEs.
V5: Phasing DAG Validity
Check: Phase dependencies form a directed acyclic graph (no cycles).
High Gates (should all pass)
V6: Metric Measurability
Check: Every success metric specifies a number, percentage, or duration.
V7: Persona Coverage
Check: Every persona appears in at least one user story.
V8: Clarification Markers
Check: No [NEEDS CLARIFICATION] markers remain.
Medium Gates (recommended)
V9: Risk Mitigation Quality
Check: Every risk mitigation is actionable (not "be careful").
V10: Open Questions Resolution
Check: Open Questions section is empty or all items are tracked.
Validation Report Format
PRD Validation Report
=====================
Critical Gates:
[PASS] V1: Acceptance Criteria Quality
[FAIL] V2: Test File Mapping — M3 missing test file path (line 87)
[PASS] V3: Architecture Decision Quality
[PASS] V4: Dependency Health
[PASS] V5: Phasing DAG Validity
High Gates:
[PASS] V6: Metric Measurability
[FAIL] V8: Clarification Markers — 2 markers remaining
Result: 2 failures (1 Critical, 1 High) — must fix before approvalRelated skills
Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196kGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k
Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493kLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493kLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493kLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493kFAQ
How does prd avoid requirements that contradict the code?
It launches an Explore agent to scan the codebase before asking any questions, preventing requirements that contradict existing architecture.
How should acceptance criteria be written?
As Given/When/Then statements, never as 'should work correctly', because untestable criteria cannot be verified at phase completion.