# scaffdog generates files from a Markdown template with question prompts

> scaffdog is a Markdown driven scaffolding tool for Node projects: you define a document with Front Matter and code blocks, the document asks the questions, and the answers are interpolated into the output files through a template engine inspired by ECMAScript and Go text/template. It ships with a Prettier plugin, a migration guide for every major version, and a monorepo that publishes the CLI, the types and the plugin separately.

**scaffdog/scaffdog** — :dog: scaffdog is Markdown driven scaffolding tool.

- Repository: https://github.com/scaffdog/scaffdog
- Website: https://scaff.dog
- Stars: 774 · Forks: 33
- Language: TypeScript
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/scaffdog-scaffdog

## The template is a document, not a program

scaffdog is described as a Markdown driven scaffolding tool, and the repository description is a little more colourful about it, with a dog emoji and the claim that it is Markdown driven scaffolding.

The design decision is that the template is a Markdown file. You can define a template with an h1 heading and a code block, and it becomes a Documetable template, which means one document can produce several output files, one per code block, with a heading naming each. The metadata comes from extended syntax using Front Matter, the same convention Jekyll popularised.

The template engine is described as simple yet powerful, inspired by ECMAScript and by Go's text/template, and the README notes that many built-in helper functions required to define templates are also provided. So the interpolation syntax is familiar to JavaScript developers and to Go developers at the same time, and the helper functions cover the operations a generator template actually needs, such as converting a name to Pascal case.

The reason to write a template in Markdown rather than in a generator script is worth stating plainly. A scaffdog template is a document that a human reads, reviews and edits, and the generated code is visible inside it as a code block. A generator written in JavaScript can do more, but it also has to be read as code, and reviewing it is a different exercise.

The project is MIT licensed, written in TypeScript, and its homepage is scaff.dog. The requirement is Node.js v18.0.0 or later.

## Two commands: init to set up, generate to run it

The workflow is deliberately short, and the README's quick start is the whole tutorial.

Installation is a local development dependency:

```bash
$ npm install --save-dev scaffdog
```

The README says scaffdog can be installed globally, but recommends installing it locally on the project, which keeps the version your team uses pinned in the lockfile and tied to the repository that uses it.

The init subcommand creates directories, the configuration file and the initial documents. By default it stores the document file and the configuration file in the .scaffdog directory:

```bash
$ npx scaffdog init

? Please enter a document name. component

Setup of scaffdog 🐶 is complete!

  ✔ .scaffdog/config.js
  ✔ .scaffdog/component.md

Now you can do scaffold by running `$ scaffdog generate`.
```

The second command runs a document and writes the files:

```bash
$ npx scaffdog generate

? Please select a document. component
ℹ Output destination directory: "."
? Please enter a component name. PrettyDog

🐶 Generated 2 files!

     ✔ PrettyDog/index.ts
     ✔ PrettyDog/PrettyDog.tsx
```

Two things are visible in that output. The document is chosen interactively from a list, and the questions come from the document itself, so the prompts a user sees are defined where the template is written. And the output confirms that one document produced two files, which is the Documetable behaviour in practice.

## Front Matter declares the questions, the body declares the files

The template format is the part worth understanding, because everything else follows from it.

The README's example replaces the generated .scaffdog/component.md with a document whose Front Matter carries the name, the root and output paths, and the questions, and whose body is a set of headings and code blocks:

````markdown
---
name: 'component'
root: '.'
output: '.'
questions:
  name: 'Please enter a component name.'
---

# `{{ inputs.name | pascal }}/index.ts`

```typescript
export * from './{{ inputs.name }}';
```
````

The front matter is where the metadata lives. name identifies the document, root and output set the directories the files are written relative to, and questions is a map of input name to the prompt text. The body is where the output files live: each heading is the path of a file, and each code block is its content, with the answers interpolated through the template syntax.

The pascal filter is the visible example of the built-in helpers. A user types PrettyDog and the template produces PrettyDog/index.ts and PrettyDog/PrettyDog.tsx, and the README shows the generated result, which is the exported type and a React function component wrapped in a div.

The whole point of that example is that the output is not a stub or a snippet. It is real TypeScript that compiles, and it was written by a human in a Markdown file, which is the trade the tool makes.

## Prettier integration, and a plugin for the template engine

The fourth feature in the README is formatting, and it is more than a convenience.

Markdown works very well with Prettier, and the templates maintain beautiful code, and the project also offers a Prettier Plugin for scaffdog's template engine. The plugin is published as its own package, prettier-plugin-scaffdog, and it appears in the release list at the same version as the CLI itself.

That combination is what makes the tool fit into an existing repository's standards. A generated file that is formatted the same way as the hand written files around it does not show up as an obvious generation artefact in a diff, and a template that Prettier can format keeps the embedded code blocks readable when the document is edited in an editor that formats Markdown.

