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
95 lines
3.2 KiB
Markdown
95 lines
3.2 KiB
Markdown
# Output templates
|
||
|
||
Use these verbatim in structure. Fill the brackets. Keep prose tight — the user
|
||
reads this to make a decision, not to admire it. Lead with the highest-leverage
|
||
point in every section.
|
||
|
||
---
|
||
|
||
## Roadmap-audit output
|
||
|
||
```markdown
|
||
# Product Audit — Relicario — [YYYY-MM-DD] · [fast | deep]
|
||
|
||
## Reality check
|
||
[One paragraph: where the product *actually* stands, reconciled against code +
|
||
git, not the docs' self-description.]
|
||
|
||
**Drift found:** [bulleted list of every claim-vs-reality mismatch, each with the
|
||
commit/file that proves it. Write "none — docs match reality" if clean.]
|
||
|
||
## Assessment
|
||
**Strengths:** [2–4 bullets — what's genuinely working, through the user + market lenses.]
|
||
**Gaps:** [2–4 bullets — table-stakes misses, friction, parity gaps.]
|
||
**Risks:** [1–3 bullets — what could undermine the product or the thesis.]
|
||
|
||
## Recommendations
|
||
[Leverage-ordered. Highest-impact first. Each line:]
|
||
- **[ADD|CUT|REORDER|PIVOT]** — [the move]. *Why:* [one line]. *Impact/Effort:* [H/M/L · H/M/L]. *Risk:* [one line].
|
||
|
||
## PM brief
|
||
[The paste-ready block — see "PM brief block" below.]
|
||
```
|
||
|
||
---
|
||
|
||
## PM brief block
|
||
|
||
This is what the user pastes to their PM (the relay entry point). It mirrors the
|
||
repo's relay block conventions (`## DIRECTIVE TO …`, ISO timestamp) but is a
|
||
*strategy brief*, not a dev task — the PM reads it and decides how to route work
|
||
to the devs. Keep it self-contained: the PM may act on it without the full audit.
|
||
|
||
```markdown
|
||
## PRODUCT DIRECTIVE TO PM
|
||
Time: [ISO-8601 local timestamp]
|
||
Source: /product-expert roadmap audit ([fast|deep])
|
||
|
||
Reality note: [one line — any drift the PM must know before acting, e.g. "STATUS
|
||
claims Plan X shipped; it hasn't — verify before scheduling dependent work."]
|
||
|
||
Roadmap changes (in priority order):
|
||
1. [ADD|CUT|REORDER|PIVOT] [the move] — [one-line why].
|
||
2. …
|
||
|
||
Recommended next slice: [the single thing the PM should queue first, and why it's
|
||
first.]
|
||
|
||
Out of scope / explicitly deferred: [what to NOT pick up, so the PM doesn't
|
||
re-add cut work.]
|
||
```
|
||
|
||
The user edits this before relaying. Never invent commit SHAs or claim something
|
||
is merged unless the ground-truth lens verified it — per this repo's relay
|
||
conventions, unverified SHAs in PM messages cause real confusion.
|
||
|
||
---
|
||
|
||
## Spec-review output
|
||
|
||
```markdown
|
||
# Spec Review — [spec filename] — [YYYY-MM-DD] · [fast | deep]
|
||
|
||
## Verdict: [PROCEED | RESCOPE | CUT | PIVOT]
|
||
[One sentence stating the call plainly.]
|
||
|
||
## Rationale
|
||
- **User job:** [does it serve a real job for a real segment? which?]
|
||
- **Positioning fit:** [does it strengthen or dilute the wedge?]
|
||
- **Opportunity cost:** [what does building this displace on the roadmap? is that
|
||
trade worth it?]
|
||
- **Scope:** [right-sized, gold-plated, or under-built? cite the YAGNI risks.]
|
||
|
||
## [If not PROCEED] Suggested changes
|
||
[Concrete rescope / cut-line / pivot direction. Be specific enough that the next
|
||
step is obvious.]
|
||
|
||
## Next step
|
||
[If PROCEED: "Spec holds up — proceed to writing-plans." Otherwise: "Revise the
|
||
spec per above, then re-review or proceed."]
|
||
```
|
||
|
||
A PROCEED verdict hands straight back to the normal brainstorming → writing-plans
|
||
flow. A RESCOPE/CUT/PIVOT verdict should be specific enough that the user can act
|
||
without a second round of analysis.
|