skills/product-requirements/SKILL.md

Rama main · réplica de lectura del repositorio original.

---
name: product-requirements
description: Turn an app idea or feature request into an implementable product contract. Use when requirements are vague, contradictory, broad, or missing acceptance criteria; do not use for a narrowly specified code change.
---

# Product Requirements

Convert intent into a buildable slice without inventing a different product.

## Establish the contract

Before implementation, identify:

- the user and the job they are trying to complete;
- the observable outcome, not merely the requested component;
- the primary path and the most consequential failure paths;
- data created, changed, exposed, or deleted;
- roles and permissions;
- integrations and deployment constraints already present;
- explicit non-goals;
- decisions that genuinely require the user.

Inspect the repository before asking questions. Existing routes, schemas, components, conventions, and tests often answer them.

## Slice the work

Prefer the smallest vertical slice that delivers a complete user outcome. A vertical slice includes the necessary UI, behavior, persistence, error handling, and verification. Do not call a disconnected mock UI a finished feature unless the user requested a prototype.

Separate verified facts, reasonable assumptions that preserve scope, and unresolved decisions whose alternatives materially change behavior. Ask only about unresolved decisions that are unsafe to infer.

## Acceptance criteria

Write criteria as observable behavior. Include loading, empty, validation, permission, dependency-failure, retry, and cancellation states when relevant. Name compatibility expectations and the evidence that will prove completion. Avoid criteria such as “looks modern,” “works correctly,” or implementation trivia.

## Guardrails

- Preserve explicit technology, design, and scope choices.
- Do not invent pricing, legal policy, business rules, credentials, analytics claims, or production data.
- Distinguish prototype behavior from production behavior.
- If a request spans independent products, sequence complete slices rather than beginning all of them.
- End planning with outcome, in-scope behavior, non-goals, assumptions, acceptance criteria, and verification.