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 ページを確認してインストールできます。
SOC 職業分類に基づく
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)"