My Hackathon Starts With One Folder

Every hackathon has a hidden tax you pay before you write a line of product code: wiring up your tools. Reinstalling the skills you rely on, re-registering the MCP servers, hunting through old repos for that architecture doc you know you wrote once. By the time your environment is actually good, you've burned two hours of a clock that doesn't stop.

So I stopped paying it. devx-engine is one folder I clone at the start of every hackathon, and the setup is already done. Here's what's in it and why each piece is there.

The whole idea: environment as a repo

devx-engine isn't a framework or a library. It's a portable development environment, checked into Git — skill sources, installed skills, MCP server config, and reference docs from past projects, all in one place. Clone it, drop in two secrets, and the agent I'm working with starts every project already knowing my tools and my patterns.

The layout is deliberately boring:

repos/            # skill / best-practice sources I pull from
skills/           # 64 installed Claude skills, ready to go
sih/              # TerraSight docs & config (code + secrets excluded)
kaggle-projects/  # reference docs from past builds
.mcp.json         # 10 MCP servers, pre-registered

Nothing here is clever. That's the point — the value isn't in any one file, it's in not having to assemble them again under a deadline.

64 skills, already installed

The skills/ folder is 64 Claude skills copied straight from my ~/.claude/skills. Design skills, review skills, deployment skills, domain-specific ones. Instead of remembering which ones I want and installing them fresh each time, they're all just there, versioned alongside the environment that uses them.

And repos/ keeps the sources those skills came from — best-practice collections, a hackathon skills marketplace, UI/UX and design skill packs. So the toolkit isn't frozen: when I want to refresh or fork a skill, its origin is one folder over, not a browser-history archaeology dig.

10 MCP servers, pre-wired

This is the part that saves the most time. .mcp.json registers ten Model Context Protocol servers so the agent can reach real systems on the first turn:

Two of them — github and postgres — read secrets from the environment (${GITHUB_PAT}, ${DATABASE_URL}), and the filesystem server is scoped to just this folder so nothing wanders. That's the entire configuration cost: set two env vars. Everything else is live.

Reference docs, not just code

The sih/ and kaggle-projects/ folders are the quietly valuable part. They hold the thinking from past builds — TerraSight's architecture and phase docs, a personal-CFO project's cost analysis and Q&A, another project's API contract and demo script. Not the code. The decisions.

When I start something new that rhymes with something old, I'm not reconstructing why I made a call last time — the reasoning is right there to lift, adapt, or argue with. Past-me did the hard thinking; present-me gets to reuse it.

Secrets were left out on purpose

One deliberate omission: no .env.local, no service-role keys, nothing sensitive got copied in from the source projects. The toolkit is meant to be cloneable and shareable, and that only works if it carries configuration, never credentials. Secrets come from the environment at use time — which is also why the whole thing can live in a public repo without me flinching.

The lesson

The best optimization I made this hackathon season wasn't an algorithm — it was refusing to rebuild my environment from scratch every time. Treating the dev setup itself as a versioned artifact means the boring, repetitive tax of "get ready to work" gets paid once and then just clones.

If you find yourself reinstalling the same tools and re-finding the same old docs at the start of every project, that repetition is a folder waiting to happen. Put your environment in Git, leave the secrets out, and start the next one already warm.