Hackathon
Cheat Sheet

Run first:Cut the idea down to the demo path

Install the Domain to Spec skill and run it:

npx skills add IdkwhatImD0ing/hackathonstarterkit --skill domain-to-spec

Use the domain-to-spec skill to write AGENTS.md and PRD.md to the repo root for this project.

Interview me first, all questions in one message rather than one at a time, because we are on the clock: what we are building, who it is for, the demo we are going to perform, our stack, and how many hours are left. If we have not agreed on a click-by-click demo script yet, say so and tell me to run the "Cut the idea down to the demo path" prompt before this one.

Keep the PRD to one page: the problem, the demo path, the in-scope feature list, the data models, external APIs and env vars, and an explicit "out of scope" section. Do not skip the out-of-scope section, it is the part that stops us building the wrong thing at hour 14.

Show me both files and wait for my approval before writing any feature code.

Point CLAUDE.md at AGENTS.md so every tool on the team loads the same rules.

Run first:Cut the idea down to the demo path

Put the rest of this hackathon on a clock.

Ask me for whatever you do not already know: the current time, the submission deadline, who is on the team and what each person can do, our in-scope feature list, and whether anyone plans to sleep. If we have not cut the scope to a demo path yet, tell me to do that first, because a schedule over an uncut scope is fiction.

Then give me an hour-by-hour plan as a table: time block, owner, task, what done means.

Rules for the plan:
- A deployed, working app at every checkpoint. No big-bang integration at the end.
- Reserve the last 3 hours for the demo video, README, and submission. Nothing new gets built in that window.
- Include a feature freeze time, and a cut-scope decision point at the halfway mark.
- Every block has exactly one owner.
- Include food and sleep.

Run first:Write the spec (AGENTS.md and PRD.md)

Split our scope so nobody overwrites anybody.

Read PRD.md in the repo root first. If it is not there, stop and tell me to run the "Write the spec" prompt before this one, then wait. Ask me who is on the team and what each person can do if you do not already know.

Then give me:
1. A file and folder ownership map, one owner per area.
2. The interfaces between areas (API routes, shared types, component props), written out now so both sides can build before either exists.
3. A branch and merge rule simple enough to follow at 4am.
4. The three most likely merge conflicts and how we avoid them.

Then write the shared types file first so everyone can start.

Install the Bugfix Doctor skill and run it:

npx skills add IdkwhatImD0ing/hackathonstarterkit --skill bugfix-doctor

Use the bugfix-doctor skill on this bug.

Ask me first for exactly what I did, what I expected, what happened, and the full error text with the stack trace. Do not start guessing before you have the verbatim error. If I paraphrase it, ask again for the real thing.

Then work the loop and do not skip steps:
1. Restate the failure in one sentence.
2. Give me your top 3 hypotheses, ranked, each with the one-line check that proves or kills it.
3. Run the cheapest check first, or tell me to run it.
4. Fix only the confirmed cause, with the smallest possible change.
5. Show me how to verify the fix, then commit.

No refactors. No "while we are here" changes.

Paste the whole stack trace. Summarizing the error is how people spend an hour on a typo.

Run first:Deploy an empty app before you build anything

It works on my machine and fails when deployed. Find out why.

Ask me for the deployed URL, what happens there versus locally, and the build or runtime log from the host. Wait for the log before theorizing. If we have never deployed successfully, say so and tell me to run the "Deploy an empty app" prompt first, because we are debugging two problems at once otherwise.

Then check these in order and report what you find at each: environment variables missing on the host, build-time versus run-time code, case-sensitive file paths, node version, packages missing from the lockfile, API keys restricted to localhost, CORS, and anything writing to the local filesystem.

Then fix the confirmed cause, redeploy, and give me the working URL.

Something that used to work is broken and I do not know what changed.

Ask me roughly when it last worked and what the broken behavior is now. Then inspect the repo yourself instead of asking me to describe the commits.

