AgentSkillsCN

Feature Spec

功能规格

SKILL.md

Feature Spec

Write structured product requirements documents (PRDs) with problem statements, user stories, prioritized requirements, acceptance criteria, and success metrics.

Usage

Ask me to help write a PRD, define requirements for a feature, write user stories, or scope a project.

Capabilities

  • •Write complete PRDs from a feature description
  • •Define user stories with acceptance criteria
  • •Prioritize requirements (P0/P1/P2)
  • •Define success metrics with measurement plans
  • •Manage scope and prevent scope creep

PRD Structure

1. Problem Statement

  • •The user problem in 2-3 sentences
  • •Who experiences it and how often
  • •Cost of not solving it (user pain, business impact)
  • •Evidence: user research, support data, metrics

2. Goals (3-5)

  • •Specific, measurable outcomes
  • •Each answers: "How will we know this succeeded?"
  • •Outcomes, not outputs ("reduce time to X by 50%" not "build wizard")

3. Non-Goals (3-5)

  • •What this feature explicitly will NOT do
  • •Adjacent capabilities out of scope for this version
  • •Brief explanation of why each is out of scope

4. User Stories

Format: "As a [user type], I want [capability] so that [benefit]"

  • •User type should be specific ("enterprise admin" not "user")
  • •Capability describes what, not how
  • •Benefit explains the value delivered
  • •Include error states and edge cases
  • •Order by priority

5. Requirements

  • •P0 (Must-Have): Cannot ship without these. The minimum viable version.
  • •P1 (Nice-to-Have): Improves experience but core works without them.
  • •P2 (Future): Out of scope for v1, but design to support later.

For each: clear behavior description, acceptance criteria, technical constraints, dependencies.

6. Success Metrics

Leading (days-weeks): adoption rate, activation rate, task completion rate, error rate Lagging (weeks-months): retention impact, revenue impact, support ticket reduction

Set specific targets with measurement method and evaluation timeline.

7. Open Questions

  • •Tag with who should answer (engineering, design, legal, data)
  • •Mark as blocking or non-blocking

Acceptance Criteria Format

Given/When/Then:

  • •Given [precondition]
  • •When [user action]
  • •Then [expected outcome]

Checklist:

  • • Specific testable behavior
  • • Error case handled
  • • Edge case covered

Scope Management

Recognize scope creep:

  • •Requirements added after spec is approved
  • •"Small" additions accumulating
  • •"While we're at it..." features no user asked for

Prevent it:

  • •Explicit non-goals in every spec
  • •Any scope addition requires a removal or timeline extension
  • •Separate v1 from v2 clearly
  • •Create a parking lot for good ideas that are not in scope

Example Prompts

  • •"Write a PRD for user onboarding improvements"
  • •"Define user stories for the notification system"
  • •"Help me scope this feature -- what's P0 vs P1?"
  • •"Write acceptance criteria for the search feature"

Tools

  • •read_file: Read existing specs or requirements
  • •write_file: Save PRDs and spec documents
  • •edit_file: Update existing specifications
  • •web_search: Research competitor implementations or best practices