prd

Stars0

Forks0

UpdatedJuly 30, 2026 at 21:33

Product requirements document for larger features — user-facing behavior, options, decisions, screen layouts, and open questions. Precedes the technical plan.

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

fastestdevalive

fastestdevalive/vibekit

View GitHub Repository View Creator Repositories

Download

File Explorer

3 files

SKILL.md

readonly

name	prd
description	Product requirements document for larger features — user-facing behavior, options, decisions, screen layouts, and open questions. Precedes the technical plan.
version	0.1.0
triggers	["write a PRD","write a product requirements doc","/prd"]
globs	[".vibekit/feature-plans/**"]

PRD skill

Use this skill before writing a technical plan when a feature is large enough to warrant capturing what and why before jumping into how.

When to write a PRD

Feature spans multiple user-facing screens or changes an existing UX flow
There are genuine options or trade-offs to document before committing to an approach
Multiple stakeholders (or future-you) need to understand the intent months later
The feature has non-trivial edge cases, back-navigation rules, or out-of-scope boundaries

When NOT to write a PRD

Pure refactors with no behavior change
Bug fixes with a clear root cause and fix
Small enhancements with an obvious, unambiguous implementation

Workflow

PRD  →  Technical Plan  →  Implementation

Create .vibekit/feature-plans/pending/<feature>/prd-<feature>.md (this skill) — directory mode, primary
- Sub-feature PRD (only when the master PRD doesn't cover it): <feature>/NN-<sub>/prd-<NN>-<feature>-<sub>.md
- Backward compat: .vibekit/feature-plans/pending/prd-<slug>.md (flat file) still works for existing projects
Once the PRD is reviewed and decisions are settled, create .vibekit/feature-plans/pending/<feature>/plan-<feature>.md (planning skill)
Link the two files via frontmatter (prd: and plan: fields)

Format rules

Read FORMAT.md before writing — it has the requirement-writing rules and header block.

Requirements: one crisp line each — no multi-sentence descriptions
Requirements describe user-facing behavior, not implementation steps
No file paths, no code references
See _prd_sample_format.md for the template

More from this repository

same repository

android-coding

fastestdevalive/vibekit

Android/Kotlin/Compose coding rules — modular architecture, ViewModel scope, Material 3, Compose pitfalls, strings, navigation, network safety, and build hygiene. Extends `coding` + `coding-agent-guardrails`.

2026-07-300

coding-agent-guardrails

fastestdevalive/vibekit

Universal code quality guardrails — file size limits, code structure, VCS discipline, and build behavior for any project

2026-07-300

coding

fastestdevalive/vibekit

Universal coding rules for any project type — error handling, testing, API design, dependency hygiene, config/secrets, logging. Extends `coding-agent-guardrails`.

2026-07-300

planning

fastestdevalive/vibekit

Structured technical feature plan with bullet-point format, file/line references, phased implementation checklists, and per-phase test verification

2026-07-300

report

fastestdevalive/vibekit

One-shot investigation → findings document. No state, no checklist, no phases — investigate, write the answer, stop.

2026-07-300

sdlc

fastestdevalive/vibekit

Orchestrates the full agentic SDLC — PRD → Plan → Review → Implement → Verify → Review — with pluggable reviewer model, feature/sub-feature decomposition, and resumable state.

2026-07-300

name	prd
description	Product requirements document for larger features — user-facing behavior, options, decisions, screen layouts, and open questions. Precedes the technical plan.
version	0.1.0
triggers	["write a PRD","write a product requirements doc","/prd"]
globs	[".vibekit/feature-plans/**"]

PRD skill

Use this skill before writing a technical plan when a feature is large enough to warrant capturing what and why before jumping into how.

When to write a PRD

Feature spans multiple user-facing screens or changes an existing UX flow
There are genuine options or trade-offs to document before committing to an approach
Multiple stakeholders (or future-you) need to understand the intent months later
The feature has non-trivial edge cases, back-navigation rules, or out-of-scope boundaries

When NOT to write a PRD

Pure refactors with no behavior change
Bug fixes with a clear root cause and fix
Small enhancements with an obvious, unambiguous implementation

Workflow

PRD  →  Technical Plan  →  Implementation

Create .vibekit/feature-plans/pending/<feature>/prd-<feature>.md (this skill) — directory mode, primary
- Sub-feature PRD (only when the master PRD doesn't cover it): <feature>/NN-<sub>/prd-<NN>-<feature>-<sub>.md
- Backward compat: .vibekit/feature-plans/pending/prd-<slug>.md (flat file) still works for existing projects
Once the PRD is reviewed and decisions are settled, create .vibekit/feature-plans/pending/<feature>/plan-<feature>.md (planning skill)
Link the two files via frontmatter (prd: and plan: fields)

Format rules

Read FORMAT.md before writing — it has the requirement-writing rules and header block.

Requirements: one crisp line each — no multi-sentence descriptions
Requirements describe user-facing behavior, not implementation steps
No file paths, no code references
See _prd_sample_format.md for the template