# Pitch And Demo > Pitch And Demo - Skill: `handsomeboy990/pitch-and-demo` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add handsomeboy990/pitch-and-demo` - Raw SKILL.md: https://api.skillmd.com/api/skills/handsomeboy990/pitch-and-demo/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: Handsomeboy990 (https://skillmd.com/u/handsomeboy990) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/handsomeboy990/pitch-and-demo --- # Pitch And Demo A project is judged on what the judges see and understand in a few minutes, not on what was built. A strong build with a weak pitch loses to a modest build with a strong one. This skill turns a working project into a presentation that lands: a clear problem, a real demo, honest claims, and a delivery that survives the room. ## 1. Lead with the problem and the stakes ``` problem open with the problem, concretely, so the judge feels it before they see the solution; a specific person with a specific pain beats an abstract market stakes why it matters: who is affected, how much, why now; the impact story that most rubrics weight heavily solution only then, the solution, as the answer to the problem just felt; the build serves the story, the story does not decorate the build avoid opening with the technology, the architecture, or the team's cleverness; the judge does not yet care, because they do not yet feel the problem ``` ## 2. Show the working thing ``` demo show it working, live or recorded; a demo that runs is the single most persuasive thing in the room, and most rubrics reward it heavily real the demo shows the actual product doing the actual thing, not slides describing it; "let me show you" beats "imagine if" path the demo follows the story: the problem, then the product solving it, in the order that makes the impact land focus demo the part that works and that scores; do not wander into the fragile feature or the settings screen; every second of the demo earns its place ``` ## 3. Fit the time, ruthlessly ``` limit the real time limit, respected; a pitch cut off at the buzzer before the demo is a loss, and judges enforce the clock structure problem, stakes, demo, what is next, in the time given; a two-minute pitch has no room for a team-history slide cut everything that does not serve the problem-to-demo arc; the technology deep-dive, the full roadmap, the acknowledgements one thing the judge should leave remembering one thing; name it, and build the pitch so that one thing lands ``` ## 4. Honest claims ``` true every claim is something the project actually does or the evidence actually supports, per opportunity-core; a judge who catches an overclaim discounts everything else demo-real the demo shows real behaviour, not a hardcoded happy path presented as general capability; if something is faked for the demo, it is not claimed as working future what is not built yet is framed as "next", not implied as done; the honest "here is what works today and where it goes" is more credible than a demo pretending to be a finished product ``` ## 5. Rehearse and survive the room ``` rehearse the pitch and demo are rehearsed against the clock, out loud, more than once; the first run is always too long and finds the fumbles fallback a recorded demo as backup for when the live one fails; wifi dies, laptops sleep, and the team that has a fallback keeps its score handoffs for a team, clean handoffs between speakers, rehearsed; a scramble over who talks next reads as unprepared questions anticipate the judges' questions (how does it scale, what is the business model, what did you build versus use) and prepare honest answers ``` ## 6. Prohibitions - Never open with the technology; open with the problem the judge must feel. - Never describe the product when you could show it working. - Never demo the fragile feature or wander off the story. - Never overclaim; a caught overstatement discredits the whole pitch. - Never present a hardcoded demo path as a general capability. - Never run over the time limit; a cut-off pitch loses the demo. - Never present without rehearsing against the clock and preparing a demo fallback. ## 7. Protocol 1. Write the narrative: problem, stakes, solution, in that order. 2. Script the demo to follow the story, showing the working, scoring part. 3. Structure the whole to the time limit; cut everything off the problem-to-demo arc. 4. Verify every claim is honest and the demo shows real behaviour. 5. Prepare the one thing the judge should remember. 6. Rehearse against the clock, prepare a recorded fallback, and ready answers to likely questions. ## 8. Auto-critique Score from 0 to 5: opens with the problem and stakes not the technology, shows a working demo of the scoring part, fits the time with everything off-arc cut, every claim honest and the demo real, one memorable thing, rehearsed against the clock with a fallback and prepared answers. Threshold: no axis below 3, average at least 4. An overclaimed or faked-as-real demo, or a pitch that opens on technology and never shows the working thing, caps the score until fixed. ## 9. Interfaces - Upstream: `opportunity-core` for honesty, `hackathon-strategy` for the project and the judging criteria the pitch scores on. - Downstream: the same pitch adapts to a demo day, an investor meeting, or an internal review; `report-writing` in `documents/` for a written version. - Lateral: `technical-writing` for a demo that needs an explainer; `self-critique` for the judge and skeptical-investor role passes. ## 10. Beyond hackathons The same structure wins a demo day, an investor pitch, and an internal project review: lead with the problem, show the working thing, claim only what is true, fit the time, and rehearse. The audience and the weighting change (an investor weights the market and the model more than a hackathon judge does), and the problem-first, show-do-not-tell, honest-claims spine is constant. Adapt the emphasis to the audience; keep the spine.