Claude Code Prototype Sprint

It is hour 6 of a hackathon. There are pizza boxes acting as monitor stands and someone two tables over has been pair programming with a Red Bull. I am not writing tests. I am not abstracting anything. I have one job, which is to get a thing that moves on screen so I can show it to a stranger and watch their face. That is the entire philosophy behind this build.

People love to ask what my fancy multi-agent orchestration setup looks like. Sorry to disappoint. My setup is almost aggressively boring. One model, two MCP servers, a single subagent, and one hook that does the one thing I always forget to do myself. That is it. The whole point is to remove decisions, because every decision is a tab I have to keep open in my head while the clock runs.

The model choice, and why it is not Opus

I run this on Claude Sonnet 4.6. I know, I know, the leaderboard people want me on Opus. But during a sprint I am not solving a gnarly distributed-systems puzzle, I am gluing a form to an API and making it look alive. Sonnet is fast and it is cheap, and when you are doing twenty round trips an hour the latency is the thing that actually kills your flow, not the last 4 percent of reasoning quality. My build clocks around 1.7s a turn at roughly 11 cents, and on Setuproll it sits at a 76 percent pass rate with a score of 86. Good enough is the goal. Good enough at 2am is a love letter.

CLAUDE.md is three rules and a dare

My memory file is short on purpose. A long CLAUDE.md is just a second codebase you have to maintain, and I do not maintain things during a sprint. These three rules are the whole personality of the build. They tell the agent to stop being a good engineer and start being a useful one.

# Prototype Sprint mode

We are building a demo, not a product. Optimize for a working
screen as fast as possible.

## Rules
- Ship the happy path first. Ignore edge cases until I ask.
- Hardcode before abstracting. Inline the data, fake the API,
  use a literal array. We can extract later (we won't).
- No tests until the idea is validated. Do not scaffold a test
  runner. Do not write a single `describe`. I mean it.

## Stack
- Next.js (App Router) + Tailwind. Single page is fine.
- Mock any external service with a local function returning
  fixture data. Leave a // TODO real api so I can grep later.

## Output
- Prefer one big file over five tidy ones during the sprint.
- When unsure, make the call and keep moving. Ask only if it
  blocks the demo.

That last rule about not asking is doing heavy lifting. Default Claude is polite and will check in with you. During a sprint that is death by a thousand confirmations. I would rather it guess wrong and let me redirect than stop and ask whether I want light or dark mode. I have a strong opinion here: a prototype that exists and is slightly wrong beats a perfect plan that is still a conversation.

Two MCP servers, no more

Filesystem so it can actually read and write my mess, and github so I can push at the buzzer without leaving the terminal. I have tried bolting on browser MCP and database MCP during hackathons and every single time it cost me more setup minutes than it saved. Here is the entire .mcp.json. If you can read JSON you have read my infrastructure.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "."]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

The one hook that saved my last demo

This is the part I am genuinely a little smug about. I have a Stop hook that boots the dev server the moment the agent finishes a turn. So the loop becomes: I describe a change, Claude makes it, it stops typing, and the server is already up. I tab over and the thing is just running. No alt-tab, no npm run dev, no the dreaded oh right I never started it. During a sprint that tiny gap between done and visible is where momentum goes to die, and this kills the gap.

{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "pgrep -f 'next dev' > /dev/null || (npm run dev > /tmp/dev.log 2>&1 &) ; echo 'dev server live on :3000'"
          }
        ]
      }
    ]
  }
}

The single subagent: builder

I keep exactly one subagent, called builder. Its whole job is to take a loose feature description and slam out the implementation in one pass without negotiating. I give it a narrow tool list and a system prompt that basically says be fast, be literal, do not gold plate. Sub-agents get their own context window, so I can hand it a chunky feature and not pollute my main thread with all the intermediate file reads.

---
name: builder
description: One-shot feature builder for prototypes. Use for any
  "add X feature" or "make a screen that does Y" request during a
  sprint. Implements the happy path and returns.
tools: Read, Write, Edit, Bash
model: sonnet
---

You are a hackathon builder. Your output is a working screen, not
a clean codebase.

- Build the happy path only. No error states unless asked.
- Hardcode data inline. Mock services with local functions.
- One file is fine. Do not split into modules for tidiness.
- Never write tests. Never add a dependency you can avoid.
- Finish the whole feature in one go, then stop. Do not ask
  follow-up questions unless the request literally cannot proceed.

What I keep and what I throw away

After a sprint, maybe one idea in five is worth keeping. For those, I do a second pass with a totally different, slower setup and actually write tests. But that is a different build for a different mood. This one is purely for the messy first 48 hours. Here is the honest tradeoff sheet.

1. Keep CLAUDE.md under a screen. If you scroll, you have a side project.
2. One subagent that does not ask permission beats three that hold meetings.
3. Automate the boring thing you forget at 2am. For me that is starting the server.
4. Pick the fast model. You can buy quality later, you cannot buy back momentum.

8:23

That video is where a few of these habits clicked for me, especially the bit about letting the agent run without holding its hand. If you want the official version of the hooks lifecycle so you can write your own, the docs and the awesome list below are the two tabs I actually keep open.

Grab it and go

If you have a weekend and a half-baked idea you cannot stop thinking about, this is the setup that gets it real before the doubt creeps in. Do not tune it. Do not add a fifth MCP server because a thread told you to. Just install it, point it at an empty folder, and start describing the demo out loud.

npx setuproll add claude-code-prototype-sprint

See you on the other side of 48 hours. Bring snacks.