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/lenses.md

@@ -0,0 +1,155 @@
+# The four lenses — dispatch prompts
+
+Spawn these as parallel subagents (the `Agent` tool). Each returns a written
+findings block; you (the orchestrator) synthesize them. Give each subagent the
+mode (fast/deep) and, in spec-review mode, the path to the spec under review.
+
+Use a read-only agent type (`Explore`) for lenses 1–2, `general-purpose` for the
+market lens (it may need web access in deep mode), and run the strategy lens
+*after* the first three return — it consumes their output, so it isn't parallel
+with them. Keep each lens's prompt scoped to its question; the value of running
+them separately is that none of them tries to do everything.
+
+---
+
+## Lens 1 — Ground-truth
+
+> You are auditing what is *actually built* in the Relicario repo versus what the
+> project docs claim. This is a reality check, not a code review — do not hunt
+> for bugs.
+>
+> Do this:
+> 1. Read ROADMAP.md, STATUS.md, CHANGELOG.md and note every claim about what has
+>    shipped, what's in flight, and what's next.
+> 2. Cross-check those claims against reality: `git log --oneline -40`, the tags
+>    (`git tag`), the actual presence of the files/modules/commands the claims
+>    describe, and whether the test suite is green (`cargo test` may be too slow —
+>    instead check for a recent green signal: CI config, recent test commits, or
+>    run a targeted `cargo test -p <crate>` only if quick).
+> 3. Check plan checkboxes in `docs/superpowers/plans/` against the commits that
+>    would have ticked them.
+>
+> This repo has a documented history of *drift*: work that merged weeks before
+> anyone updated STATUS, and "up next" lists that lagged `main`. Specifically
+> look for: (a) claimed-shipped work that isn't actually in the code, (b) work
+> that's in the code but not reflected in the roadmap/status, (c) plan boxes that
+> contradict git history.
+>
+> CRITICAL distinction — drift vs. in-flight lift. Docs lagging the code is NOT
+> automatically "drift to fix." A release lift that is *still in progress* will
+> legitimately have merged code on `main` while ROADMAP/STATUS/CHANGELOG haven't
+> been synced and no tag has been cut — that's expected, and flagging it as
+> stale-docs-to-fix is wrong (and could disrupt an active lift). Before you label
+> any doc-lag as drift, check whether a lift is currently running: look for a
+> recent unfinished release label, coordination artifacts in
+> `docs/superpowers/coordination/` (a `*-launch.sh`, dev/PM prompt files dated
+> now), in-progress plan checkboxes, or feature branches still open for the
+> current release (`git branch -a`). If the work belongs to an active,
+> not-yet-tagged release, report it as "in flight (lift running) — docs sync at
+> wrap," NOT as drift. Reserve "drift" for docs that contradict *finished/tagged*
+> reality.
+>
+> Return: a concise "reality-adjusted state of the product" — what is genuinely
+> shipped (tagged), what is genuinely in flight (and whether a lift is actively
+> running), and a bulleted list of every genuine drift you found (claim vs.
+> finished reality, with the commit or file that proves it). Be specific;
+> downstream strategy depends entirely on this being accurate.
+
+---
+
+## Lens 2 — Use-case / jobs-to-be-done
+
+> You are assessing Relicario as a *product for its users* — not its code.
+>
+> Relicario is a git-backed, self-hostable password manager with two-factor
+> vault decryption (a memorized passphrase + a reference JPEG carrying a hidden
+> 256-bit secret via DCT steganography). The server only ever sees ciphertext.
+> Read README.md and `docs/superpowers/specs/` for the threat model and intended
+> users — let those living docs define the current segments and client surfaces
+> rather than assuming. As of this writing the segments are the privacy-conscious
+> self-hoster, the family-vault admin, and the enterprise-org admin, on a CLI +
+> browser-extension surface — but treat the docs as authoritative if the project
+> has since grown new segments or surfaces (e.g. mobile, Safari).
+>
+> Answer:
+> 1. Who is this really for, and what jobs do they hire it for? Map the major
+>    features to the jobs they serve.
+> 2. Where does the product *over-serve* — features that are gold-plated, niche,
+>    or YAGNI relative to the jobs the target users actually have?
+> 3. Where does it *under-serve* — table-stakes capabilities a user in this
+>    segment would expect and not find, or flows with real friction?
+> 4. CLI/extension parity is an explicit design value in this project. Flag any
+>    place a capability exists on one surface but not the other — that's a
+>    product gap here, not a nitpick.
+>
+> Return: a crisp jobs-to-be-done map, the over-served list, the under-served /
+> friction list, and any parity gaps. Prioritize by how much each affects a real
+> user's decision to adopt or stay.
+
+---
+
+## Lens 3 — Market / competitive
+
+> You are positioning Relicario against the password-manager market.
+>
+> Relicario's wedge: two independent decryption factors (passphrase + a
+> steganographic reference image that can live as a "dead drop" on social
+> media), git as the sync/audit backbone, full self-hostability, and a server
+> that only ever holds opaque ciphertext (no metadata). It's GPL and open-source;
+> check README.md / ROADMAP.md for the current release stage, client surfaces,
+> and which tracks (e.g. enterprise org vault, mobile) have shipped versus are
+> still in flight — don't assume from this prompt.
+>
+> Read `references/competitive-landscape.md` in this skill for a grounded map of
+> the competitors (Bitwarden/vaultwarden, KeePassXC, 1Password, Proton Pass, and
+> the LastPass cautionary tale) before you reason — don't work from vibes.
+>
+> {FAST MODE}: reason from that cheat-sheet plus your own knowledge.
+> {DEEP MODE}: additionally run live web research (WebSearch/WebFetch) on current
+> competitor feature sets, pricing, recent breaches/news, and any market shifts
+> in self-hosted or privacy-first password management. Cite what you find.
+>
+> Answer:
+> 1. Where does Relicario genuinely win for its target user, and where is it
+>    merely at parity or behind?
+> 2. Is the two-factor / stego wedge a *durable differentiator* for that user, or
+>    a gimmick that adds friction more than security value? Argue it honestly.
+> 3. What is table stakes in this market that Relicario lacks (e.g. mobile
+>    clients, autofill quality, painless import, secure sharing)?
+> 4. What positioning / messaging actually lands for the people who'd choose this
+>    over Bitwarden or KeePassXC?
+>
+> Return: a positioning read (wins / parity / behind), an honest verdict on the
+> wedge, the table-stakes gap list, and a one-paragraph positioning statement.
+> State whether you ran fast or deep.
+
+---
+
+## Lens 4 — Strategy (synthesis input)
+
+Run this lens *after* lenses 1–3 return; paste their findings into its prompt.
+
+> You are the strategy synthesis for a Relicario product review. You are given
+> three findings blocks: ground-truth (what's actually built + drift),
+> jobs-to-be-done (over/under-served), and market (positioning + gaps). Below
+> them is the current ROADMAP.md "up next" list.
+>
+> Produce a prioritized set of roadmap moves. Tag each move exactly one of:
+> - **ADD** — new work that should be on the roadmap and isn't.
+> - **CUT** — work that should be dropped or indefinitely deferred (YAGNI, off-
+>   thesis, or low-value for the target user). Cutting is a first-class call.
+> - **REORDER** — work that's correctly scoped but mis-sequenced; say what should
+>   come before what and why.
+> - **PIVOT** — a larger directional change (segment, positioning, or thesis).
+>   Use sparingly and argue it hard.
+>
+> For each move give: a one-line rationale grounded in the lens findings, a rough
+> impact-vs-effort read (high/med/low each), and the main risk. Order the whole
+> list by leverage — the single highest-impact move first.
+>
+> Be opinionated and specific. "Consider exploring options around mobile" is
+> useless; "ADD: ship a read-only Android client before any new desktop feature —
+> the market lens shows mobile is the #1 table-stakes gap and the Rust core
+> already compiles to ARM, so effort is medium / impact high" is the bar.
+>
+> Return: the tagged, leverage-ordered move list, nothing else.