role-product-manager
PM role in AID methodology. Use for requirements, user stories, acceptance criteria, stakeholder management, scope definition.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
PM role in AID methodology. Use for requirements, user stories, acceptance criteria, stakeholder management, scope definition.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
AID Phase 4 - Development phase. Use for implementing features, TDD practices, code reviews, transitioning from planning to QA.
AID Phase 0 - Research & discovery. Use for validating problem spaces, identifying stakeholders, defining success metrics, deciding whether to proceed.
AID Phase 3 - Implementation Planning with consolidation-first approach. Resolves contradictions between PRD and Tech Spec, creates consolidated master document, then breaks down into actionable tasks and populates Jira. Includes sprint planning and risk assessment.
AID Phase 1 - PRD creation. Use for user stories, acceptance criteria, scoping features, transitioning from discovery to tech spec.
AID Phase 5 - QA and Release. Use for validating implementations, acceptance tests, preparing releases, deployment, operational readiness.
AID Phase 2 - Technical Specification. Use for system architecture, API contracts, data models, security architecture, transitioning from PRD to implementation.
| name | role-product-manager |
| description | PM role in AID methodology. Use for requirements, user stories, acceptance criteria, stakeholder management, scope definition. |
| Phase | Focus | Output |
|---|---|---|
| Discovery | Problem validation | Problem statement, stakeholder map |
| PRD | Requirements | PRD, user stories, acceptance criteria |
| Tech Spec | Review feasibility | Alignment review, clarifications |
| Development | Clarify & validate | Requirement answers, acceptance testing |
| QA & Ship | Acceptance | Sign-off, release notes |
As a [role]
I want [capability]
So that [benefit]
Acceptance Criteria:
- Given [context], when [action], then [outcome]
| Anti-Pattern | Fix |
|---|---|
| Solution-first | Start with problem |
| Implementation in requirements | Focus on WHAT not HOW |
| Assuming stakeholders | Verify who's affected |
| Vague criteria | "It should be fast" -> "<2s" |
| Scope creep | Explicit acknowledgment |
| Role | How |
|---|---|
| Developers | Clear requirements, answer questions |
| QA | Review scenarios, clarify edge cases |
| Tech Leads | Discuss feasibility, accept constraints |
Bad: "Make dashboard faster"
Good: "Reduce load from 4s to <1s (P95)"