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
156 lines
8.1 KiB
Markdown
156 lines
8.1 KiB
Markdown
# 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.
|