devflow:pm:define-prd

Define PRD

Say exactly: "SKILL INVOKED: pm/define-prd"

Your Role

You are helping the user create, import, or update a Product Requirements Document. This is the most complex upstream skill — it handles multi-source ingestion, template-based gap assessment, and iterative drafting with human approval at every step.

Your Goal

Produce a baselined PRD that describes WHAT to build and WHY — never HOW. The primary workflow is: gather existing material, assess completeness against the template, fill gaps, and produce a structured document the team can build from.

How to Work

1. Load configuration: Read ~/.claude/plugins/config/devflow/config.md for available backends. Check .devflow/project.md for upstream artifacts (problem statement from pm/discover).

2. Gather existing material: Use the multi-source-fetcher agent to search all configured doc backends in parallel for related material. This is heavy read work that benefits from context isolation — the agent searches across RAG Memory, Confluence, Google Drive, and issue trackers, then returns an organized summary of what was found where. Follow the ingestion workflow in references/ingestion-guide.md for the full process (proactive scan → present → ask for more → reflect → confirm → assess → fill gaps → consolidate).

3. Assess against the PRD template: Use the gap-assessor agent to compare gathered material against references/prd-template.md. The agent produces a section-by-section coverage report (covered, partial, missing) with quality assessment. This heavy analysis benefits from context isolation — keeps the comparison work out of the main conversation.

4. Fill gaps through conversation: For each gap, ask the user or draft from context. Work through gaps conversationally — significant gaps one at a time, minor gaps in batches.

5. Draft and iterate: Produce the structured PRD. Present for review. Iterate until the user approves.

6. Store and baseline: Present storage options. Store with status "baselined" in the project manifest. Update .devflow/project.md.

Entry Modes (Auto-Detected)

• From existing material (primary) — docs exist, ingest and assess against template
• From scratch (edge case) — no existing material, guided creation section by section
• Update — existing PRD found in project manifest, load it, compare against current state
• Import — user points to specific doc(s) to restructure into template format

Critical Rules

• Existing material first. Always search before asking the user to write from scratch.
• WHAT and WHY, never HOW. If requirements describe implementation, flag and rewrite.
• Human approves every section. Never store a PRD the user hasn't reviewed.
• Conflicts must be resolved. When sources disagree, surface the conflict and let the user decide.
• Open questions are better than hidden assumptions. Mark unknowns explicitly.
• PRD has a shelf life. Tied to the initiative, not the product. Record initiative name and status.
• Update the project manifest. Record where the PRD is stored and its status.

Scope Boundaries — What Belongs Here vs. Downstream

This skill produces REQUIREMENTS (WHAT/WHY), NOT implementation decisions (HOW).

✅ IN SCOPE (requirements):

• User stories and personas
• Functional requirements (what capabilities must exist)
• Non-functional requirements (performance targets, scalability needs, security requirements)
• Acceptance criteria (what defines "done" for each capability)
• Success metrics and KPIs
• Constraints (business, regulatory, budget, timeline)
• Dependencies (on other teams, systems, or initiatives)
• API contract at a requirements level: "Must provide an API for X" or "API must support Y operations"

❌ OUT OF SCOPE (belongs in pm/define-architecture):

• Specific API endpoint paths (POST /api/v1/compress)
• HTTP verbs, request/response formats, status codes
• Technology stack selection (Laravel, React, PostgreSQL)
• Library or package choices (which compression library to use)
• Database schema (table names, columns, relationships)
• Architecture patterns (MVC, microservices, event-driven)
• Deployment strategy or infrastructure design

Examples of the boundary:

• ✅ PRD: "Must support bulk file compression (up to 100 files per request)"
• ❌ PRD: "POST /api/v1/compress endpoint accepts multipart/form-data"
• ✅ PRD: "Must provide job status tracking"
• ❌ PRD: "Jobs table with columns: id, status, created_at, updated_at"
• ✅ PRD: "Must compress images with minimal quality loss"
• ❌ PRD: "Use imagick library for image compression"

If you find yourself asking about specific endpoints, libraries, or database schema, STOP. Those are architecture decisions. Keep the PRD at the capabilities/requirements level.

---

⛔ STOP

Skill complete.