Then:
1. Show me the commits since then, one line each.
2. Tell me which are most likely responsible and why.
3. Give me the exact commands to get back to the last working state on a new branch, without losing today's work.
4. Once we are working again, reapply the changes one at a time and test after each.

Do not force push. Do not delete branches. Ask before anything destructive.

Commit every 30 minutes. This prompt is only as good as your last commit.

I am stuck and the clock is running.

Ask me what I am stuck on and how many hours we have left. Then give me exactly three things:
1. The fastest workaround that keeps the demo intact, even if it is ugly.
2. What we lose by taking it, in one line.
3. What the demo looks like if we cut this feature entirely.

Then recommend one of the three in two sentences. Nobody is reading our source code, so optimize for what judges will see.

Triage what is left. I need a decision, not options.

Ask me in one message: how long until submission, what currently works, what is broken, what has not been started, and what the demo is supposed to show.

Then:
1. Tell me the smallest demo we can still deliver using what already works.
2. List what to cut, in order, and what to say about it if judges ask.
3. Give me the one thing to fix first, chosen by demo impact per minute of work. For anything broken that cannot be fixed in the time we have, say "hardcode it" instead: a demo step that shows canned output beats a demo step that does not exist.
4. Reserve the last 45 minutes for the video and submission, and tell me the hard stop time for coding.

One plan. No alternatives. I will follow it.

A small demo that works beats an ambitious one that does not. Every judge has seen the second kind.

We are out of time and the real thing will not work. Hardcode whatever it takes so the demo still happens.

Ask me first: the click-by-click demo script, what already works for real, what is broken or missing, and how many minutes we have. If we never wrote a demo script, have me walk you through the clicks right now and write it down as you go.

Then work backward from the demo script and nothing else:
1. Every step that works for real stays real. Real beats fake wherever real exists.
2. Every step that does not work gets hardcoded: canned API responses, precomputed results, fixed state transitions, a scripted happy path. It has to look real on screen for the exact inputs in the script, and it must never crash.
3. Make the seams invisible to the audience: realistic data, realistic timing, no placeholder text, no debug output.
4. When you are done, give me a two-column list, REAL versus HARDCODED, step by step, so the presenter knows exactly what they can click live and where they must not deviate from the script.
5. Walk the full script with me once and confirm every step renders.

The worst outcome tonight is standing in front of judges with nothing on screen. A hardcoded demo we can show beats a real one we cannot.

Know your seams and stick to the script. If a judge asks what is real, answer honestly; a hardcoded demo you own up to is a prototype.

A service our demo depends on is down, rate-limited, or out of credits.

Ask me which service it is, what it does for us in one sentence, and how long we have left.

Then:
1. Give me a drop-in replacement we can wire in under 30 minutes, with the code.
2. If there is none, hardcode it: record one real successful response now if the service still answers at all, otherwise write the response by hand, and serve that when the live call fails. The demo must flow either way.
3. Make the failure path invisible to the audience and obvious to us, and tell me exactly which steps of the demo are now canned so the presenter knows.

Do option 1 if it exists, otherwise option 2. Do not make me choose, just tell me which you did.

Our repo is a mess and we are out of time.

Ask me what I ran, the full output git gave me, which branches exist, and which version demos correctly. Then inspect the repo yourself.

Then:
1. Tell me in plain English what state the repo is in.
2. Give me a safe path to one branch containing the demo-critical work, step by step, with the exact commands.
3. Back everything up first: create a backup branch before any destructive command and tell me its name.
4. If any work has to be dropped, tell me exactly what and ask me before doing it.

Never force push to our main branch.

We present in minutes and something just broke.

Ask me only two things: how many minutes I have, and what broke. Then answer in under 100 words.

1. Do not refactor. Give me the ugliest fix that makes the demo path work right now, hardcoding the broken step's output if that is fastest.
2. If even that will not land in time, give me the exact words to route around it live: what I click instead, and what I say.
3. Give me the fallback order: live app, then local, then the recorded video, then screenshots. We show one of these no matter what.

Have the video downloaded on your laptop before you present. Venue wifi fails at every hackathon.