# Product Capability

> Load when accepted product intent must become a concise, implementation-ready local capability specification with explicit constraints, non-goals, test seams, and unresolved decisions.

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

---


# Product Capability

Turn accepted product intent into a local engineering contract. This Skill specifies one capability; it does not own implementation, ticketing, or delivery.

Use `grill-me` first when consequential decisions remain. Use `grill-with-docs` when this work creates or changes a durable specification so the same decision graph is reconciled with repository evidence.

## Inputs

Read only relevant sources:

- accepted source facts from the user, current task, issues, PRDs, or roadmap notes
- existing behavior, tests, schemas, interfaces, and durable docs
- project instructions and ownership/security/rollout constraints

Do not invent product truth. Label an inference or unresolved decision instead of smoothing over missing evidence.

## Specification

Write the smallest artifact that makes implementation unambiguous:

```text
CAPABILITY
- actor, new behavior, and observable outcome

ACCEPTED SOURCE FACTS
- source anchor and fact

CONSTRAINTS
- invariants, ownership, trust, lifecycle, failure, migration, and rollout rules

INTERFACES
- inputs, outputs, states, errors, side effects, and compatibility boundaries

TEST SEAMS
- public behaviors and deterministic evidence that will prove acceptance

OUT OF SCOPE
- explicit non-goals and rejected expansion

OPEN DECISIONS
- unresolved choices that can still change implementation or acceptance

HANDOFF
- ready for implementation, needs alignment, or needs focused design review
```

Prefer updating the project's existing canonical spec or planning location. Do not create a new planning stack when the repository already owns one.

## Quality Gate

The result is ready only when:

- every required behavior traces to accepted source facts
- boundaries and failure behavior are explicit
- test seams demonstrate user/caller-visible outcomes rather than private structure
- non-goals prevent likely scope drift
- contradictions with current implementation are surfaced
- a competent implementer can proceed without rediscovering hidden product decisions

Use `to-tickets` only when the accepted spec needs project-owned execution slices. Do not publish an issue, apply a label, or mutate a remote tracker from this Skill.