goga-define-prd

goga-define-prd

Purpose

Generate the final Product Requirements Document from the validated product definition.

Transform the complete, conflict-free product context into a single PRD that can be handed to engineering as the product source of truth for technical design.

The PRD must preserve the decisions made during the definition process without introducing new product decisions.

Contract

consume:
  - product
  - problem
  - users
  - goals
  - user_experience
  - requirements
  - constraints
  - scope
  - success_criteria

produce:
  - prd

Core Principle

The PRD is a representation of decisions that have already been made.

This skill is not a product-design stage.

Do not:

• invent missing requirements;
• redesign the user experience;
• introduce new goals;
• expand scope;
• choose technical solutions;
• resolve contradictions.

If the context is not sufficiently complete or internally consistent, report the issue to the orchestrator instead of generating a misleading PRD.

Preconditions

Before generating the PRD, verify that:

• the problem is defined;
• relevant users are identified;
• goals are established;
• user experience is defined;
• requirements are explicit;
• constraints are known;
• scope is defined;
• success criteria are established;
• no unresolved conflicts remain.

If any of these conditions is not satisfied, do not generate the final PRD.

PRD Structure

The PRD must be generated as a Markdown document with the following structure:

# <Product Change Title>

## Problem

## Users

## Goals

## User Experience

## Requirements

## Constraints

## Scope

### In Scope

### Out of Scope

## Success Criteria

Use additional subsections when they improve clarity, but do not introduce unrelated product-management artifacts.

1. Title

Create a concise title that describes the product change.

The title should describe the subject of the change rather than the implementation.