product-capability

Product Capability

Transform a product requirement or feature request into a capability specification: a structured technical document that bridges product intent and engineering implementation.

Distinct from create-prd:

• create-prd → what and why (Jobs-to-be-Done, personas, scope). Audience: PMs, stakeholders.
• product-capability → what + how (acceptance criteria, task breakdown, traceability). Audience: engineers building it.

When to Use

• Engineering needs a clear, testable spec to implement from — not a narrative PRD
• Acceptance criteria must be explicit and verifiable before a ticket is created
• Traceability is required: feature request → capability → AC → implementation tasks
• A PRD exists but lacks the implementation detail engineers need to estimate or build

When NOT to Use

Instead of product-capability	Use
Exploring the problem space and options	opportunity-solution-tree
Writing the product story for stakeholders	create-prd
Prioritizing what to build next	feature-prioritization
Planning launch readiness	launch-strategy

Structure

A capability spec consists of five parts:

1. Capability Statement

One sentence: what the system must be able to do.

The system must allow authenticated users to export their activity history
as a CSV file filtered by date range.

Write as system capability, not user story. Avoid "As a user, I want…" — that belongs in the PRD.

2. Context

• Source requirement (link to PRD, issue, or ticket)
• Affected components (which services, modules, APIs)
• Dependencies (what must exist before this can be built)

3. Acceptance Criteria

Each criterion must be:

• Testable: a QA engineer can write a test case for it without ambiguity
• Specific: names exact behavior, not intent
• Binary: pass or fail — no "should generally work"

**AC-01**: Given a user with `EXPORT_HISTORY` permission, when they request
  an export for date range [start, end], the system returns a valid CSV within
  5 seconds containing all activity records in that range.

**AC-02**: Given an empty result set, the system returns an empty CSV with
  only the header row, not an error.

**AC-03**: Given a date range exceeding 1 year, the system rejects the request
  with HTTP 422 and error code `DATE_RANGE_TOO_LARGE`.

**AC-04**: Exported CSV rows include: timestamp (ISO 8601), action_type,
  resource_id, user_id, ip_address.