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