eliteforge-prd-generator

What this skill does

# PRD Generator

Use this skill to turn a rough product idea into a concise, searchable PRD. Prefer direct, decision-oriented writing. The PRD is the product fact source for later feature delivery, not a duplicate brainstorming memo.

## Environment Variables

- `ELITEFORGE_SKILL_PRD_OUTPUT_PATH` [optional] Default Typst source output path for the PRD when the user does not explicitly provide one.

## When To Use This Skill

- A new product or feature needs a formal PRD
- A broad idea needs product-level scope, priorities, and user goals
- The team needs a stable product input before design clarification or feature planning
- An existing PRD needs to be tightened, simplified, or updated

## Output Path

Resolve the Typst source path in this order:

1. explicit user-provided path for the current task
2. `ELITEFORGE_SKILL_PRD_OUTPUT_PATH`
3. `<project>/docs/prd.typ`

Normalize the resolved path as follows:

- if it is a directory, write `<that-directory>/prd.typ`
- if it is a file path without a `.typ` suffix, keep the basename and append or replace the suffix with `.typ`
- create missing parent directories before writing

After writing the Typst source, export a sibling PDF with the same basename in the same directory. Do not write `prd.md`.

## Operating Rules

- Inspect local context first when relevant: existing docs, product notes, adjacent PRDs, specs, and feature folders
- Ask only for missing product decisions that materially change scope, priority, or sequencing
- Draft early, revise until decisions are stable, then write the Typst source to the resolved path
- Use `assets/prd-template.typ` as the starting structure when creating a new PRD
- Use `prd.typ` as the source of truth and export a sibling PDF in the same directory
- Keep the PRD compact but implementation-ready: every selected feature must expose enough functional, page, rule, exception, and acceptance detail for downstream feature specs
- Do not duplicate implementation detail, test plans, or long design prose
- Do not create relationship explosion; keep only dependencies that change scope, priority, or sequencing
- Use searchable headings. A downstream agent must be able to locate one feature, page, rule, exception, or acceptance slice with `rg` by heading text instead of loading the whole PRD
- Do competitor research only when the user asks for it or it materially changes positioning, scope, or priority
- If Typst compilation is unavailable or fails, report the blocker instead of claiming PDF output
- End at a stable PRD; follow-up design clarification and implementation planning belong to later workflows

## Template Contract

Use `assets/prd-template.typ` as the canonical PRD structure. Keep all top-level sections unless the topic is explicitly not applicable, and replace placeholder rows with concrete product facts before final output.

Preserve the template's searchable heading prefixes:

- `Module:`
- `Feature:`
- `Page:`
- `Interaction:`
- `Rule:`
- `Exception:`
- `Acceptance:`

Use business terms after those prefixes. Do not hide feature names in prose-only paragraphs or generic headings such as `Details`.

## Content Boundaries

Avoid repeating the brainstorming artifact.

- Brainstorming owns why this is needed, alternatives considered, rejected options, and unresolved design choices.
- PRD owns what the product must do: functional requirements, entry points, page behavior, business rules, exceptions, boundaries, acceptance, dependencies, and order.

Rules:

- If the feature has no UI, keep the page section concise and name the API, job, event, or integration entry point.
- Business rules must be precise enough for backend service, database, API, and test design; do not bury them inside page copy.
- Exception coverage must include realistic empty, denied, invalid, stale, duplicate, upstream failure, timeout, partial success, and boundary cases when they can occur.
- Shared requirements are only real cross-feature needs such as auth, roles, audit, search, notifications, shared data model, or shared workflow infrastructure.
- Feature inventory should usually contain 3-7 bounded features, each pointing back to its source feature/page/rule/exception headings.
- Dependency map records only direct blocking dependencies; `A --> B` means `B depends on A`.
- Acceptance is product-level completion, not test cases and not `AC-*`.