From an empty directory to a green build.
/init-project turns a new directory next to the Nerviz clone into a Spring Boot project with declared architecture, executable boundaries and a green build, with no business code. The first feature comes from /new-feature.
Next to the clone, with its own .claude/
The session runs in a copy of the repository: a clone, or the tree the plugin's /nerviz:new-project fetches without one. The project is generated next to it, at ../<artifactId>. /init-project, project-bootstrap and the blueprint catalog stay in the copy; the project receives only its own .claude/, written by ArchHook.java export, which refuses to write into the clone itself.
- Claude Code asks before writing outside the directory the session started in. To approve the generation once, run
mkdir ../my-apiand/add-dir ../my-apifirst. An empty directory is accepted. - Development starts in a new session opened in the generated project: it is the only one that loads the project's
settings.jsonand hooks.
# with the plugin, no clone: in the directory that will hold the projects claude plugin marketplace add nerviz-ai/marketplace claude plugin install nerviz@nerviz cd ~/dev && claude › /nerviz:new-project # or with a clone git clone --depth 1 https://github.com/nerviz-ai/nerviz # approve the generation once, before /init-project mkdir ../my-api › /add-dir ../my-api
Only what the command line did not say
The whole interview happens in the main session, before anything is delegated: blueprint, build, features, coordinates, TLS and Sonar, at most four questions per call. What --blueprint, --groupId, --name or --bounded-context already say is not asked again. Features are asked only where the blueprint sets them false: hexagonal already turns on REST, JPA with Flyway, OpenAPI, Testcontainers and Actuator, so its one question offers Kafka, as a yes or no. The bounded context is its own question, defaulting to the artifactId: it is the first segment of every Kafka topic name.
› /arch-doctor › /init-project --blueprint hexagonal --build maven --name my-api
A skill, an agent, a procedure
init-project is a manual ritual: the model never triggers it on its own. It does not do the work; it delegates, and project-initializer does not reimplement the procedure, it follows it.
- skill
init-projectInterviews you, then hands every answer to the agent. At the end it fills the genesis record and chains
git-publish. - agent
project-initializerRuns in an isolated context with restricted tools, on
sonnetwith high effort, and asks nothing. - skill
project-bootstrapThe procedure, step by step. The agent follows it; it does not reimplement it.
- The base comes from
start.spring.ioat run time. Versions are never written from memory. - It restructures per module or per package, then writes Checkstyle,
lombok.config,logback-spring.xml, the Dockerfile and compose file, the boundary map.claude/forbidden-imports.txt, the rootCLAUDE.mdand the CI workflow. - It writes the project's
.claude/in one command,ArchHook.java export, driven by the manifest inextensions.json. Transport security and SonarQube are chained skills,transport-security-setupandsonarqube-setup; their questions are part of the interview. - Verification is the only quality gate:
clean verify, then the boundary,lombok.configand autonomy tests. A red build is fixed before the report.
A report in a fixed format
When the build passes, /init-project fills the run's record in GENESIS.md and only then chains git-publish, which asks twice: once to run git init and make the first commit, once to create the GitHub repository and push. Nothing is committed or pushed without those two gates.
# excerpt of the example report in docs/en/02-init-project.md, a fictional project ✅ Project pedidos-api created — blueprint hexagonal Modules: domain → depends on [] application → depends on [domain] adapters/adapter-in-rest → depends on [application, domain] adapters/adapter-out-persistence → depends on [application, domain] bootstrap → depends on [*] # … Business code: none — by design. 9 package-info.java written Boundaries: 9 rules in .claude/forbidden-imports.txt — blocking verified ✓ # … Build: PASSED # … Next steps: 1. /use-case-design <first-use-case-name>
An excerpt of the example report in nerviz's docs, a fictional project. Names, versions and counts are illustrative.
Open a new session inside the project
The generated project is self-contained: whoever clones it does not need Nerviz on their machine. The creation skills, the project-initializer agent and the blueprint catalog are left behind on purpose, and the active blueprint travels with the project so that /arch-adopt can resolve it on the next update.
settings.jsonis read once, at session startup. The session opened in the clone runs with the clone's hooks, not the project's, so everything looks like it works and nothing is enforced.- Accept the first
git-publishgate: the tests hook usesgit diff HEAD, and in a repository with no commits it exits without running a test.
# a new session, inside the generated project cd ../my-api claude › /new-feature <what the first use case should do>
- The skill
Its contract, its write territory and what the guard does with it.
init-project · the skill's page → - The full doc
In the nerviz repository.
02-init-project.md →