# Product Capability

> Use when a PRD or product intent is clear but the implementation constraints are not — turns a vague capability ask into an engineering-ready plan that exposes invariants, interfaces, and unresolved decisions before any code is written.

- Skill: `pekral/product-capability` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pekral/product-capability`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pekral/product-capability/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- License: MIT
- Author: pekral (https://skillmd.com/u/pekral)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/pekral/product-capability

---


## Constraints
- Apply `@rules/laravel/architecture.mdc` — actors, surfaces, states, and data model must fit the existing layers (Action → ModelService → Repository / ModelManager), not invent new abstractions.
- Apply `@rules/compound-engineering/general.mdc` — the plan is a durable artifact the next agent reuses, not throwaway prose.
- Apply `@rules/compound-engineering/general.mdc` *Assign the most relevant existing label when creating a tracker issue* for any tracker issue this plan creates or hands off to `@skills/create-issues-from-text/SKILL.md` to create.
- Do not invent product truth. Every unknown is an explicit open question, never a silent assumption.
- Separate user-visible promises from implementation detail. Keep them in distinct sections.
- Mark each constraint as **fixed policy**, **architectural preference**, or **open question** — never blur the three.
- Do not write code. The output is a plan, not an implementation.
- Use one language only. English here.

## Use when
- A PRD exists but the implementation constraints stay implicit.
- The capability spans multiple surfaces or services and needs one contract.
- The product vision is clear yet its architectural implications are not.
- Engineering reviews keep surfacing the same hidden assumptions.

The gap is not "what should we build?" but "what exactly must be true before implementation starts?".

## Execution

Walk these four steps in order. Each feeds the next.

1. **Restate the capability precisely.** Compress the ask into one statement covering the **user** (who gains the ability), the **new ability** (what they can now do), and the **outcome change** (what is true after that was not before). If you cannot fill all three, that is the first open question.

2. **Extract the constraints.** Surface what must hold regardless of design:
   - business rules the capability must obey,
   - scope boundaries (in scope vs explicitly out),
   - invariants that must never break,
   - trust boundaries and data ownership (who owns and may read/write the data; account scoping per `@rules/laravel/architecture.mdc`),
   - lifecycle and state transitions,
   - rollout / migration requirements.
   Tag every item as fixed policy, architectural preference, or open question.

3. **Define the implementation contract.** Make the capability concrete enough to hand off:
   - **actors** — users, roles, systems that act,
   - **surfaces** — entry points (HTTP, Livewire, command, job, listener),
   - **states** — the state machine and allowed transitions,
   - **interfaces** — Action inputs/outputs and the boundary contract,
   - **data model** — entities, ownership, and account scoping implications.
   Keep the contract aligned with the existing architecture; flag any place where it would force a new layer.

4. **Translate into execution readiness + handoff.** Decide the readiness level and route the work:
   - **Ready to implement** → hand to `@skills/blueprint/SKILL.md` for a multi-PR plan, or to `@skills/create-issues-from-text/SKILL.md` to break it into tracker issues.
   - **Needs architecture review** → route the data-model / layering questions through `@rules/laravel/architecture.mdc` before planning.
   - **Needs product clarification** → list the open questions that block a contract; stop until they are answered.

## Output

Write the plan to a durable file (`PRODUCT.md` at the repo root, or a `docs/` capability doc) so the next agent picks it up — per `@rules/compound-engineering/general.mdc`. State the file path in your reply. Use exactly these sections:

1. **Capability restatement** — user, new ability, outcome change (one paragraph).
2. **User-visible promises** — what the user is guaranteed to experience. No implementation here.
3. **Constraints** — the step-2 list, each tagged fixed policy / architectural preference / open question.
4. **Implementation contract** — actors, surfaces, states, interfaces, data model (step 3).
5. **Non-goals** — what this capability explicitly does not cover.
6. **Open questions** — every unresolved decision that blocks or shapes implementation, with who must answer it.
7. **Handoff** — the readiness level and the named next step (`blueprint`, `create-issues-from-text`, or architecture review).

Fill every section. If a section has nothing, write an explicit note (e.g. `No non-goals identified.`) rather than leaving it blank.

## Done when
- The capability is restated with all three of user, ability, and outcome change.
- Every constraint is tagged fixed policy, architectural preference, or open question.
- User-visible promises are separated from implementation detail.
- The implementation contract fits the existing architecture, or each deviation is flagged.
- All open questions are listed, none disguised as assumptions.
- The plan is written to a durable file and the handoff names a real next step.