Product docs: PRDs and specs

Where product docs live

Iterel does not add a separate PRD tool or destination. A product document attaches to the work object at its natural granularity:

• Project → living context and Project Map specs.
• Mission → one PRD.
• Task → its spec.

Each layer owns a size. The PRD is intent, the spec is the per-task contract, and the board is live state. The links between them are provenance and prompt context, not a live two-way sync.

Mission PRD

Open a mission's ⋯ menu and choose Create PRD. Iterel generates a structured document — overview, goals, users, requirements, success metrics, scope and milestones, risks and edge cases, open questions — grounded in the mission, the tasks already under it, and living project context. It opens in the artifact reader, streams as it writes, and saves to Assets with tool provenance.

A mission has at most one PRD; choosing Create PRD again opens the existing one. A failed generation shows a Retry action. Refine the PRD with a prompt like any artifact, and Update PRD from tasks folds the current task ledger back into it.

PRD → tasks

From a ready PRD, Generate tasks proposes a bounded set of directly actionable tasks — each with a title, type, priority, Fibonacci effort, impact, objective, and a seeded spec. Review the proposals, edit or exclude any, then Create. Approved tasks land in the mission's board lane with the seeded spec and a context link back to the PRD. Nothing is created until you approve it, and a partial failure rolls back only the tasks it created, never the mission.

This is the loop other stacks split across a document tool and a tracker: the same PRD that states the intent produces the tasks an engine then executes.

Task spec

A task's Spec section holds its user story, acceptance criteria, spec with edge cases, and notes. Generate spec fills empty spec kinds from the mission PRD and living context; overwriting an existing spec asks first. Specs stay editable and flow into engine runs untouched.

Coach review

Coach review runs a product-lead critique on any ready document — gap analysis against the intended coverage, ambiguity and testability notes, missed edge cases, concrete rewrites, and next questions. It adds or replaces exactly one coach-review section and leaves every other section byte-stable, so re-running is safe and the revision history stays clean.

Into the engine loop

When a task belongs to a mission with a PRD, the PRD is folded into the Build prompt alongside the task spec and project context. A round implements against the mission's stated goals, requirements, and non-goals, and flags conflicts in its receipt instead of silently deviating. A task without a PRD runs exactly as before; runs never depend on a PRD existing.