The publishing split is worth noting too. The release list contains three packages moving together: scaffdog at 4.1.0, the Prettier plugin at 4.1.0, and @scaffdog/types at 4.1.0, all published within a second of each other on 2024-09-16. The type package exists so that a project can write its own tooling against the same types the CLI uses.

The installation instruction is the last piece of the picture, and it is a one-liner. The README points at the documentation site for customizing templates, and the same site carries the full reference for the engine and its helpers.

## A monorepo with turbo, pnpm workspaces and changesets

The repository layout shows a project organised as a workspace with several published packages.

The root package is private and named scaffdog-root, with workspaces covering packages/@scaffdog/* and packages/*. The package manager is pnpm at version 9.15.0, and the build and test orchestration is done with turbo, with scripts like turbo run build and turbo run test filtered to the packages directory. The website lives in its own directory with its own dev and build scripts.

The release process uses changesets. The changelog script is changeset add, the publish script is changeset publish, and there is a pair of scripts for entering and exiting a canary prerelease, which matches the default branch being canary rather than main. The repository also has a .changeset directory for pending changes, a .husky directory for git hooks, commitlint configuration, renovate for dependency updates, an eslint configuration, prettier configuration, and turbo and tsconfig base files.

The examples directory has two sample projects, a commonjs one and a module one, and there are separate test scripts for the examples, for end to end tests and for the packages themselves, with a test:all script that chains them. There is even a scaffold script, which uses the tool on itself.

For a user none of this matters much, and for a contributor it tells you the project is a normal modern TypeScript monorepo rather than a single package. The part that does matter to a user is that the CLI, the types and the Prettier plugin are versioned and published together.

## Migration notes for every major version, and where the tool stops

The README keeps a Migration section with a link for each major step, to v4 from v3, to v3 from v2, to v2 from v1 and to v1 from v0, all pointing at a single Migration Guide. That is a useful signal: a tool whose template syntax changes between majors needs those notes, and this one has them for every jump it has made.

The limits of the tool are visible in the design.

It is a text template engine, not a program. A scaffdog template can ask questions, filter answers and write files, and that is all. Anything that needs real control flow, that needs to inspect an existing repository, that needs to read the filesystem to decide what to generate, is outside what the engine can express, and the answer is to write a generator script instead. The README's own advice, that the template is a document, is the trade: readable and reviewable in exchange for expressiveness.

It is a Node tool. The requirement is Node.js v18.0.0 or later, the package is on npm, and the whole repository is a pnpm and TypeScript workspace. There is nothing to reuse from a Python or Go toolchain.

And the generated output is your problem afterwards. scaffdog writes files into a repository, and those files then have to be maintained by hand, formatted, linted and tested like anything else. The tool is about the first minute of a file's life, not its whole life.

On maintenance, the picture is mixed in a way worth checking before you depend on it. The repository is not archived and the last push was on 2026-10-18, so the source is being worked on. The published packages, however, are at 4.1.0 from 2024-09-16, and the two releases before that in the list are from the same day. So the npm artifacts are around two years old while the branch is current, and the canary prerelease flow exists precisely so that a canary build of the in-progress version can be published. If you need something newer than 4.1.0, that is the route the project provides.

## Conclusion

Node teams that keep component or module skeletons in a repository should try scaffdog, because the template is a Markdown document that a reviewer can read, the questions are declared in Front Matter, and the generated output is plain source code that lives in version control next to everything else. It is the wrong tool if your templates need real logic, because the engine is a template language rather than a program, and it is the wrong tool outside Node. Before adopting, read the migration guide for the major version you are moving to, and note that the published scaffdog package is at 4.1.0 from 2024-09-16 while the repository is still being worked on.

## FAQ

### How do I install scaffdog?

The README says scaffdog can be installed globally but recommends installing it locally on the project, with npm install --save-dev scaffdog. The requirement is Node.js v18.0.0 or later.

### What is a scaffdog template and where does it live?

A template is a Markdown document with Front Matter that defines metadata and questions, and code blocks whose headings name the files to generate. By default the document file and the configuration file are stored in the .scaffdog directory, and the init subcommand creates them.

### Which scaffdog version is published on npm?

The scaffdog package, the prettier-plugin-scaffdog package and the @scaffdog/types package were all published at version 4.1.0 on 2024-09-16. The repository itself is still being worked on, and the project publishes canary prereleases through changesets.

### Does scaffdog need Prettier?

No, but the project offers a Prettier Plugin for scaffdog's template engine as a separate package, and the README points out that Markdown works very well with Prettier, which is what keeps generated code formatted the same way as the rest of a repository.

## Sources

- [License: MIT](https://github.com/scaffdog/scaffdog/blob/canary/LICENSE)
- [Project website](https://scaff.dog)
- [README](https://github.com/scaffdog/scaffdog/blob/canary/README.md)
- [Releases](https://github.com/scaffdog/scaffdog/releases)
- [scaffdog/scaffdog on GitHub](https://github.com/scaffdog/scaffdog)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/scaffdog-scaffdog