kn-standard-prd
3
总安装量
3
周安装量
#57097
全站排名
安装命令
npx skills add https://github.com/kaisanetwork/kn-standard-prd --skill kn-standard-prd
Agent 安装分布
amp
3
antigravity
3
github-copilot
3
codex
3
kimi-cli
3
gemini-cli
3
Skill 文档
KN Standard PRD
Purpose
Produce execution-ready PRDs that align business, product, design, and engineering. This skill combines strict requirement quality, practical templates, and deterministic validation.
When To Use
Use when the user asks to:
- Create or improve a PRD
- Document feature requirements
- Define scope and acceptance criteria
- Produce lean, one-pager, technical, or AI-feature PRDs
Operating Principles
- Ask before drafting: do not write a full PRD without discovery.
- Be measurable: replace vague words with thresholds and target values.
- Separate
what/whyfromhow: avoid over-specifying implementation. - Guard scope: explicitly list in-scope and out-of-scope.
- Preserve uncertainty: unknowns are written as
TBDwith owner and due date.
Workflow
1) Discovery Interview (Required)
Ask focused questions and fill missing context. Use references/discovery_question_bank.md.
Minimum discovery bar:
- If user context is vague: ask at least 5 questions.
- If user gives a detailed brief: ask at least 2 critical gap questions.
Required topics:
- Problem and urgency
- Target users and use cases
- Business outcomes and success metrics
- Constraints (timeline, legal, platform, budget)
- Scope boundaries and non-goals
2) Select PRD Mode
Choose one mode with the user:
standard: end-to-end production PRDlean: agile-friendly compact PRDone-pager: executive-level brieftechnical: engineering-heavy requirementsai-feature: adds model/tool/evaluation sections
Template sources:
references/prd_template_standard.mdreferences/prd_template_lean.md
3) Draft Requirements
For each major capability:
- Write user stories in standard format.
- Add acceptance criteria that are testable.
- Add non-functional requirements (performance, reliability, security, accessibility).
Story patterns: references/user_story_examples.md
4) Define Metrics
Pick a framework using references/metrics_framework_selector.md.
- Always define one North Star metric.
- Include leading and lagging indicators.
- Add baseline, target, and timeframe.
5) Quality Gate (Required)
Run validation:
scripts/validate_prd.sh <file.md> --mode <standard|lean|one-pager|technical|ai-feature>
Compatibility note:
scripts/validate_prd.shis a Bash script and must be run with Bash (bash scripts/validate_prd.sh ...).- If Bash is unavailable in the environment, skip script execution and run a manual checklist from
references/prd_review_checklist.md.
If validation reports critical issues, revise before presenting as final.
Output Contract
A final PRD must contain at minimum:
- Problem statement
- Goals/objectives
- User stories with acceptance criteria
- Success metrics (with numeric targets)
- Scope (in + out)
- Risks and dependencies
For ai-feature mode, also include:
- Model/provider assumptions
- Evaluation dataset/benchmark plan
- Safety/privacy constraints
- Fallback behavior on low confidence
Requirement Quality Standard
Bad:
- “Search should be fast”
Good:
- “p95 search latency <= 250ms on 100k records”
Bad:
- “Onboarding should be intuitive”
Good:
- “Activation rate >= 45% within first session”
Anti-Patterns To Reject
- Writing PRD without discovery
- Missing out-of-scope section
- Acceptance criteria that are not testable
- Metrics without baseline/target/time window
- Placeholder-heavy drafts presented as final
Bundled Resources
references/
prd_template_standard.md: full PRD structureprd_template_lean.md: compact structure for smaller changesdiscovery_question_bank.md: interview questions by scenariometrics_framework_selector.md: framework selection and examplesmode_selection_matrix.md: how to choose the right PRD mode quicklyuser_story_examples.md: story and acceptance-criteria patternsprd_review_checklist.md: pre-signoff quality checklist
scripts/
validate_prd.sh: structure and quality checks with mode support
Execution Notes
- Prefer concise, skimmable markdown.
- Keep stakeholder language clear and implementation-neutral.
- Where confidence is low, explicitly mark assumptions and open questions.