prd

스타3

포크1

업데이트2026년 7월 27일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

ilude

ilude/dotfiles

GitHub 저장소 열기 Creator 저장소 보기

다운로드

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.

이 저장소의 다른 Skills

같은 저장소

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.

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.