prd
PRD
Create a structured Product Requirements Document with user stories, acceptance criteria, functional requirements, and scope boundaries.
When to Use
- A direction has been chosen and needs to be formalized into requirements
- Before architecture or task breakdown — requirements must exist first
- When the team needs a shared source of truth for what "done" means
- When acceptance criteria need to be explicit and verifiable
When NOT to use: Requirements are already documented in a prd.md that is still accurate, or the change is a single-line fix with obvious scope.
Input
brainstorming.mdfrom the artifact folder (required — contains chosen direction)goal-definition.mdfrom the artifact folder (required — contains success criteria)context-map.mdfrom the artifact folder (recommended — for technical grounding)
More from olamedia/analytics-skills
analyze-project
Use when starting work on any project to produce or update living documentation (TechStack.md, ProjectStructure.md) that bootstraps context for any AI agent session. Run before any feature work, or periodically to keep docs current.
13humanizer
>-
12architect
>-
12goal-definition
Use when you have a raw idea or request and need to define a clear goal with success criteria before exploring solutions. Use when requirements are vague, when "what does done look like" is unclear, or when assumptions need surfacing.
11analyze
Use when you have a raw idea or request and want to run the full analytics pipeline automatically — from research through to an interlinked task list. Best for straightforward problems where the full pipeline can flow with minimal back-and-forth.
10frontend-design
>-
10