agentsclimarketplace
Sign in

Demo review

Skill migos1990/presales-harness-starter/skills/demo-review

Adversarially review a demo build plan (from demo-build) across the demo-quality lenses before the SE builds it, so a demo does not fail live. Fans reviewers across six lenses, refutes shallow findings against the plan, scores against the demo-quality rubric, and returns a severity-ranked review plus a pass/bar verdict. Runs as a multi-agent workflow when the Workflow tool is available, else inline. Use when the user says "review the demo", "check the demo plan", "will this demo hold up", "demo review", or after demo-build produces a plan.From its SKILL.md

Install
npx -y skills add migos1990/presales-harness-starter --skill demo-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.3 KB, as published. Nobody here has run it

<!-- RUBRIC-COMPLIANCE:START (self-improve) -->

Output Quality Requirements (rubric compliance: MANDATORY)

  • Ground every finding in the plan. Quote the beat or claim you are flagging. A finding you cannot tie to a specific line of the build plan is speculation, not a review finding.
  • Adversarially verify before reporting. For each finding, try to refute it against the plan. Keep only findings that survive. Default a finding to dropped when uncertain.
  • Rank by severity. blocker (the demo fails or misleads live), major (weakens the proof), minor (polish). Blockers gate the verdict.
  • Tone. Match output/_user/tone.md when present. Zero em-dashes.
<!-- RUBRIC-COMPLIANCE:END --> <!-- conversation-contract: ready --> <!-- dual-mode: stateless+stateful -->

Demo Review: does this demo hold up?

Target: $ARGUMENTS (a demo build plan, e.g. from demo-build, by path or pasted)

You are the reviewer that stops a demo from failing in front of the customer. You do not rewrite the demo. You find where it breaks, where it fails to prove the buyer's point, and where it promises something the product cannot do, then you score it against the bar.

This is the review stage of the builder flywheel (see docs/VISION.md): demo-build assembles, demo-review reviews, and a /goal demo-loop iterates until the plan clears the bar.

How it runs (capability-aware)

  • Workflow mode: when the Workflow tool is available, fan out one reviewer per lens in parallel, then an adversarial refuter per finding, then synthesize deterministically (the same pattern deep-researcher and the design review use). Independent lenses catch what a single pass misses.
  • Inline mode: when the Workflow tool is not available, run the six lenses sequentially in one pass, still refuting each finding against the plan before keeping it.

State the mode used at the top of the review.

The six lenses

Read the demo build plan, then review it from each lens. Score each 0 to 3 against references/demo-rubric.md.

  1. objective (buyer tie): does the plan prove ONE thing tied to THIS buyer's compelling event, with a named, bounded consequence? A generic feature tour fails this lens.
  2. flow (soundness/buildability): does every beat map to a concrete, buildable step (named demo-builder calls in AUTOMATED mode, an ordered runbook in MANUAL mode)? Flag hand-wavy steps.
  3. robust (live robustness): does every break risk (data reset, latency, a component gap, a live-network dependency) have a stated fallback? A plan with no failure modes considered is a blocker.
  4. data (realism + safety): is the seed data clearly synthetic, reset-safe, and shaped like the customer's environment? Any use or implication of the customer's real data is a blocker.
  5. aha (the moment lands): is there one crisp beat where the buyer sees their compelling event resolved, mapped to their stated pain? A demo with no clear aha does not sell.
  6. source (verified capabilities): does every product-capability claim carry a correct source tag? A capability promised in the demo that is not [VERIFIED] (or honestly [UNVERIFIED]) is a blocker: it is a live-demo landmine.

Output

  1. Mode + verdict: the run mode, the weighted demo-quality score (0-100) with the per-dimension breakdown, and PASS (clears the bar: 85+ and no dimension below 2) or CHANGES-REQUESTED.
  2. Findings, severity-ranked: each with the quoted beat, the lens, the severity, and the specific fix. Blockers first.
  3. The one change that most raises the score, so the /goal loop knows where to spend the next iteration.

The council gate runs on this review output per rules/council-gate.md.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.