AI agent skill · by @JasonxzWen

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.

Archived 2026-10-23 · Source updated 2026-07-23 · License: MIT. Check the original repository for the latest version.

SKILL.md instructions

# 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.