De um diretório vazio a um build verde.

Ao lado do clone, com o próprio .claude/

A sessão roda numa cópia do repositório: um clone, ou a árvore que o /nerviz:new-project do plugin busca sem clone. O projeto é gerado ao lado dela, em ../<artifactId>. O /init-project, o project-bootstrap e o catálogo de blueprints ficam na cópia; o projeto recebe só o próprio .claude/, escrito pelo ArchHook.java export, que se recusa a escrever dentro do clone.

• O Claude Code pergunta antes de escrever fora do diretório em que a sessão começou. Para aprovar a geração uma vez, rode mkdir ../my-api e /add-dir ../my-api antes. Um diretório vazio é aceito.
• O desenvolvimento começa numa sessão nova, aberta no projeto gerado: só ela carrega o settings.json e os hooks do projeto.

# 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

Só o que a linha de comando não disse

A entrevista inteira acontece na sessão principal, antes de delegar qualquer coisa: blueprint, build, features, coordenadas, TLS e Sonar, no máximo quatro perguntas por chamada. O que --blueprint, --groupId, --name ou --bounded-context já dizem não é perguntado de novo. As features só são perguntadas onde o blueprint as deixa false: o hexagonal já liga REST, JPA com Flyway, OpenAPI, Testcontainers e Actuator, então a única pergunta oferece Kafka, como sim ou não. O bounded context é uma pergunta própria, com o artifactId como padrão: é o primeiro segmento do nome de todo tópico Kafka.

› /arch-doctor
› /init-project --blueprint hexagonal --build maven --name my-api

Uma skill, um agente, um procedimento

O init-project é um ritual manual: o modelo nunca o dispara sozinho. Ele não faz o trabalho, delega; e o project-initializer não reimplementa o procedimento, segue-o.

1. skillinit-project

   Entrevista você e entrega cada resposta ao agente. No fim, preenche o registro de gênese e encadeia o git-publish.

2. agentproject-initializer

   Roda num contexto isolado, com ferramentas restritas, no sonnet com esforço alto, e não pergunta nada.

3. skillproject-bootstrap

   O procedimento, passo a passo. O agente o segue; não o reimplementa.

• A base vem do start.spring.io na hora. Versão nunca é escrita de memória.
• Ele reestrutura por módulo ou por pacote, depois escreve o Checkstyle, o lombok.config, o logback-spring.xml, o Dockerfile e o compose, o mapa de fronteiras .claude/forbidden-imports.txt, o CLAUDE.md da raiz e o workflow de CI.
• Escreve o .claude/ do projeto num só comando, o ArchHook.java export, guiado pelo manifesto do extensions.json. Segurança de transporte e SonarQube são skills encadeadas, transport-security-setup e sonarqube-setup; as perguntas delas fazem parte da entrevista.
• A verificação é o único portão de qualidade: clean verify, depois os testes de fronteira, de lombok.config e de autonomia. Build vermelho é corrigido antes do relatório.

Um relatório em formato fixo

Com o build verde, o /init-project preenche o registro do run no GENESIS.md e só então encadeia o git-publish, que pergunta duas vezes: uma para rodar git init e fazer o primeiro commit, outra para criar o repositório no GitHub e dar push. Nada é commitado nem enviado sem esses dois portões.

# 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>

Um trecho do relatório de exemplo dos docs do nerviz, um projeto fictício. Nomes, versões e contagens são ilustrativos.

Abra uma sessão nova dentro do projeto

O projeto gerado é autocontido: quem o clona não precisa do Nerviz na máquina. As skills de criação, o agente project-initializer e o catálogo de blueprints ficam para trás de propósito, e o blueprint ativo viaja com o projeto para o /arch-adopt resolvê-lo na próxima atualização.

• O settings.json é lido uma vez, na partida da sessão. A sessão aberta no clone roda com os hooks do clone, não os do projeto: tudo parece funcionar e nada é imposto.
• Aceite o primeiro portão do git-publish: o hook de testes usa git diff HEAD, e num repositório sem commits ele sai sem rodar um teste.

# a new session, inside the generated project
cd ../my-api
claude
› /new-feature <what the first use case should do>