claudegoodies
Skill

product-capability

From affaan-m

Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.

Converts a PRD or roadmap ask into a written capability plan listing constraints, interfaces, and open questions before coding starts.

Use it when

  • A feature spans multiple services/repos and needs a shared contract before implementation
  • Reviewers keep re-explaining the same hidden assumptions during PRs
  • A PRD exists but architecture, data, or lifecycle implications are still fuzzy
  • You want a durable PRODUCT.md-style artifact instead of scattered planning notes

Skip it if

  • The task is single-service or small enough that a quick plan is unnecessary overhead
  • No PRD, roadmap item, or product discussion exists yet to translate
  • You just need code written, not a constraints/contract document

Facts

Repository
affaan-m/ECC
Status
Actively maintained
Last commit
Source file
.agents/skills/product-capability/SKILL.md

Source preview

The instructions Claude Code reads when this skill runs.

# Product Capability

This skill turns product intent into explicit engineering constraints.

Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"

## When to Use

- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
- Senior engineers keep restating the same hidden assumptions during review
- You need a reusable artifact that can survive across harnesses and sessions

## Canonical Artifact

If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.

If no capability manifest exists yet, create one using the template at:

- `docs/examples/product-capability-template.md`

The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.

## Non-Negotiable Rules

- Do not invent product truth. Mark unresolved questions explicitly.
- Separate user-visible promises from implementation details.
- Call out what is fixed policy, what is architecture preference, and what is still open.
- If the request conflicts with existing repo constraints,
View full source on GitHub →

Other skills