# 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.
