# Output templates

Use these verbatim in structure. Fill the brackets. Keep prose tight — the user
reads this to make a decision, not to admire it. Lead with the highest-leverage
point in every section.

---

## Roadmap-audit output

```markdown
# Product Audit — Relicario — [YYYY-MM-DD] · [fast | deep]

## Reality check
[One paragraph: where the product *actually* stands, reconciled against code +
git, not the docs' self-description.]

**Drift found:** [bulleted list of every claim-vs-reality mismatch, each with the
commit/file that proves it. Write "none — docs match reality" if clean.]

## Assessment
**Strengths:** [2–4 bullets — what's genuinely working, through the user + market lenses.]
**Gaps:** [2–4 bullets — table-stakes misses, friction, parity gaps.]
**Risks:** [1–3 bullets — what could undermine the product or the thesis.]

## Recommendations
[Leverage-ordered. Highest-impact first. Each line:]
- **[ADD|CUT|REORDER|PIVOT]** — [the move]. *Why:* [one line]. *Impact/Effort:* [H/M/L · H/M/L]. *Risk:* [one line].

## PM brief
[The paste-ready block — see "PM brief block" below.]
```

---

## PM brief block

This is what the user pastes to their PM (the relay entry point). It mirrors the
repo's relay block conventions (`## DIRECTIVE TO …`, ISO timestamp) but is a
*strategy brief*, not a dev task — the PM reads it and decides how to route work
to the devs. Keep it self-contained: the PM may act on it without the full audit.

```markdown
## PRODUCT DIRECTIVE TO PM
Time: [ISO-8601 local timestamp]
Source: /product-expert roadmap audit ([fast|deep])

Reality note: [one line — any drift the PM must know before acting, e.g. "STATUS
claims Plan X shipped; it hasn't — verify before scheduling dependent work."]

Roadmap changes (in priority order):
1. [ADD|CUT|REORDER|PIVOT] [the move] — [one-line why].
2. …

Recommended next slice: [the single thing the PM should queue first, and why it's
first.]

Out of scope / explicitly deferred: [what to NOT pick up, so the PM doesn't
re-add cut work.]
```

The user edits this before relaying. Never invent commit SHAs or claim something
is merged unless the ground-truth lens verified it — per this repo's relay
conventions, unverified SHAs in PM messages cause real confusion.

---

## Spec-review output

```markdown
# Spec Review — [spec filename] — [YYYY-MM-DD] · [fast | deep]

## Verdict: [PROCEED | RESCOPE | CUT | PIVOT]
[One sentence stating the call plainly.]

## Rationale
- **User job:** [does it serve a real job for a real segment? which?]
- **Positioning fit:** [does it strengthen or dilute the wedge?]
- **Opportunity cost:** [what does building this displace on the roadmap? is that
  trade worth it?]
- **Scope:** [right-sized, gold-plated, or under-built? cite the YAGNI risks.]

## [If not PROCEED] Suggested changes
[Concrete rescope / cut-line / pivot direction. Be specific enough that the next
step is obvious.]

## Next step
[If PROCEED: "Spec holds up — proceed to writing-plans." Otherwise: "Revise the
spec per above, then re-review or proceed."]
```

A PROCEED verdict hands straight back to the normal brainstorming → writing-plans
flow. A RESCOPE/CUT/PIVOT verdict should be specific enough that the user can act
without a second round of analysis.