pm-spec-writing

# PM Spec Writing Take an idea (often vague) and turn it into a specification a developer or AI agent can actually build from. Stack-agnostic. Works for new features, bug fixes, content changes, or infrastructure work. --- ## When to use - Translating an idea into a buildable feature spec - Writing a PRD or product requirement document - Filing a bug report that someone else can act on - Scoping a project before kickoff - Prioritizing a backlog of feature requests - Writing acceptance criteria for an existing feature - Breaking a large initiative into shippable increments ## When NOT to use - Quarterly or annual planning across multiple initiatives (use `roadmap-planning`) - Code review or debugging existing code (use `code-review-web`) - Design decisions for a feature already specced (use `design-standards`) - User research to validate an idea (use `ux-research`) --- ## Required inputs - The idea, request, or problem being addressed - The audience or user affected - Any existing constraints (stack, deadlines, dependencies) - The success metric (how will you know it worked?) If the idea is vague, the workflow's first step is clarification. Do not write specs around vagueness. --- ## The framework: 4 phases Every PM workflow follows the same arc. The phases are universal even if the specific outputs vary. ### Phase 1: Clarify the idea Before any spec, answer four questions. If any answer is "I don't know," go back to the user. 1. **What user problem does this s...