Use case · Product

PRDs from a five-question intake

One structured intake, one synthesis, one verify pass. User stories, interface copy, scope table, decision log and acceptance cases — in your template, in minutes. Asset-risk side effects are written as hard rejections.

Hedy writes PRDs as a governed, on-premise AI employee, not a cloud assistant. It runs a five-question intake, synthesizes a structured §0-6 draft, switches to engineering mode to fill technical contracts, then to review mode to challenge gaps. Any action that risks real assets — deleting docs, overwriting tickets, mass-messaging — hits a default-deny whitelist and hard-refuses. One Hedy owns the whole PRD workflow, self-hosted, with append-only audit and cited sources.

Last updated: 20 July 2026

How Hedy runs it

01

Five questions

Problem, entry point, minimal scope, touched systems, references. One round, most of the signal.

02

Full synthesis

From background through acceptance cases — with scope stated as "we will not build" pairs, each with a reason.

03

Engineering mode

On request: auth chains, error codes, idempotency and transaction boundaries — checked against a hard list.

04

Review mode

Point Hedy at an existing PRD and get findings ranked by severity, referenced by section.

Governed by design

  • Asset-risk side effects must be hard rejections in the spec — a house rule
  • Lessons from each review append to the skill and survive upgrades
  • Documents file to your space; nothing is shared externally

In depth

Most AI writing tools stop at drafting prose. Hedy runs the full PRD workflow as one employee. It opens with a five-question intake — problem, user, scope, constraints, success metric — instead of guessing. Then it synthesizes a structured document across §0-6: context, goals, users, scope, functional requirements, non-goals, and open questions. The output is a real PRD skeleton your team can review, not a wall of text. One Hedy covers what an intake PM, a spec writer, and a reviewer used to split.

The work runs in modes. In synthesis mode Hedy assembles §0-6 from the intake answers. In engineering mode it fills the technical contract — data shapes, API surfaces, edge cases, dependencies, rollout constraints — so the spec is buildable, not aspirational. In review mode it turns adversarial: it re-reads its own draft, flags missing non-goals, ambiguous acceptance criteria, and unstated assumptions. Because Hedy is self-hosted on your infrastructure with your own model keys (including local vLLM or Ollama), the whole PRD never leaves your network and there are no sub-processors.

Governance is the product, not a setting. When PRD work touches real assets — deleting a Confluence page, overwriting a Jira epic, mass-messaging a channel — Hedy does not proceed. Write operations run default-deny against a whitelist, so any unlisted side-effect is a hard refusal, not a soft warning it can be talked out of. This limit lives in config and code, not in a prompt, so it cannot be prompt-injected away. Retrieval respects the asker's ACL, so a PRD assembled for one requester never surfaces documents they can't see.

Every step is accountable. Actions land in an append-only audit log — no edit, no delete endpoint. Higher-risk operations pass through L0/L1/L2 approval tiers, and Hedy's evidence gate requires that factual claims in the PRD are cited verbatim to their source, so requirements trace back to the interview answer or document they came from. Feishu/Lark is a first-class surface alongside Slack, and the deployment is a ~30-minute Docker Compose install licensed per seat with an offline Ed25519 license.

Questions

How does Hedy write a PRD without me feeding it a full brief?
Hedy starts with a five-question intake covering problem, user, scope, constraints, and success metric. It uses those answers to synthesize a structured §0-6 document rather than guessing. If a section lacks enough input, review mode flags it as an open question instead of inventing content, so gaps stay visible.
What are the engineering mode and review mode in Hedy's PRD flow?
Engineering mode fills the technical contract — data shapes, API surfaces, edge cases, dependencies, and rollout constraints — so the spec is buildable. Review mode is adversarial: Hedy re-reads its own draft to flag missing non-goals, ambiguous acceptance criteria, and unstated assumptions before you hand it to a team.
What happens if writing a PRD requires deleting or overwriting something?
Hedy hard-refuses. Write operations run default-deny against a whitelist, so any side-effect touching real assets — deleting docs, overwriting tickets, mass-messaging — is blocked unless explicitly allowed. That limit lives in config and code, not a prompt, so it can't be prompt-injected away, and higher-risk actions still route through L0/L1/L2 approval.
Does the PRD content stay inside my company?
Yes. Hedy is self-hosted on your own infrastructure (Docker, K8s, or air-gapped) and uses your own model keys, including local vLLM or Ollama. There are no sub-processors, retrieval respects each asker's ACL, and every action lands in an append-only audit log for full traceability.

Related

hedy.one

See it on your own infrastructure.

Book a demo