# Craftsman: scaffolding vertical slices for .NET web APIs

> Craftsman is a dotnet global tool that generates the files for a vertical slice architecture web API, along with the EF Core, Docker, and test scaffolding around them. It is the code generation half of the Wrapt framework, and its release history reads as a record of how the .NET community's preferred libraries changed between 2022 and now.

**pdevito3/craftsman** — A .NET scaffolding tool to help you stop worrying about boilerplate and focus on your business logic 🚀

- Repository: https://github.com/pdevito3/craftsman
- Website: https://wrapt.dev
- Stars: 1,168 · Forks: 74
- Language: C#
- License: MIT
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/pdevito3-craftsman

## A code generator with opinions about architecture

Craftsman is a .NET scaffolding tool, and its own description gives the motivation plainly: a scaffolding tool to help you stop worrying about boilerplate and focus on your business logic. It is described as the workhorse behind the Wrapt framework and provides a suite of CLI commands for quickly scaffolding out new files and projects for your .NET Web APIs with simple CLI commands and configuration files.

The architecture it generates is vertical slice architecture, which is the key thing to understand before using it. Rather than a layers folder with controllers, services, and repositories, the generated code is organised by feature, and within a feature by the operation. The topic list on the repository is explicit about it, listing vertical-slice-architecture alongside cqrs, ddd, event-driven-architecture, masstransit, mediatr, rabbitmq, and automted-test-generation.

So this is not a general purpose project generator. It generates a specific shape of .NET web API, with the supporting pieces around it, and the shape is the product. If your team already has a house architecture, the tool is going to propose a different one.

The project is MIT licensed, written in C#, and the default branch is develop rather than main. The home page is wrapt.dev, the last push to the repository was on 2026-10-03, and the current release is v0.29.0 from the same day, with v0.28.3 and v0.28.2 from December 2024 before it. The gap between those two dates is the most interesting fact about the release history, and the changelog explains what happened in it.

## The quickstart is three commands

The installation requires the .NET 8 SDK along with EF Core, and then the tool itself is a dotnet global tool.

```bash
dotnet tool install -g craftsman
```

Then you generate a project:

```bash
craftsman new example MyFirstProject
```

That is the whole onboarding. The `new` command with a template name and a project name is the entry point, and the `example` template produces a project that includes the associated scaffolding.

The command vocabulary is visible in the release notes, which is where the interesting part is. There is an `add:feature` command, which was enhanced in version 0.12 to add more than just ad-hoc features. There is a `new:example` command for generating example projects with associated templates. There is a `register:producer` command for event producers. And the BFF commands were removed in 0.25, with the Duende BFF scaffolding itself having arrived back in 0.14.

So the tool is not just a project generator. It generates into an existing project too, adding features and the code around them, which is the mode you would use once the initial scaffolding has been shaped to your liking.

All of the documentation lives on wrapt.dev rather than in the repository, which is a common arrangement for a project where the framework and the generator are two halves of one thing.

## The changelog is a history of the .NET ecosystem

The release highlights in the README read like an archaeology of the .NET community's changing tastes over four years, and that is genuinely useful information for anyone deciding whether to commit to the tool.

The mapping library changed twice. Version 0.21 moved from Mapster to Mapperly. Earlier, in 0.16, the project moved from Automapper to Mapster, and version 0.22 added records for queries and commands and DTOs. If you are starting a new project today you get Mapperly, and the fact that the tool has migrated twice is a reasonable signal about how the project handles dependency churn.

The ORM and data layer changed shape too. Version 0.15 added repository and unit of work abstractions for better testing and validation, and version 0.20 added an intermediate model so that DTOs are not passed into the domain, along with specification support. Version 0.18 brought built in migrations and an environment service, and version 0.13 promoted DDD entities with private setters, factory methods, and associated fakers.

The test story is the other thread. Version 0.19 moved the test projects to XUnit, and 0.23 replaced Moq with NSub. Version 0.17 made the functional tests use a Docker database, and 0.12 updated the Docker utility for integration tests using Fluent Docker. Version 0.24 added Dependabot and GitHub Actions for tests, and 0.25 added an architecture test enhancement.

Several features came and went. Version 0.22 moved from Sieve to QueryKit for querying. Version 0.23 added a GetAll feature and Hangfire scaffolding. Version 0.15 added OpenTelemetry and Jaeger tracing, along with built in domain event support with unit test scaffolding. Version 0.21 added a new default error handler middleware with the existing one still optional. Version 0.14 added Duende BFF scaffolding, React scaffolding, and Dockerfile and Docker Compose scaffolding.

