Building myself a go-to startup kit

I start new projects a lot. Most of them never go anywhere, that's just how ideas work, but the first hour of each one used to look the same: pick a package manager, decide on a test framework, argue with myself about folder structure, figure out where env vars go. Small decisions, made from scratch, every single time, for problems I'd already solved the week before.

That's the itch that turned into Socratic Agentic Workflow in the first place, and it's the same itch behind v0.4.0. The skill's scaffold-patterns.md file is, in plain terms, my go-to startup kit: a library of starter repo structures I don't have to reinvent. I used one of these scaffolds to build the project in Putting my /skills to use, and it worked. But a kit only stays a kit if it's still current when you reach for it, and that's exactly where v0.3.0 left a gap.

A kit that doesn't go stale

Up through v0.3.0, each pattern in scaffold-patterns.md came with inline comments and a short rationale, genuinely useful, but written once and then left alone. "What's current best practice for a Next.js project's folder structure" is not a fact that ages well. Tooling churns, defaults change, and a kit item that was right when I wrote it can be quietly out of date six months later with nothing flagging it.

Insight: a startup kit you don't maintain isn't a kit anymore, it's an artifact. Useful for one project, a liability for the next ten.

v0.4.0 adds a step that runs silently before SCAFFOLD.md gets generated, what the skill calls the "architect pass." It starts from the matching entry in scaffold-patterns.md, and if I named a specific framework or tool during the interview, it uses web search to confirm the current recommended structure and tooling before finalizing the layout: folder layout, package manager, test framework, linter and formatter, env handling. If the stack is still generic or undecided, it skips the search. No point checking the internet about a decision nobody's made yet.

This is the same "always ask, never assume" instinct the skill already points at me, now pointed at its own defaults. The kit checks itself before it hands itself to me.

The part of the kit that used to be invisible

The output also gets a new ## Tooling section in SCAFFOLD.md, naming the package manager, test framework, linter/formatter, and env handling concretely for the stack, or stating plainly that it's "Deferred" if I haven't decided yet. Small addition, but it closes a gap I kept hitting: the old scaffold would show a tests/ folder in the tree and just... not say what runs the tests. I'd find out three files into the build, which is a bad time to find out.

To back this up without making every run depend on a search, scaffold-patterns.md itself now carries "Tooling defaults" per pattern, a fallback baseline for each project type. The architect pass can override these when I've named a framework, but if I'm still undecided, I'm not left with nothing. I get a sensible default, clearly labeled as a default.

Why this is the part I actually wanted

Three of these changes are mechanical: a new pass, a new section, a new field in a reference file. The fourth is a sentence in the changelog that's easy to skim past: the scaffold now reflects current best practice for the named stack, not a guess, grounded via search when a specific framework is involved.

That's the whole point of building a startup kit for myself. The value isn't having a folder structure ready to go, I could write that down once and copy-paste it forever. The value is not having to wonder whether the thing I copy-pasted is still good advice. Project number one, the kit was right because I happened to know the stack well enough to catch anything stale myself. Project number forty, I won't, and I shouldn't have to. That's what v0.4.0 actually buys me: the kit stays a kit, project after project, without me babysitting it.

v0.5.0, while we're at it

This was written for v0.4.0, and v0.5.0 shipped before I'd even published it. Two things from that release belong in the "kit" framing too. Every agent role definition now gets checked against five conventions, single responsibility, an I/O contract, tool scope, a coordination role, and a failure path, with AGENTS.md rewritten per role to spell out what each one explicitly does not do. And the output now ships with a sixth file, [slug]-README.md, generated last, linking the other five in the order you're meant to read them.

The kit keeps getting less like a folder of files and more like a kit with its own instructions.

The skill is MIT-licensed and lives at github.com/Kimotep/skills. More on what I build with it next, soon.