write-brief

星标14

分支0

更新时间2026年6月29日 22:23

Use when the user wants the human-facing decision document for a problem or bet that has been investigated, to align people on it or to force a choice. Covers three shapes: a narrative or report (problem, why now, impact, and the ask), a hard-questions FAQ, or a decision or options memo that weighs several options (including do-nothing), recommends one, and states the ask. Trigger on phrasing like 'write the brief', 'draft the brief', 'opportunity brief', 'the narrative', 'the FAQ', 'decision memo', 'options memo', 'recommendation memo', 'weigh options and recommend one', or after a decision passes the readiness gate. This is the leadership decision artifact, rendered from existing evidence and scores, NOT an engineering PRD, spec, acceptance criteria, status update, competitive battlecard, or metrics review. Refuses to invent metrics.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

sparkline-ventures

sparkline-ventures/product-eval

打开 GitHub 仓库查看创作者相关仓库

下载

Write Brief

Produce the human decision artifact for a decided problem or bet, in the requested style. Narrative and FAQ styles persuade and align humans around the problem, why now, impact, and ask; memo style forces a yes/no or option choice with a recommendation and explicit ask. It is not an implementation spec. Each style renders from the same .product-eval/<scope>/ content (problem, evidence, themes, scores, decision). Never invent metrics, owners, or dates, write "Not provided in input" instead.

Preconditions

The brief is gated on decision-readiness. Check the item's latest verdict in .product-eval/<scope>/decisions-log.md: if there is no passing (Decide-now) verdict, or the latest outcome is "Run a research sprint", do not produce a confident brief. Say so, and offer a "decision-readiness brief" that states the gaps and points to design-test for the cheapest validating test instead.

Also run the conformance preflight in DATA-CONTRACT.md (Validation) on the scope files you render from; if scores.md, themes.md, or decisions-log.md fails a check, report the violation rather than rendering a brief from inconsistent data.

Styles, `--style narrative | faq | memo | both`

narrative / report

A flowing readout: problem → why now → proposed solution → customer & business impact → success metrics → the ask. Prose, not bullets; one quantified claim early; explicit before/after; no unsupported roadmap commitments. Optional press-release voice (write it as if already shipped). Structure and starters in references/opportunity-brief.md.

faq

The hard-questions version, the completeness gate. Answer the question bank in references/opportunity-brief.md (problem, customer, timing, alternatives, limitations, out-of-scope, failure modes, success metrics, one-way doors, …). This version is also the scaffold the critique lens-panel attacks before the doc is "done".

memo

A decision-oriented memo that forces a yes/no or option choice by a deadline, for driving a decision, not persuading. Headings in order: purpose & decision requested (one sentence + deadline) · executive summary (customer + business impact) · current state & evidence (each claim with source + strength) · root cause · options considered (≥3 incl. do-nothing; table Option | Summary | Benefits | Tradeoffs | Key risk | Why not selected) · recommended strategy (falsifiable success/failure criteria) · metrics scorecard (Metric | Baseline | Target | Owner | Date) · economics if relevant · risks/dependencies/mitigations (owner + close date) · the ask (concrete, owner- and time-bound). Run critique on the recommendation's falsifiability and whether do-nothing is honestly weighed.

both

Narrative as the readout, FAQ as the backing appendix.

Workflow

Load the decided problem, its evidence, scores, and verdict from the scope.
Render the requested style(s) from references/opportunity-brief.md.
Put evidence in appendices, not in marketing claims; cite source + strength.
Run critique (panel mode) on the FAQ and tag each answer resolved / open / contested before calling it done.
Export to docx/pdf if asked (read the docx/pdf skills). Write to .product-eval/<scope>/docs/.

Output

The brief in the requested style plus the critique summary (resolved / open / contested counts). Lead with the one-paragraph essence. End with Next move: and recommend resolving open FAQ items, pressure-testing the plan if commitment risk remains, or turning the approved decision into a build brief.

同仓库更多 Skills

同仓库

calibrate

sparkline-ventures/product-eval

Tune and validate the scoring constants (evidence-weight base, diversity factors, gate threshold, crispness bars) against past decisions with known outcomes. Use when the user says "calibrate", "tune the thresholds", "validate the scoring", "the confidence numbers feel off", or has a set of past decisions to check the model against. Reports mismatches and recommended constant changes; never silently changes them.

2026-06-2914

critique

sparkline-ventures/product-eval

