eliteforge-prd-generator

name	eliteforge-prd-generator
description	Draft or refine a concise product requirements document from a rough product idea, then write a Typst source file and sibling PDF to a resolved output path.
metadata	{"version":"1.0.1"}

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-*.