## What gets generated, and what it depends on

Looking across the release notes, the generated artefacts fall into a few groups.

The domain layer. Entities with private setters, factory methods, and fakers. Value objects, including a common value object scaffolding and an Email value object. A shared kernel. Soft delete capability. Specification support. Records for queries, commands, and DTOs, plus an intermediate model so DTOs do not reach the domain.

The application and API layer. Feature folders with endpoints, requests, responses, and handlers. A permissions upgrade in 0.13 that significantly simplified setup, which resulted in a new library, HeimGuard, that can be used in any .NET project. Users and roles managed in each boundary in 0.17, with AuthN still separate. Move permission guards to feature in 0.16. A new register:producer command.

The infrastructure layer. Built in migrations. A repository and unit of work. Docker and Docker Compose scaffolding. An auth server rewrite with Keycloak in 0.16, and auth server scaffolding with an in-memory implementation in 0.12. Options pattern configuration and an environment service.

The testing layer, which is the most thorough part. Integration tests with a service collection per test, so service mocking is possible without clashing with other tests, from version 0.19. Architecture tests. Unit test scaffolding for domain events. And an entire automated test generation angle, which is what the topic list calls automated-test-generation.

The direction of travel across all of it is a complete vertical slice with its tests, and the reason the generated code is worth reading is that it is opinionated about how a .NET API should be put together, not just about what files to create.

## The gaps in the project, stated by its author

The Upcoming Features section and the Contributing section both show a project run by one person, and the README is candid about it.

The author writes that there are refinement items in the pipe and that he is working through a deep example project to really dogfood the things, with updates coming from those findings. He also asks for feature requests on the Discord rather than assuming a roadmap.

The contributing section is more revealing. The recommendation is to open a topic for discussion before developing a pull request, and the author says he has not had enough pull request interest to put together a contributing.md, but will do a detailed writeup if there is interest. There is also a direct instruction in the README that any features or changes will not be merged without working unit tests, and that there should be no lint errors after any JavaScript file changes, which in this case means no errors after any file changes.

The contact section is similarly informal. If you file an issue and do not hear back within 24 to 48 hours you can ping him on Twitter or Discord, and there is a Discord channel for larger community discussions.

None of this is a complaint, it is a description of the risk. A scaffolding tool is a piece of infrastructure that a team then depends on, and depending on a single maintainer with a two year gap between releases means the upgrade path is less predictable than the version numbers suggest. The practical mitigation is to treat the generated code as a starting point you own, rather than as something you re-scaffold on every upgrade.

## Conclusion

Adopt Craftsman if you start .NET web APIs from the same shape repeatedly and want the feature, endpoint, test, and Docker files generated consistently. Do not adopt it if you have an established architecture the tool would fight, since it generates into a specific vertical slice layout. Verify first which template library choices the version you install makes, because the changelog shows the mapping library changing twice and the ORM scaffolding changing shape.

## FAQ

### What is Craftsman and what does it generate?

Craftsman is a .NET scaffolding tool providing CLI commands for quickly scaffolding out new files and projects for .NET web APIs using simple CLI commands and configuration files, generating a vertical slice architecture with the domain, application, infrastructure, and test layers around it.

### How do I install Craftsman and create a first project?

You need the .NET 8 SDK along with EF Core, then you run dotnet tool install -g craftsman to install the tool, and craftsman new example MyFirstProject to generate a project from the example template. All of the documentation is on wrapt.dev.

### Which mapping library does Craftsman generate code for?

Mapperly, which is where the project landed after migrating from Automapper to Mapster in version 0.16 and then from Mapster to Mapperly in version 0.21. Version 0.22 also added records for queries and commands and DTOs.

### Does Craftsman generate tests along with the feature code?

Yes. The README lists automated test generation as a project topic, and the release notes describe integration tests with a service collection per test from version 0.19, architecture test enhancements in 0.25, unit test scaffolding for domain events in 0.15, and functional tests using a Docker database in 0.17.

### What is the latest Craftsman release?

v0.29.0, published on 2026-10-03, with v0.28.3 and v0.28.2 from December 2024 before it. The current release includes primary constructors and updated API versioning, which were the 0.26 highlights.

## Sources

- [License: MIT](https://github.com/pdevito3/craftsman/blob/develop/LICENSE)
- [pdevito3/craftsman on GitHub](https://github.com/pdevito3/craftsman)
- [Project website](https://wrapt.dev)
- [README](https://github.com/pdevito3/craftsman/blob/develop/README.md)
- [Releases](https://github.com/pdevito3/craftsman/releases)

---

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