product-manager
Drive feature requirements, scope, acceptance criteria, and cross-role handoff for this repo. Use when reviewing product gaps, writing PRDs, choosing MVP scope, defining success metrics, or synchronizing PM, engineering, and QA around a feature.
ソース情報
- リポジトリ
- khorzhenwin/tenxeng
- ソースの最終更新活動
- 2026年3月21日 08:30
- 検出された SKILL.md の言語
- 英語
- スター
- 0
- フォーク
- 0
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SKILL.md を表示中
SKILL.md
ソースの指示 · 読み取り専用プレビュー- name
- product-manager
- description
- Drive feature requirements, scope, acceptance criteria, and cross-role handoff for this repo. Use when reviewing product gaps, writing PRDs, choosing MVP scope, defining success metrics, or synchronizing PM, engineering, and QA around a feature.
# Product Manager
## When To Use
Use this skill when you need to:
- Review product gaps before coding
- Turn ideas into testable requirements
- Define MVP scope and non-goals
- Keep PM, engineering, and QA aligned on one feature packet
## Default Workflow
1. Inspect product context in `README.md`, relevant docs, and current UI/API entry points.
2. Write the user problem, target user, and why the feature matters now.
3. Lock MVP scope, explicit non-goals, and rollout risks before implementation.
4. Create or update the shared feature packet under `docs/product/<feature>/`:
- `PRD.md`
- `IMPLEMENTATION.md`
- `QA.md`
5. Keep acceptance criteria observable in UI, API, or persisted data.
6. Hand off one source of truth to engineering and QA; avoid parallel requirement versions.
## Required Deliverables
### `PRD.md`
- Problem statement
- Goals and non-goals
- User stories
- MVP scope
- Acceptance criteria
- Rollout notes, risks, and follow-ups
## Synchronization Rules
- Use one stable feature name/path across docs, code, and tests.
- If scope changes, update `PRD.md` first, then `IMPLEMENTATION.md` and `QA.md` in the same change.
- Keep acceptance criteria concise and testable.
- Prefer repository conventions over ad-hoc process documents.
## Repo-Specific Guidance
- Core product shell lives in `app/dashboard/page.tsx`.
- Route handlers live in `app/api/**/route.ts`.
- Reusable business logic belongs in `lib/**`.
- Feature packet docs for this workflow belong in `docs/product/`.
- Call other repo skills when the feature touches Firebase, Gemini, routes, or integration tests.
## Handoff Checklist
- [ ] User problem is explicit.
- [ ] MVP and out-of-scope work are separated.
- [ ] Acceptance criteria are observable.
- [ ] Engineering entry points are named.
- [ ] QA scenarios and rollout risks are captured.
## Anti-Patterns
Do not:
- Start implementation before requirements are stable enough to test.
- Write broad goals without acceptance criteria.
- Let PM, engineering, and QA work from different briefs.
- Fold future ideas into MVP scope without labeling them as follow-ups.
GitHubで見る