prd

Estrelas0

Forks0

Atualizado30 de julho de 2026 às 21:33

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

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

fastestdevalive

fastestdevalive/vibekit

Abrir repositório GitHub Ver repositórios do creator

Download

Explorador de arquivos

3 arquivos

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

Mais deste repositório

mesmo repositório

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