prd

Estrelas3

Forks1

Atualizado27 de julho de 2026 às 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.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

ilude

ilude/dotfiles

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Especialistas em gestão de projetosNegócios e Operações Financeiras·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.

Mais deste repositório

mesmo repositório

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.