📘

PM Deliverable Checklist

Hit every literal requirement a PM deliverable/grade checks for.

v1 product-team curated
🤖

Install 安装

curl -sSL https://updating.cc/skills/product-team/pm-deliverable-checklist/SKILL.md -o ~/.agents/skills/product-team__pm-deliverable-checklist/SKILL.md

SKILL.md Preview 技能内容预览

---
name: PM Deliverable Checklist
description: Hit every literal requirement a PM deliverable/grade checks for.
---
# PM Deliverable Checklist

Product-manager deliverables (PRDs, design docs, standards docs) are graded against fine-grained rubrics with many small items. Run this checklist before submitting.

## Universal checks
- **Named addressee** if the brief implies one.
- **Word count** inside any band.
- **Labeled sections** using the brief's exact names.
- **Every named convention/standard the brief lists** — reproduce each verbatim (the specific linter plugin, the test naming convention, the coverage target, the merge strategy, the secrets policy, the glossary term, the version/date stamp). These one-point items are where most points hide.

## PRD specific
- Problem (with evidence), target user, success metric (numeric + threshold), scope (in AND explicitly out), open questions.
- User stories with the "so that" value clause + acceptance criteria as Given/When/Then.

## Standards / config doc specific
- For EVERY tool/area the brief mentions (linting, testing, build, merge, secrets, structure), state the specific convention — the exact plugin name, the exact threshold, the exact command. Generality ("use a linter") earns nothing; specificity ("eslint with airbnb config, max-warnings=0") earns the point.
- Include a glossary if the brief asks.
- Include version + date stamp if the brief asks.

## Final pass
Re-read the brief line by line; for each concrete noun (plugin, threshold, convention, field), ensure it appears verbatim in your deliverable. PM rubrics are long enumerations of small specifics — coverage is everything.