From discover
Defines PRD structure, user story format with 4 Risks assessment, EARS-format acceptance criteria, and delivery readiness thresholds. Use when writing PRDs, drafting user stories, defining acceptance criteria, or reviewing PRD quality and completeness.
npx claudepluginhub shinpr/claude-code-workflows --plugin discoverThis skill uses the workspace's default tool permissions.
Canonical reference for PRD quality — shared by both authoring and review workflows. Ensures the author and reviewer apply the same standards.
Generates structured PRDs with problem, context, solution, user stories, acceptance criteria, metrics, risks, and out-of-scope items. Iteratively gathers info via questions, reviews docs/issues/templates.
Generates Product Requirements Documents (PRDs) with user stories, success metrics, scope, technical considerations, and risks for product features.
Drafts lightweight PRDs via guided conversation for feature ideas, requirements brainstorming, sprint planning, user stories, and acceptance criteria expansion.
Share bugs, ideas, or general feedback.
Canonical reference for PRD quality — shared by both authoring and review workflows. Ensures the author and reviewer apply the same standards.
| Task | Read |
|---|---|
| Writing or reviewing a full PRD | references/prd-template.md |
| Writing or reviewing acceptance criteria | references/acceptance-criteria.md |
| Assessing story readiness or drafting user stories | references/user-story-guide.md |
4 Risks framework, Confidence Meter (0-10), and OST hierarchy are foundational concepts. This skill operationalizes them in the PRD context — templates, thresholds, and format.
A discovery-driven PRD follows a standard structure with additive extensions. See references/prd-template.md for the authoritative template.
Core sections (standard PRD):
Discovery extensions (additive, never replace core sections):
Each user story follows the persona-grounded format with 4 Risks assessment. See references/user-story-guide.md for the full guide.
Key rules:
docs/product/personas/, not generic "user"All functional requirements use EARS-format acceptance criteria. See references/acceptance-criteria.md for patterns and examples.
Key rules: