PRDs & Project Context

Create product requirements and project context that humans and coding assistants can execute effectively.

Two capabilities:

1. PRDs & Specs – Requirements, specs, stories, acceptance criteria
2. Project Context – Architecture, conventions, tribal knowledge (CLAUDE.md)

Modern Best Practices (Jan 2026): Context engineering (right info, right format, right time), decision-first docs, testable requirements with acceptance criteria, metrics with formula + timeframe + data source, cross-tool portability.

Workflow (Use This Order)

1. Pick the deliverable (PRD, AI PRD, tech spec, story map, CLAUDE.md).
2. Gather inputs (problem evidence, users, constraints, dependencies, risks).
3. Fill the template (write decisions first; keep requirements testable).
4. Validate with checklists (requirements, edge cases, security/compliance as needed).
5. Hand off with next actions (implementation plan, owners, open questions).

Quick Reference

PRDs & Specs

Project Context (CLAUDE.md)

Decision Tree

User needs:
    ├─► AI-Assisted Coding?
    │   ├─ Non-trivial (>3 files)? → Planning checklist + agentic session
    │   └─ Simple (<3 files)? → Direct implementation
    │
    ├─► Project Onboarding?
    │   ├─ New to codebase? → Generate CLAUDE.md
    │   └─ Quick context? → Minimal CLAUDE.md
    │
    └─► Traditional PRD?
        ├─ Product requirements? → PRD template
        ├─ AI feature? → AI PRD template
        └─ Acceptance criteria? → Gherkin/BDD

Cross-Tool Context Files

CLAUDE.md / AGENTS.md Guidance

• Start minimal: assets/minimal-claudemd.md
• Add only what’s needed: assets/architecture-context.md, assets/conventions-context.md, assets/key-files-context.md, assets/dependencies-context.md, assets/tribal-knowledge-context.md
• Keep it executable: commands must run; include no secrets; prefer file paths over pasted code

Do / Avoid

Do

• Start with executive summary (decision, users, scope, success)
• Define acceptance criteria in testable language
• Keep requirements unambiguous (must/should/may)
• Link to supporting docs instead of pasting

Avoid

• Vague requirements (“fast”, “easy”) without definitions
• Mixing draft notes and final requirements
• Metrics without measurement plan
• Docs with no owner or review cadence

Context Extraction

Use:

• references/architecture-extraction.md for components/data flows
• references/convention-mining.md for naming/patterns
• references/tribal-knowledge-recovery.md for git-history “why”
• references/docs-audit-commands.md for audit commands and tool fallbacks

Quality Checklist

PRD Quality

• Clear problem statement
• Measurable success criteria
• Unambiguous acceptance criteria
• Edge cases documented
• AI can execute without clarification

CLAUDE.md Quality

• Architecture reflects actual structure
• Key files exist at listed locations
• Conventions match actual patterns
• Commands actually work
• No sensitive information

Resources

Templates

Related Skills