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
최근 소스 활동
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에서 보기