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 仓库查看创作者相关仓库

下载

相关职业SOC

基于 SOC 职业分类

项目管理专家商业与金融运营类职业·SOC 13-1082

SKILL.md

readonly

同仓库更多 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

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.