本文へ移動
cccskills
無料GitHub で公開

common-product-requirements

Standardize PRD discovery and drafting for product scope, user outcomes, requirement IDs, and acceptance criteria. Use when creating PRD, product requirements, feature specification, or acceptance criteria plan.

インストール方法を見る

含まれるファイル(5)

  • SKILL.md4.2 KB
  • evals/evals.json3.6 KB
  • references/checklist.md1.5 KB
  • references/lean-spec-template.md631 B
  • references/prd-template.md3.3 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Product Requirements Expert

Priority: P0 (CRITICAL)

Role: PM-owned product spec owner. Define the product "What" before technical design or implementation.

1. Discovery Phase (Iterative)

  • Context Injection: Ask for linked BRD objective and business success metric.
  • Gap Analysis: Identify missing info (problem, persona/JTBD, use cases, metrics, platform, flows, constraints, priorities, analytics, rollout, open questions).
  • Active Inquiry:
  • Ask 3-5 clarification questions at a time.
  • MUST provide (a, b, c) options to reduce user friction.
  • Example: "Target platform? a) Web b) Mobile c) Both"
  • Repeat: Continue until Actionable State reached.

2. Drafting Phase (System of Record)

  • Filesystem: Ensure docs/prd/ exists.
  • Load Template: Read references/prd-template.md.
  • Slug Alignment: Use the same [slug] from the source docs/brd/brd-[slug].md to maintain filename-level traceability.
  • Fill & Fix: Map Discovery answers to template. Mark unknowns as TBD.
  • Traceability: Assign stable REQ-* and AC-* IDs, and map each requirement to a BRD objective reference.
  • User Stories: Require specific persona, clear business value, and INVEST self-check.
  • Acceptance Criteria: Use Given/When/Then for behavior that could be misread; cover happy, edge, and negative paths.
  • Implementation Gate: Do not hand off to engineering until each slice names REQ-*, AC-*, owner, status, priority, and verification lane.
  • Handoff Quality: Name requirement owners, status, and define rollout/ops. Identify whether design-solution is required.
  • Readiness Route: Existing code without PRD/AC proof is partial/unverified; route through implementation-readiness.
  • Outcome Report: Include feature_status, requirement trace, completed/missing evidence, decision needed, and recommended next workflow.
  • Living Spec: Include analytics, risks, rollout, decisions, and changelog.
  • Output: Write to docs/prd/prd-[slug].md.

3. Verification Checklist (Mandatory)

  • Functional: all user flows defined?
  • Traceability: every AC mapped to REQ-* and business objective?
  • Non-Functional: Performance? Security? Offline mode?
  • Analytics/Ops: Events, guardrails, rollout, and support readiness?
  • Tech Constraints: DB schema impacts? API changes?
  • Edge Cases: Zero state? Error state?
  • Scope Hygiene: Out-of-scope items explicitly listed?

Anti-Patterns

  • No Assumptions: Never guess business logic. Ask.
  • No Vagueness: "Fast" -> "Load < 200ms".
  • No Implementation: PRD = "What", Implementation Plan = "How".
  • No Coding Before ACs: route missing ACs, owners, or RACI back to PM planning.
  • Offshore handoff: explicitly include a PM/BA/Engineering/QA RACI and name the validation owner before development starts.
  • No Orphan Requirements: every requirement must have owner, status, and linked objective.
  • No BRD/SRS Conflation: Route business-only items to BRD skill and technical-contract items to SRS skill.
  • No Generic Actors: replace "user" with a specific role or persona.

References

Ownership checklist

  • Record the Product owner, Engineering owner, and QA/release owner for every requirement or release decision.

Canonical response anchors

When this skill applies, preserve the following domain terminology or equivalent concrete examples in the answer when relevant:

  • Discovery,What outcome,Which channels
  • docs/prd
  • implementation-readiness

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Upgrade an Android project to Android Gradle Plugin (AGP) 9. Use when migrating to AGP 9, updating Gradle build files, migrating to built-in Kotlin, or adopting the new AGP DSL.

日本語の概要は準備中です。原文の説明を表示しています。

HoangNguyen0403/agent-skills-standard5732026年10月12日 更新

Apply Clean Architecture layering, modularization, and Unidirectional Data Flow in Android projects. Use when setting up project structure, placing code in layers, configuring feature/core modules, or implementing UDF patterns; defer Compose state and ViewModel/StateFlow implementation to their specific skills.

日本語の概要は準備中です。原文の説明を表示しています。

HoangNguyen0403/agent-skills-standard5732026年10月12日 更新

Implement WorkManager and background processing correctly on Android. Use when creating Worker classes, scheduling tasks, choosing between WorkManager and Foreground Services, or setting up Hilt in workers; defer FCM and notification delivery to android-notifications.

日本語の概要は準備中です。原文の説明を表示しています。

HoangNguyen0403/agent-skills-standard5732026年10月12日 更新

Build high-performance declarative UI with Jetpack Compose. Use when writing Composable functions, optimizing recomposition, hoisting state, or working with LazyColumn and side effects; defer deep-link and navigation routing to android-navigation.

日本語の概要は準備中です。原文の説明を表示しています。

HoangNguyen0403/agent-skills-standard5732026年10月12日 更新

Migrate an Android XML View to Jetpack Compose following a structured 10-step workflow. Use when converting XML layouts to Compose, setting up Compose in an existing View-based project, or incrementally adopting Compose.

日本語の概要は準備中です。原文の説明を表示しています。

HoangNguyen0403/agent-skills-standard5732026年10月12日 更新

Write correct coroutine scopes, lifecycle collection, and dispatcher injection in Android production code. Use for suspend functions, coroutine scopes, and dispatcher mechanics; defer ViewModel StateFlow/LiveData architecture, Fragment lifecycle recipes, persistence/notifications, and unit-test recipes to their specific skills.

日本語の概要は準備中です。原文の説明を表示しています。

HoangNguyen0403/agent-skills-standard5732026年10月12日 更新

HoangNguyen0403 のスキルをすべて見る

このスキルの問題を報告する