From vamfi-software-consultancy
This skill should be used when the user asks to "write a PRD", "draft product requirements", "create a requirements document", "define features and NFRs", "write user stories for a product", or needs to produce a structured Product Requirements Document from discovery findings or a product brief.
npx claudepluginhub vamfi/vamfi-plugins --plugin vamfi-software-consultancyThis skill uses the workspace's default tool permissions.
Produce a precise, structured Product Requirements Document (PRD) that defines what to build, for whom, and how success will be measured. Every requirement must be testable; every assumption must be explicit.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Produce a precise, structured Product Requirements Document (PRD) that defines what to build, for whom, and how success will be measured. Every requirement must be testable; every assumption must be explicit.
A PRD is the contract between business and delivery. It defines the scope of what will be built and what will not. This skill produces a PRD that is specific enough to drive architecture and story shaping, while remaining a business document that non-technical stakeholders can validate.
Goals must be outcome-oriented, not output-oriented:
Non-goals are equally important — state at least 3 things that are deliberately excluded.
For each primary persona:
Format each requirement as:
REQ-[N]: [Short title]
As a [persona], I want [capability] so that [outcome].
Acceptance criteria:
- Given [context], when [action], then [result]
Priority: Must Have / Should Have / Could Have / Won't Have (MoSCoW)
| Category | Requirement | Metric | Target | Priority |
|---|---|---|---|---|
| Performance | Page load time | p95 response time | < 2s | Must Have |
| Availability | Service uptime | Monthly uptime | 99.9% | Must Have |
| Security | Authentication | MFA support | Required for admin | Must Have |
| Scalability | Concurrent users | Peak load | 10,000 | Should Have |
| Accessibility | WCAG compliance | WCAG level | 2.1 AA | Must Have |
Constraints: technical, regulatory, timeline, or budget facts that bound the solution space. Dependencies: other systems, teams, or external parties that must deliver something for this to work.
Track every significant decision made during PRD authoring:
| Decision | Options Considered | Rationale | Date | Owner |
|---|---|---|---|---|
| [decision] | [option A vs B] | [why this choice] | [date] | [who decided] |
# Product Requirements Document: [Product/Feature Name]
Version: 1.0 | Date: [YYYY-MM-DD] | Status: Draft
## Goals
[Outcome-oriented goals]
## Non-Goals
[Explicit exclusions]
## User Personas
[Persona cards]
## User Journey
[Key flows — happy path and exception paths]
## Functional Requirements
[REQ-N format requirements]
## Non-Functional Requirements
[Table]
## Constraints
[Technical, regulatory, timeline, budget]
## Dependencies
[External systems, teams, services]
## Open Questions
[Unresolved items that must be decided before build]
## Action Ledger
[Decision log table]
## Out of Scope
[Explicit out-of-scope items to prevent scope creep]
references/requirement-quality-checklist.md — Checklist for testable, unambiguous requirementsassets/prd-template.md — Full blank PRD template