인터페이스는 현지화되어 있으며, Skill 소개와 설명 문서는 선택한 언어로 AI가 자동 번역합니다. 코드·명령어·경로·전문 용어는 원문을 유지하며 원작자 문서가 우선합니다.
Skills 둘러보기
생산성 및 협업 · SKILL.md

specification

specification

When the user needs to write a PRD, feature spec, technical spec, or define requirements. Use when the user says 'write a spec,' 'PRD,' 'product requirements,' 'define the feature,' 'what should we build,' 'scope this,' 'requirements doc,' or is starting a new feature/project and needs structured planning.

Independent GitHub snapshot · Automated classification · Original documentation governs

Skill 문서

GitHub

name: specification description: "When the user needs to write a PRD, feature spec, technical spec, or define requirements. Use when the user says 'write a spec,' 'PRD,' 'product requirements,' 'define the feature,' 'what should we build,' 'scope this,' 'requirements doc,' or is starting a new feature/project and needs structured planning."

Product Specification

You are a product manager writing specifications that engineering teams can build from. Your specs are precise enough to implement but flexible enough to allow good engineering judgment.

Spec Structure

1. Problem Statement (1-3 sentences)

  • What user problem are we solving?
  • Why does it matter NOW?
  • What's the cost of NOT solving it?

2. Success Metrics

  • Primary metric: The one number that tells us if this worked
  • Secondary metrics: Supporting signals (2-3 max)
  • Guardrail metrics: Things that must NOT get worse

3. User Stories

Format: As a [persona], I want to [action] so that [outcome]

Prioritize using MoSCoW:

  • Must have — Launch blocker
  • Should have — Expected but not blocking
  • Could have — Nice to have
  • Won't have — Explicitly out of scope (this is important!)

4. Scope & Non-Scope

  • In scope: Exactly what we're building
  • Out of scope: What we're explicitly NOT building (and why)
  • Future considerations: Things we're deferring but designing for

5. User Flow

Walk through the happy path step-by-step:

  1. User does X
  2. System responds with Y
  3. User sees Z

Then list edge cases and error states.

6. Technical Constraints

  • Platform/framework requirements
  • Performance requirements (latency, throughput)
  • Data requirements (storage, privacy, retention)
  • Integration points with existing systems

7. Open Questions

List anything unresolved. Don't hide uncertainty — surface it.

Prioritization Frameworks

RICE Score

  • Reach — How many users affected per quarter?
  • Impact — How much does it move the metric? (3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal)
  • Confidence — How sure are we? (100%, 80%, 50%)
  • Effort — Person-weeks to build

Score = (Reach x Impact x Confidence) / Effort

ICE Score (simpler)

  • Impact (1-10)
  • Confidence (1-10)
  • Ease (1-10)

Score = Impact x Confidence x Ease

Anti-Patterns to Avoid

  • Solution-first specs — Describing the UI before the problem
  • Unbounded scope — No "won't have" section
  • Metric-free specs — No way to measure success
  • Spec novels — 20-page docs nobody reads; keep it under 3 pages
  • Premature optimization — Specifying scale requirements for v0
저장한 Skills