product-definition-builder
Product Definition Builder
Installed Commands
Resolve <product-definition-builder-skill-root> to the absolute directory containing this installed SKILL.md. Resolve sibling skill roots from the same installation (normally ~/.agents/skills/). Quote script paths, keep the working directory and --repo-root at the target project, and never assume that project contains skills/. In references, skills/<name>/scripts/, <name>/scripts/, and bare scripts/ are logical installed-skill paths: expand them to the observed absolute skill root before execution. Repository maintenance and CI commands still run from this source repository.
Overview
At every invocation, apply ../delivery-harness/references/document-sync-contract.md. For accepted enhancement delivery, use ../delivery-harness/references/bounded-enhancement.md: preserve the current PRD and IDs, reuse decisions already made, and avoid repeated approval for same-scope implementation repairs. A genuinely changed product decision is a next-round contract gap, not permission to forge approval.
For a UI enhancement, hand off the added/changed UI IDs and necessary entry or return paths, with all other surfaces explicitly preserved. Follow ../ui-design-builder/references/enhancement-recommendations.md's Incremental UI Scope for the downstream boundary; do not request a fresh all-screen design package or reset unaffected approvals. Select the Epic or small-fix record before implementation using the shared bounded-enhancement rule.
Before approval, define test personas (role, tenant, account/data state), applicable Web/native/agent journeys, observable success and denial/no-side-effect assertions, and mock versus real-sandbox obligations in the existing TEST rows and architecture testing section. Record non-applicability rather than inventing login for a headless or unauthenticated product. The downstream Harness freezes the executable matrix and owns fixtures and evidence through ../delivery-harness/references/delivery-acceptance-contract.md; this skill creates no accounts or evidence register.
Use this skill to turn a product idea into a decision-ready package, not an agent-selected implementation guess. Define product scope, journeys, UI surface responsibilities, routes, actions, states, data, trust, and security boundaries, acceptance signals, implementation architecture, release targets, and technology constraints. Draft and reconcile PRD.md, architecture.md, and stack-decisions.md; present coherent frontend, backend/data/auth, mobile/desktop, AI, deployment, and commercial technology options; then obtain an explicit Stack Decision Checkpoint and Product Definition Approval. Stop there. A later explicit UI request invokes ui-design-builder; a later implementation request invokes delivery-harness against approved inputs.
Apply Generate, Verify And Correct at Product checkpoints. The author repairs accepted-scope defects and reruns the focused check; the owner supplies human approvals and contract changes.