relicario/.claude/skills/product-expert/references/lenses.md

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.