solo-founder-benchmark-to-demo-loop

name	Solo Founder Benchmark To Demo Loop
description	A reusable skill for taking one founder product goal through domain discovery, benchmark selection, local setup, app build, live workflow verification, and repair until the demo has receipts instead of vibes.

Solo Founder Benchmark To Demo Loop

Use this skill when a founder wants one prompt to become a working agent product, prototype, hackathon demo, or accelerator sprint deliverable that can be judged by evidence. The agent should not merely build a UI or pass unit tests; it should discover what the product must do, pick or create transferable tasks, prove those tasks in the live app, and return the real score.

Trigger Signals

• build my agent app, solo founder, hackathon, accelerator, prototype to demo, or ship after sprint.
• which benchmark fits my product, make my agent pass this workflow, or prove this works in my app.
• SpreadsheetBench, BankerToolBench, SWE-bench, workflow bench, live browser proof, or agent eval.
• held-out, no answer-keys, in-app transfer, honest provenance, or ProofLoop.

Preconditions

• The user has a repository, product goal, or partial app the coding agent can inspect.
• The agent can run local commands, install ordinary development dependencies, and use approved credentials.
• The agent has an autonomy envelope: what it may edit, what it may spend, what it must ask before doing.
• The app can expose at least one verifiable workflow through local tests, a local server, browser automation, official scorer, synthetic task pack, or human-reviewable artifact.

Strategy

1. Discover the product. Identify the user, workflow, data boundary, agent job, output artifact, and demo surface. Write down assumptions instead of asking for more steering when safe reversible choices exist.
2. Choose the benchmark shape. Prefer a public benchmark only when its task semantics transfer into the app. Otherwise create a small local task pack from real product workflows and keep held-out tasks hidden from the worker.
3. Set up locally. Install dependencies, identify env keys without printing them, start the app, run the smallest smoke, and record blockers in a local receipt instead of stopping at the first missing command.
4. Build the agent path. Implement the minimum app, tool, adapter, or UI flow needed for the workflow. Keep writes behind the app's normal APIs and avoid direct state mutation shortcuts.
5. Verify through transfer. Run the task through the app path, not a private shortcut. Use official scorers where available, and browser or Playwright evidence where the demo is a user-facing workflow.
6. Repair and rerun. If proof fails, localize the failure, patch the smallest relevant surface, rerun the same proof, and record the delta. Do not switch to an easier task to make the demo look green.
7. Return the founder answer. State the real score, what passed, what failed, what was blocked, what it cost, and the single highest-leverage next fix.

Constraints

• Do not run an off-the-shelf benchmark just because it exists; prove transfer to the user's actual app.
• Do not grade yourself. The final verdict must come from a scorer, test, browser evidence, receipt, or human gate.
• Do not hide failure. A low score with receipts is more valuable than an unproven success claim.
• Do not upload private code, prompts, traces, or credentials to hosted services without explicit approval.
• Do not use per-task answer writers, memorized fixtures, hidden state, or answer keys.

Validation

node evomap/validate-skills.mjs
node skills/solo-founder-nodes/conformance/conformance.mjs

The loop is valid when the repo contains a task or benchmark rationale, local setup receipt, implementation diff, live or scorer evidence, repair log for failures, and a plain-English verdict that preserves held-out, no answer-keys, in-app transfer, and honest provenance.