Iterate PRD

Refine an existing Product Requirements Document without losing its decision history, requirement identity, or relationship to evidence.

Run a decision loop: establish the facts, resolve one product decision, repaint the affected parts of the PRD, validate the result, and return control to the user. A question, objection, or thought-in-progress continues the discussion; it becomes an edit only when the decision is settled.

Keep the work in product space: user experience, observable behavior, scope, and success. Record implementation-only questions under Deferred to TDD unless they expose a product decision.

1. Establish the working set

Resolve the task directory and PRD path from the invocation or conversation. If either is genuinely ambiguous, ask one precise question and wait.

For an .agent-work/tasks/<task> directory, use a symlink-following directory listing such as ls -La; inventorying it with a non-following glob can silently miss its contents. Read every file in the task directory completely, including the PRD, ticket or task, research, design discussion, diagrams, mockups, and later notes. Read every additional path named by the user. Preserve the PRD's path, frontmatter, and established structure.

Apply this authority order when artifacts disagree:

active user decision > PRD > design discussion > research > ticket

An unresolved comment is feedback to evaluate, not an authority that silently overrides the PRD.