prd

Sterne0

Forks0

Aktualisiert30. Juli 2026 um 21:33

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

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

fastestdevalive

fastestdevalive/vibekit

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Datei-Explorer

3 Dateien

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

Mehr aus diesem Repository

gleiches 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