scorecard

Stars14

Forks0

UpdatedJune 29, 2026 at 22:23

Render the results of a product-eval investigation as a self-contained interactive HTML page: ranked opportunities with their Value, Confidence, verdict, evidence weight, customer quotes, and open gaps, laid out as KPI cards, a Value by Confidence quadrant, and per-opportunity cards. Use when the user wants to visualize, render, share, or make a dashboard or scorecard from an existing product-eval scope, that is, the output of prioritize-backlog or decision-readiness, or a scope's scores.md, themes.md, and decisions-log.md. Triggers include 'decision dashboard', 'product dashboard', 'scorecard from the ranked opportunities', 'turn the prioritization into something visual to share'. Do NOT use for general metrics or KPI dashboards, north-star or quarterly metric trends, grading raw signal strength, checking connected data sources, or drafting briefs; this only renders an already-scored opportunity ranking, it does not gather data or compute scores.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

sparkline-ventures

sparkline-ventures/product-eval

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

SKILL.md

readonly

name

scorecard

description

Scorecard

Turn an investigation's scores and verdicts into a single self-contained, interactive HTML page a PM can open, sort, share, and act on. This is the rich output: it makes prioritize-backlog and decision-readiness results tangible instead of a wall of text.

When to run

After prioritize-backlog (ideally with decision-readiness run on the top items). Reads .product-eval/<scope>/scores.md, .product-eval/<scope>/themes.md, and .product-eval/<scope>/decisions-log.md.

Preflight (data contract). Before rendering, run the conformance preflight in DATA-CONTRACT.md (Validation) on scores.md, themes.md, and decisions-log.md. If a check fails (a verdict outside the four-verdict vocabulary, a band that disagrees with its number, a problem with no matching theme), stop and report it rather than drawing a misleading dashboard. examples/activation-q3/ is a conformant fixture and examples/activation-q3/scorecard.html is its rendered output.

What it produces

One standalone .product-eval/<scope>/scorecard.html (no server; only optional Chart.js from a CDN), containing:

KPI cards: total opportunities, counts by recommendation (Decide now / Run a research sprint / Do not commit yet / Deprioritize), and the confidence ceiling.
Value × Confidence quadrant: each opportunity plotted; a vertical line at the Confidence gate (70) and a horizontal at Value 70, so the eye lands on the top-right "Decide now" quadrant.
Opportunity cards: one per opportunity, with clearly-labeled bands (Value, Confidence), optional 0-100 audit bars, evidence weight, accounts affected, the recommendation, verbatim customer quotes (the qualitative voice), the top complaint and the explicit ask, and a "why it ranks here" line tying the score back to that customer pain, plus the open gaps. The quotes and the complaint/ask are what make the prioritization legible; lead with them, not the number.
A "how to read" glossary: plain-language definitions of Value, Confidence, evidence weight, and accounts, and the recommendation tiers.
Honest footer: the confidence ceiling and the single cheapest move to raise the top item (e.g. "add one independent source type").

How to build

Generate one HTML file with inline CSS + JS. Read the data from the scope files (or accept inline data when rendering an example). For each opportunity, pull 1-2 verbatim customer quotes plus its top complaint and explicit ask from the evidence, these carry the qualitative voice and make the ranking legible. Show clearly-labeled Value and Confidence bands first, with exact 0-100 bars only as audit detail, and include the glossary. Color-code recommendations consistently: Decide now = green, Run a research sprint = amber, Do not commit yet = grey, Deprioritize = red. If a bounded ±10 adjustment was applied, note it. Keep it faithful to the formula, never invent a number the evidence doesn't support. Write to .product-eval/<scope>/scorecard.html and offer to open it.

Output

The path to the HTML scorecard plus a one-line summary (e.g. "5 opportunities, 1 Decide now, 2 Run a research sprint, 1 Do not commit yet, 1 Deprioritize; ceiling: Decide-now reachable"). End with Next move: and recommend deciding on the top item, designing the research sprint for under-evidenced items, or writing the stakeholder report.

More from this repository

same repository

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

scorecard

description

Scorecard

When to run

What it produces

One standalone .product-eval/<scope>/scorecard.html (no server; only optional Chart.js from a CDN), containing:

KPI cards: total opportunities, counts by recommendation (Decide now / Run a research sprint / Do not commit yet / Deprioritize), and the confidence ceiling.
Value × Confidence quadrant: each opportunity plotted; a vertical line at the Confidence gate (70) and a horizontal at Value 70, so the eye lands on the top-right "Decide now" quadrant.
Opportunity cards: one per opportunity, with clearly-labeled bands (Value, Confidence), optional 0-100 audit bars, evidence weight, accounts affected, the recommendation, verbatim customer quotes (the qualitative voice), the top complaint and the explicit ask, and a "why it ranks here" line tying the score back to that customer pain, plus the open gaps. The quotes and the complaint/ask are what make the prioritization legible; lead with them, not the number.
A "how to read" glossary: plain-language definitions of Value, Confidence, evidence weight, and accounts, and the recommendation tiers.
Honest footer: the confidence ceiling and the single cheapest move to raise the top item (e.g. "add one independent source type").