feat(skills): add product-expert roadmap-audit + spec-review strategist

A standalone, self-triggering skill that acts as Relicario's product
strategist: audits the roadmap and reviews freshly-brainstormed release
specs for product/market fit, emitting PM-ready relay directive blocks.
Advisory only — the user stays the decision-maker.

- Two modes: roadmap audit (default) and spec review (verdict:
  PROCEED / RESCOPE / CUT / PIVOT).
- Four-lens engine run as parallel subagents: ground-truth (verify
  claims vs code/git, distinguishing an in-flight lift from real drift),
  jobs-to-be-done, market/competitive, and strategy synthesis.
- Fast by default; `deep` adds live competitive web research.
- Durable by design: lenses read living docs (README/ROADMAP/STATUS/
  CHANGELOG/specs) at runtime, so new surfaces/segments/features are
  picked up automatically. The one static asset, competitive-landscape.md,
  carries a last-reviewed date + freshness protocol.
- Wires a post-brainstorm product gate into CLAUDE.md's Planning section.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQbgrP6KQW5pibjbPEoTSs

.claude/skills/product-expert/references/output-templates.md

@@ -0,0 +1,94 @@
+# 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.