Use when someone wants existing thinking attacked, graded, or handed to fresh eyes, not written or summarized. The point is to break the artifact, not produce it. It owns three intents: a skeptical outside read of conclusions, findings, themes, a synthesis, a brief, or a FAQ, from someone who was not in the room; running those findings past hostile lenses (a wary customer, CFO, engineer, competitor) to see where they collapse; and grading a problem statement or one-liner (right altitude, names a real persona, or vague mush) with a score and what is missing. Reach for it on 'give this a fresh adversarial read', 'put this in front of a skeptical X', 'score how crisp this problem statement is', 'poke holes', 'red-team this'. Do not use it to create or restate the artifact. Attacking a whole plan, roadmap, or PRD routes through pressure-test; this skill owns findings, syntheses, problem statements, and panels.

2026-06-2914

decision-readiness

sparkline-ventures/product-eval

Judge whether there is enough evidence to make a build decision on a specific problem or bet, and return one of three outcomes: Decide now, Run a research sprint, or Do not commit yet. Use when the user asks "do we have enough data to decide?", "is this worth building?", "are we ready to commit to X?", "what's the evidence for this?", or "decision readiness". This is the core gate, Confidence band drives the decision; signal strength is assessed per evidence item.

2026-06-2914

design-test

sparkline-ventures/product-eval

Turn a "Run a research sprint" verdict (promising but under-evidenced) into the cheapest experiment that would close the gap, a concrete validating test with a hypothesis, method, sample, effort, and pass/fail threshold. Use when decision-readiness returns Run a research sprint, or when the user asks "how do we validate this", "what's the cheapest test", "how do we de-risk this bet", or has a promising idea with thin first-party evidence. Designs the test; its results feed back into gather-evidence. Do NOT use to pull existing data (that is gather-evidence) or to judge sufficiency (that is decision-readiness).

2026-06-2914

discover-sources

sparkline-ventures/product-eval

Map what product-data sources a user can draw on, connectors, tools, files, offline systems, and the decision-confidence ceiling those sources allow. Use when the intent is discovery and setup of the evidence base itself: "what data do I have / could connect", "scan/inventory my sources", "is X hooked up", "where could product insights come from", "how confident could any decision be given my data", or starting a new project before any framing or prioritizing. Do NOT use when the user wants you to actually work the data they already have, pulling, summarizing, grading, or reporting on tickets, reviews, surveys, metrics, scorecards, or trends. Those are analysis and reporting tasks, not source discovery. The trigger is "what evidence exists and how good can it get," not "analyze the evidence." Produces a source map plus a confidence ceiling.

2026-06-2914

drift-check

sparkline-ventures/product-eval

Compare an investigation's CURRENT state against an EARLIER SNAPSHOT of itself and report what moved between those two points in time: problem-statement drift, evidence added or retired, Value/Confidence score movement, theme or narrative reframing, and whether confidence is genuinely accumulating or just churning. Use when the user says "what changed since last month", "has this drifted", "compare this to the prior version", "is the confidence trajectory improving", or wants to audit a scope before re-deciding. Reads scoped snapshots and git history and runs the cross-stage consistency checks. Do NOT use for finding patterns or trends WITHIN the current evidence set, that is synthesize; nor for reviewing a product-metrics dashboard, that is a metrics review. This is specifically a then-vs-now diff of the investigation. No daemon; runs on demand or on a schedule.

2026-06-2914

name

write-brief

description

Write Brief

Preconditions

Styles, `--style narrative | faq | memo | both`

narrative / report

faq

memo

both

Narrative as the readout, FAQ as the backing appendix.

Workflow

Load the decided problem, its evidence, scores, and verdict from the scope.
Render the requested style(s) from references/opportunity-brief.md.
Put evidence in appendices, not in marketing claims; cite source + strength.
Run critique (panel mode) on the FAQ and tag each answer resolved / open / contested before calling it done.
Export to docx/pdf if asked (read the docx/pdf skills). Write to .product-eval/<scope>/docs/.

write-brief

Write Brief

Preconditions

Styles, --style narrative | faq | memo | both

narrative / report

faq

memo

both

Workflow

Output

同仓库更多 Skills

Write Brief

Preconditions

Styles, --style narrative | faq | memo | both

narrative / report

faq

memo

both

Workflow

Output

同仓库更多 Skills

Styles, `--style narrative | faq | memo | both`

Styles, `--style narrative | faq | memo | both`