prd

Stars3

Forks1

UpdatedJuly 27, 2026 at 14:46

Use for /prd-it or to draft, refine, or review a Product Requirements Document. Not for acceptance criteria, planning, or Pi /goal prompts.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

ilude

ilude/dotfiles

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

SKILL.md

readonly

name	prd
description	Use for /prd-it or to draft, refine, or review a Product Requirements Document. Not for acceptance criteria, planning, or Pi /goal prompts.

PRD Workflow

Boundary

Use prd only for an explicit request to draft, refine, or review a PRD, including /prd-it. A PRD is optional and is not a prerequisite for planning or implementation. Use planning for standalone requirements or acceptance criteria and pi-goal for executable Pi goal prompts.

Core Principle

A PRD records the product decisions needed to align problem, outcome, scope, requirements, and acceptance. Keep it decision-oriented and proportionate to the request.

Artifact Contract

For a new PRD artifact, use pi/skills/workflow/templates/prd-template.md and write .specs/{lowercase-kebab-case-slug}/PRD.md unless the user names another path.
Refine an explicitly supplied PRD in place unless the user requests a new artifact.
Keep Problem, Goals, Non-Goals, context, and rationale as natural narrative.
Treat Requirements and Acceptance Criteria as normative. Load planning and preserve identifiers, defined terms, modal strength, conditions, bounds, and exceptions.
Add users, scenarios, assumptions, risks, dependencies, alternatives, or open questions only when they affect the product decision.
Add /plan-it or /review-it handoffs only when requested.
Ask one concise clarification at a time only when the answer would materially change scope, acceptance, or another product decision. Otherwise draft with explicit assumptions.

Minimal PRD Shape

# PRD: <title>
## Problem
## Goals
## Non-Goals
## Requirements
## Acceptance Criteria

Anti-Patterns

Activating for an incidental mention of a PRD or for every mention of requirements.
Making a PRD mandatory before another workflow.
Expanding a small request into a full product process.
Applying requirement syntax to narrative sections.
Mixing implementation tasks into product requirements unless the implementation is an explicit constraint.
Leaving competing material interpretations hidden in prose.

More from this repository

same repository

pi-extension

ilude/dotfiles

Pi extensions and tool policy: extensions/*.ts, hooks, registerTool, promptGuidelines, registerCommand, footer/status UI, tool_result, session hooks, or subprocesses. Not for slash-command placement; use pi-command.

2026-08-023

docs

ilude/dotfiles

README, CHANGELOG, docs/, RFCs, ADRs, guides, or Markdown structure. Not for prose cleanup or archival work.

2026-07-273

no-ai-slop

ilude/dotfiles

Prose cleanup for filler, hype, vague claims, repetition, detection tells, or uncited specifics. Not for Markdown architecture or archival work.

2026-07-273

planning

ilude/dotfiles

Requirements, user stories, acceptance/verification criteria, or testable outcomes. Not for PRD drafting (/prd) or Pi /goal prompts.

2026-07-273

pi-log-analytics

ilude/dotfiles

Pi session, trace, metrics, routing, workflow-friction, workflow-telemetry, usage, or local JSONL analysis with DuckDB. Use for aggregating or correlating Pi runtime logs. Not for adding telemetry, generic SQL/database design, or non-Pi logs.

2026-07-273

forgejo-actions

ilude/dotfiles

Forgejo Actions: .forgejo/workflows, forgejo-runner, labels, secrets, workflow_dispatch, CI/CD, or deployment. Not for Git remotes, repository setup, or Forgejo APIs; use git-workflow.

2026-07-253

PRD Workflow

Boundary

Core Principle

A PRD records the product decisions needed to align problem, outcome, scope, requirements, and acceptance. Keep it decision-oriented and proportionate to the request.

Artifact Contract

For a new PRD artifact, use pi/skills/workflow/templates/prd-template.md and write .specs/{lowercase-kebab-case-slug}/PRD.md unless the user names another path.

Refine an explicitly supplied PRD in place unless the user requests a new artifact.

Keep Problem, Goals, Non-Goals, context, and rationale as natural narrative.

Treat Requirements and Acceptance Criteria as normative. Load planning and preserve identifiers, defined terms, modal strength, conditions, bounds, and exceptions.

Add users, scenarios, assumptions, risks, dependencies, alternatives, or open questions only when they affect the product decision.

Add /plan-it or /review-it handoffs only when requested.

Ask one concise clarification at a time only when the answer would materially change scope, acceptance, or another product decision. Otherwise draft with explicit assumptions.

Minimal PRD Shape

# PRD: <title> ## Problem ## Goals ## Non-Goals ## Requirements ## Acceptance Criteria

Anti-Patterns

Activating for an incidental mention of a PRD or for every mention of requirements.

Making a PRD mandatory before another workflow.

Expanding a small request into a full product process.

Applying requirement syntax to narrative sections.

Mixing implementation tasks into product requirements unless the implementation is an explicit constraint.

Leaving competing material interpretations hidden in prose.