Skip to main content
skill Claude Code CX Codex Cursor GitHub Copilot

product-capability — Claude skill: PRD to implementation plan

Turns a PRD, roadmap item or product discussion into a capability plan with constraints, invariants and interfaces spelled out before multi-service work starts.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add affaan-m/ECC --skill product-capability -a claude-code
Open on GitHub

What product-capability does

Reach for this skill when the open question is not what to build but what must be true before implementation begins. It compresses the ask into one precise statement of the new capability, then pulls out the constraints: business rules, scope boundaries, invariants, trust boundaries, data ownership, lifecycle transitions, rollout and migration requirements, failure and recovery expectations.

The result is an SRS-style capability plan: a summary, explicit non-goals, actors and surfaces, states and transitions, interface and data implications, security, billing and policy constraints, observability requirements, and the open questions still blocking work. It closes with a handoff verdict — ready to implement, needs architecture review, or needs product clarification first. If the repo already keeps product context in PRODUCT.md or docs/product/, the skill updates it there; otherwise it starts from docs/examples/product-capability-template.md.

One rule shapes the whole thing: product truth is never invented. Unresolved questions get marked, and a conflict with existing repo constraints is stated outright rather than smoothed over. Worth installing if a feature crosses several services or repos and senior engineers keep restating the same hidden assumptions in review. For a one-file change it is extra ceremony.

What it helps with

  • surface hidden constraints from a PRD before coding starts
  • lock a capability contract for a feature spanning several services
  • collect invariants and trust boundaries into one artifact
  • separate user-visible promises from implementation details
  • flag open questions that block implementation

Example prompts for the agent

  • Read docs/prd/billing.md and produce a capability plan with constraints and open questions
  • Here is a founder note about the new onboarding — turn it into an SRS-style plan and tell me what blocks the start
  • Update PRODUCT.md for this feature and give me the handoff: implement, architecture review, or product clarification

How to install product-capability

1Skills CLI (Vercel)

npx skills add affaan-m/ECC --skill product-capability -a claude-code

2Manually: put the files in place

~/.claude/skills/product-capability/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/product-capability/

From the same set146

The whole set →
video-editing affaan-m AI-assisted workflow for editing, trimming, and enriching real footage. Connects raw recordings with FFmpeg cuts, Remotion overlays, and ElevenLabs voiceovers. Claude Code CX Codex Cursor +1 6,500installs docker-patterns affaan-m A skill with Dockerfile and Docker Compose patterns: local dev stacks, networking, volumes, container hardening. Claude Code CX Codex Cursor +1 6,300installs frontend-patterns affaan-m A skill for React and Next.js work: component patterns, state, data fetching, and render performance. Use it when building or reviewing UI. Claude Code CX Codex Cursor +1 5,900installs backend-patterns affaan-m A skill with backend patterns for Node.js, Express and Next.js API routes: layering, caching, transactions, error handling. Claude Code CX Codex Cursor +1 5,900installs coding-standards affaan-m Baseline cross-project coding conventions for naming, immutability, and clean code principles. Useful for code reviews and refactoring. Claude Code CX Codex Cursor +1 5,600installs api-design affaan-m Provides REST API design standards covering resource naming, status codes, pagination, and error payloads. Use it when creating or auditing API contracts. Claude Code CX Codex Cursor +1 5,500installs rust-testing affaan-m A skill for writing Rust tests: unit, integration, async, property-based, mocks and coverage. Useful when the project runs on TDD. Claude Code CX Codex Cursor +1 5,500installs laravel-security affaan-m This skill reviews Laravel authentication, Eloquent safety, CSRF, XSS, APIs, and production settings. Use it for security reviews or deployment checks. Claude Code CX Codex Cursor +1 5,400installs

Similar

Questions about product-capability

How do I install product-capability in Claude?

Run npx skills add affaan-m/ECC --skill product-capability -a claude-code. The skill lands at ~/.claude/skills/product-capability/SKILL.md.

What does product-capability do?

It translates product intent into an implementation plan: constraints, invariants, interfaces, non-goals and open questions. You get one reusable artifact instead of scattered notes.

Which platforms does the skill support?

Claude, Codex, Cursor, GitHub Copilot, Gemini CLI and OpenCode. Each has its own install command, for example npx skills add affaan-m/ECC --skill product-capability -a cursor.

Source text

SKILL.md · MIT
---
name: product-capability
description: 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.
metadata:
  origin: ECC
---

# 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, say so clearly instead of smoothing it over.
- Prefer one reusable capability artifact over scattered ad hoc notes.

## Inputs

Read only what is needed:

1. Product intent
   - issue, discussion, PRD, roadmap note, founder message
2. Current architecture
   - relevant repo docs, contracts, schemas, routes, existing workflows
3. Existing capability context
   - `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
4. Delivery constraints
   - auth, billing, compliance, rollout, backwards compatibility, performance, review policy

## Core Workflow

### 1. Restate the capability

Compress the ask into one precise statement:

- who the user or operator is
- what new capability exists after this ships
- what outcome changes because of it

If this statement is weak, the implementation will drift.

### 2. Resolve capability constraints

Extract the constraints that must hold before implementation:

- business rules
- scope boundaries
- invariants
- trust boundaries
- data ownership
- lifecycle transitions
- rollout / migration requirements
- failure and recovery expectations

These are the things that often live only in senior-engineer memory.

### 3. Define the implementation-facing contract

Produce an SRS-style capability plan with:

- capability summary
- explicit non-goals
- actors and surfaces
- required states and transitions
- interfaces / inputs / outputs
- data model implications
- security / billing / policy constraints
- observability and operator requirements
- open questions blocking implementation

### 4. Translate into execution

End with the exact handoff:

- ready for direct implementation
- needs architecture review first
- needs product clarification first

If useful, point to the next ECC-native lane:

- `project-flow-ops`
- `workspace-surface-audit`
- `api-connector-builder`
- `dashboard-builder`
- `tdd-workflow`
- `verification-loop`

## Output Format

Return the result in this order:

```text
CAPABILITY
- one-paragraph restatement

CONSTRAINTS
- fixed rules, invariants, and boundaries

IMPLEMENTATION CONTRACT
- actors
- surfaces
- states and transitions
- interface/data implications

NON-GOALS
- what this lane explicitly does not own

OPEN QUESTIONS
- blockers or product decisions still required

HANDOFF
- what should happen next and which ECC lane should take it
```

## Good Outcomes

- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
- Engineering review has a durable artifact instead of relying on memory or Slack context.
- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.

© affaan-m · MIT · affaan-m/ECC

See also

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor