prd

النجوم٣

التفرعات١

آخر تحديث٢٧ يوليو ٢٠٢٦ في ١٤:٤٦

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

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.

المزيد من هذا المستودع

نفس المستودع

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.