Agent PRD

A PRD says what and why, never how (that's the tech spec). For an agent product, two sections that are optional elsewhere are mandatory here: the agent success definition and the eval + monitoring strategy — because an agent's output is non-deterministic, so "is it working?" is itself a measurement problem you must define before building.

A requirement is not complete until it carries the eval that proves it. This is the load-bearing rule of an agent PRD: vague success criteria ("users are happy", "it works well") are not requirements, they're wishes. Every core requirement in this PRD must name at least one concrete, gradable acceptance eval. If you can't write the eval, you don't yet understand the requirement — either sharpen it or cut it. These acceptance evals are the seed that the data-and-evals step (data-and-evals) expands into the full eval set; they are not duplicated work, they are the same asset started early.

Conventions

Follow _conventions.md (read-first order, docs/ vs artifacts/, don't-clobber guard).

Before you start

Read PROJECT.md and artifacts/brainstorm.md if they exist. Pull the core task, autonomy level, and failure costs from there rather than re-asking. Fill gaps from PROJECT.md; only ask the user about things neither file answers.

Two modes — pick based on PROJECT.md stage

• Thin (stage = prototype): write only sections 1–4 below. Just enough to know the core task so a prototype can de-risk it. Don't over-invest before feasibility is proven.
• Full (stage = building MVP): all sections.

State which mode you're using in one line at the top of the output.

Sections

ALWAYS use this template:

# PRD — [product] (mode: thin|full)

## 1. Problem & users
Who, what pain, how they solve it today.

## 2. Goals & non-goals
Bullets. Non-goals are as important as goals — they prevent scope creep.

## 3. The core agent task
The one or two tasks the agent must perform. Concrete input → expected outcome.

## 4. Agent success definition        <- MANDATORY
- What "works" means concretely (not "users are happy").
- Target task success rate.
- Autonomy: when unsure, does it stop-and-ask or proceed? (pull from PROJECT.md)
- Unacceptable failures — hard lines it must never cross.

## 5. Requirements & acceptance evals  <- MANDATORY (both modes)
List the core requirements. For EACH requirement, one or more acceptance eval cases:
  - id (e.g. R1-a), and the requirement it proves
  - input / scenario (a concrete task, not a category)
  - expected agent behavior / outcome
  - grading: deterministic (right tool? valid output? under budget?) |
    rubric (LLM-judge) | human
A requirement with no acceptance eval is INCOMPLETE — write the eval or cut the
requirement. These cases seed the data-and-evals step; keep them in a form it can lift directly.

## 6. Eval strategy                    <- MANDATORY (full mode)
- What you'll measure quality against, beyond the per-requirement acceptance evals.
- Which checks are deterministic vs. judgment-based (LLM-judge or human).
- Offline (before shipping a change) vs. online (sampled from real traffic).
- Note: the full harness gets built in the data-and-evals step; §5 is its seed, §6 is its shape.

## 7. Monitoring requirements          <- MANDATORY (full mode)
- What must be observable in production: task success/failure, tool error rate,
  fallback/escape-hatch frequency, cost per task, latency.
- State plainly: every agent run must be fully traced (a design constraint in system-design and data-and-evals).

## 8. Scope & milestones
MVP boundary. What's explicitly deferred past v1.

## 9. Open questions

Principles

• Keep it tight. A solo founder's PRD is a thinking tool, not a deliverable for a committee.
• If the agent takes real-world actions (per PROJECT.md), section 4's unacceptable-failures and section 7's monitoring must be heavier — high-autonomy agents need guardrails specified here, not discovered later.
• Make the user the decision-maker. Where two scopings are defensible, present both and ask.
• Every unacceptable failure in §4 should have a matching acceptance eval in §5 that proves the agent does NOT do it. A hard line with no eval is unenforceable.

Output

Write artifacts/prd.md (apply the don't-clobber guard).

Then hand off to the stress-test gate. A drafted PRD is not an approved PRD. The next stage is agent-prd-gate, which runs the PRD Review Panel against this artifact. The pipeline does not advance to the competitive step until the gate has run and returned go (or the user has recorded per-finding overrides). Do not proceed past this skill by writing competitive/system-design artifacts — stop here and invoke the gate.

End by flagging the riskiest assumption in the PRD, confirming every requirement in §5 carries at least one acceptance eval, and stating that the next step is the agent-prd-gate stress-test.