Skip to main content

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.

Zur Installation springen

Quellinformationen

Repository
khorzhenwin/tenxeng
Letzte Quellaktivität
21. März 2026 um 08:30
Erkannte Sprache von SKILL.md
Englisch
Sterne
0
Forks
0

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
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.
Auf GitHub ansehen