Files
relicario/.claude/skills/product-expert/references/lenses.md
adlee-was-taken c3044ed5af 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
2026-06-20 22:30:48 -04:00

156 lines
8.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 12, `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 13 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.