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.

الانتقال إلى التثبيت

معلومات المصدر

المستودع
khorzhenwin/tenxeng
آخر نشاط في المصدر
٢١ مارس ٢٠٢٦ في ٠٨:٣٠
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٠
التفرعات
٠

خيارات التثبيت

يُحدَّد 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