↑ ↓ to move · Enter to open · Esc to closeTap a result

← Where to start
New project · /init-project

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.

§ where the project is born

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-api and /add-dir ../my-api first. 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.json and 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
§ what it asks

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
§ who does what

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.

  1. skillinit-project

    Interviews you, then hands every answer to the agent. At the end it fills the genesis record and chains git-publish.

  2. agentproject-initializer

    Runs in an isolated context with restricted tools, on sonnet with high effort, and asks nothing.

  3. skillproject-bootstrap

    The procedure, step by step. The agent follows it; it does not reimplement it.

  • The base comes from start.spring.io at 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 root CLAUDE.md and the CI workflow.
  • It writes the project's .claude/ in one command, ArchHook.java export, driven by the manifest in extensions.json. Transport security and SonarQube are chained skills, transport-security-setup and sonarqube-setup; their questions are part of the interview.
  • Verification is the only quality gate: clean verify, then the boundary, lombok.config and autonomy tests. A red build is fixed before the report.
§ what comes out

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.

§ what happens next

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.json is 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-publish gate: the tests hook uses git 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>