Problem
Template authoring has no easy entry point. Authors either hand-write diecut.toml from scratch reading docs, or reach for extract/distill (#117, #123, #130) which are powerful but overkill for someone just starting. Previous attempts have focused on reverse-engineering existing projects; this ticket is the simpler complement.
The explicit goal: start simpler, not smarter.
Proposed feature
diecut init <name> creates a minimal working template skeleton:
<name>/
├── diecut.toml # minimal manifest, one variable
└── {{ project_name }}/
└── README.md # hello-world content using the variable
Behavior:
- Offline, <1s to create
- The generated skeleton renders successfully via
diecut new <name> with zero edits
- Comments inside
diecut.toml point to docs for extending (hooks, conditionals, computed vars)
Non-goals
- No reverse-engineering (that's
extract / distill)
- No interactive prompts at init time — keep it minimal
- No multi-template repo scaffolding in v1
- No install-snippet generation (separate ticket for
diecut share)
Open questions
diecut init <name> (create new dir) vs. diecut init . (scaffold in place)?
- Include a commented-out hook stub, or omit entirely for "start simple"?
Acceptance criteria
Problem
Template authoring has no easy entry point. Authors either hand-write
diecut.tomlfrom scratch reading docs, or reach forextract/distill(#117, #123, #130) which are powerful but overkill for someone just starting. Previous attempts have focused on reverse-engineering existing projects; this ticket is the simpler complement.The explicit goal: start simpler, not smarter.
Proposed feature
diecut init <name>creates a minimal working template skeleton:Behavior:
diecut new <name>with zero editsdiecut.tomlpoint to docs for extending (hooks, conditionals, computed vars)Non-goals
extract/distill)diecut share)Open questions
diecut init <name>(create new dir) vs.diecut init .(scaffold in place)?Acceptance criteria
initsubcommand wired updiecut new <name>in tests