diecut

Single binary No runtime dependencies. Download one file and go.

Easy to make A diecut.toml and a folder — that's a template. You just made one.

Multi-template repos One repo, many templates. Use subpaths to pick the one you want.

Any Git host GitHub, GitLab, Codeberg — or any Git URL.

Install

curl -fsSL https://diecut.dev/install.sh | sh

More install options →

Use it

diecut new gh:raiderrobert/diecut-templates/rust-cli -o my-cli

That’s it. diecut prompts you for variables and generates a ready-to-go project.

Learn more about using templates →

Use cases

Project template — Your personal dev stack, your team’s service skeleton, your agency’s client baseline. Write the pattern once; scaffold on demand.

Monorepo packages — New packages should start from the same baseline as existing ones, not be hand-assembled. Keep a templates directory in the repo, or point at a well-structured package as the pattern.

Repeating in-project patterns — Pick the folder that already has the right shape, run diecut new ./path/to/that-folder, and get a prompt-driven copy. New routes, feature modules, service clients — anything you repeat.

Multi-file feature scaffolding — A new entity means controller, service, repository, test — all sharing a name. Copy-paste misses one; a template can’t.

Structured content — Define the frontmatter shape once. Whether a human fills it in interactively or an LLM passes -d flags, the output always conforms.

Prompt and skill templates — The craft is in the template; the personalization is mechanical. select variables constrain tone and persona to values the prompt was actually designed for.

Why diecut?

I built diecut because I tend to make lots of projects for fun. I get a stack I like, and I don’t like messing around with the setup. I enjoyed cookiecutter back in the day, but I found it complicating my life more than simplifying it.

I aimed to solve four things:

• Single binary: I’ve often just wanted to download a binary and no faff with Python stuff, even though I wrote mostly Python.
• Easy to make: I wanted it to be dead simple to make templates with as few footguns as possible. So you also don’t need to do complicated logic in the templates, because you can just chain conditional prompts together to get your answers. You don’t even need to use almost any of the Tera templating at all and can just use conditional files feature to exclude files you don’t want.
• Multi-template repos: I dabble a lot in different stacks and languages, but I’d rather not have 5 different repos for my templates. This felt like a good way to organize them.
• Safe to try: sometimes I want to see what the result will look like before I commit to it, but none of the other tools out there had this feature.