trogonstack/trogonstack-product-requirements

Produce the initial set of Feature Requirements Documents (FRDs) for a new project. Calibrates between an agile first pass (small set of must-have features only) and a waterfall first pass (comprehensive coverage). Asks how many features to draft, identifies them from the project's product overview, and scaffolds each via the FRD template. Use when the user is starting a project and there are no FRDs yet.

Review Feature Requirements Documents (FRDs) (single file or full tree) against the Overview / Terminology / Requirements template, source-of-truth rules, module boundaries, downstream impact, and the parent-delivers-value rule for sub-features. Writes a review file. Use when the user asks to review, audit, or sanity-check a feature spec.

Split, merge, or nest Feature Requirements Documents (FRDs) using the parent-delivers-value rule where a parent feature must deliver value on its own and a child must be meaningless without the parent. Promotes parent files into directories, scaffolds child FRDs with appended prefixes, and rewrites the parent into an umbrella. Use when an FRD has grown too large or when multiple FRDs should be combined.

Draft a Feature Requirements Document (FRD) using the Overview / Terminology / Requirements template, Product Overview context, source-of-truth checks, and REQ-[PREFIX]-NNN / AC-[PREFIX]-NNN.N acceptance criteria. Supports nested sub-features with appended prefixes. Use when the user wants to spec a feature for engineering to build.

Draft the Business Problem of a PRD by framing the core problem the product addresses, the gaps in today's tools and processes, and why change is necessary now. Drives discovery through who experiences the pain, what fails today, and the cost of inaction. Writes to .trogonai/project/{projectid}/prd/business-problem.prd.md. Use when the user wants to write, refine, or audit the problem framing of a product or feature.

Draft the Current State of a PRD by documenting the status quo the product improves upon. Drives discovery through what users do today, the workarounds in use, the costs of the status quo, and the alternatives that already exist. Writes to .trogonai/project/{projectid}/prd/current-state.prd.md. Use when the user wants to document the baseline before proposing a change.

Draft an additional Product Overview Document beyond the six defaults when a product-specific context area is needed. Keeps custom PRDs at product-level why/what, prevents duplicate default sections, and writes to .trogonai/project/{projectid}/prd/{slug}.prd.md. Use when the user needs a custom overview document rather than a feature requirement.

Initialize a new project with the six default Product Overview Documents (business problem, current state, personas, product description, success metrics, technical requirements). Scaffolds stubs and walks the user through running each section skill in priority order. Use when the user is starting a project and there are no PRD files yet.

Draft the Personas of a PRD by defining the users, their goals, and what success looks like for them. Drives discovery through who the users are, the jobs they are trying to do, their constraints, and the per-persona definition of success. Writes to .trogonai/project/{projectid}/prd/personas.prd.md. Use when the user wants to define or sharpen who the product is for.

Draft the Product Description of a PRD by describing what the product is and how its parts fit together. Drives discovery through the one-liner, the user-facing surfaces, the major components, how they interact, and the boundaries of what the product is not. Writes to .trogonai/project/{projectid}/prd/product-description.prd.md. Use when the user wants to describe the product shape without diving into requirements.

Review Product Overview Documents for completeness, clarity, source-of-truth conflicts, module-boundary drift, and likely downstream FRD / Blueprint / Work Order impact. Reads the default and custom files under .trogonai/project/{projectid}/prd/ and writes a review. Use when the user asks to review, audit, critique, or sanity-check a PRD.

Draft the Success Metrics of a PRD by defining the key metrics used to measure success. Drives discovery through the primary outcome metric, leading indicators, guardrail metrics that must not regress, and the instrumentation source for each. Writes to .trogonai/project/{projectid}/prd/success-metrics.prd.md. Use when the user wants to define how success will be measured before building.

Draft the Technical Requirements of a PRD by capturing the technical constraints and requirements the product must meet. Drives discovery through performance, scale, reliability, security, privacy, compliance, integrations, platforms, accessibility, and localization. Writes to .trogonai/project/{projectid}/prd/technical-requirements.prd.md. Use when the user wants to capture the non-functional and platform constraints engineering will design against.

Apply the shared Requirements operating model across product-requirements skills: Requirements / Blueprints / Work Orders boundaries, single source-of-truth ownership, TrogonStack ask-question-compatible clarification, Product Overview / FRD scope, feature hierarchy, and downstream impact. Use alongside PRD or FRD writing, review, split, or getting-started work when cross-document consistency, ambiguity, or module handoff matters.