@connsoft-tech/claude-init 1.0.0

package/templates/.claude/rules/registro-decisoes.md.tpl

@@ -0,0 +1,18 @@
+# Regra: registro automático de decisões
+
+Sempre que, durante uma implementação, você tomar ou identificar uma
+decisão de arquitetura relevante (ex: escolha de padrão, trade-off entre
+duas abordagens, mudança que afeta múltiplos módulos, decisão que alguém
+vai perguntar "por que foi feito assim" no futuro), você deve:
+
+1. Antes de finalizar a tarefa, adicionar uma entrada em
+   `docs/architecture/decisions.md`, seguindo exatamente o formato descrito
+   no topo daquele arquivo.
+2. Não perguntar permissão para registrar — registrar faz parte de
+   finalizar a tarefa, assim como rodar o `reviewer`.
+3. NÃO registrar: preferências de estilo, detalhes de implementação sem
+   trade-off real, ou nada que já esteja coberto por uma regra existente
+   em `.claude/rules/`. O log é para decisões, não para changelog de código.
+4. Se a tarefa não envolveu nenhuma decisão nova (só implementação direta
+   de algo já padronizado), não crie entrada — não adicionar é o
+   comportamento correto nesse caso.

package/templates/.claude/rules/stack.md.tpl

@@ -0,0 +1,6 @@
+# Regra: stack permitida
+
+- Usar somente: {{LANGUAGE}}, {{DATABASE}}, mensageria: {{MESSAGING}}
+- Não sugerir nem introduzir frameworks/linguagens fora da stack acima
+  sem confirmação explícita.
+- Deploy sempre via: {{DEPLOY}}

package/templates/.github/workflows/auto-tag.yml.tpl

@@ -0,0 +1,31 @@
+name: Auto Tag Release
+
+on:
+  push:
+    branches: [{{RELEASE_BRANCH}}]
+
+jobs:
+  tag:
+    if: startsWith(github.event.head_commit.message, 'chore(release):')
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+
+      - name: Extrair versão do commit
+        id: version
+        run: |
+          VERSION=$(echo "${{ github.event.head_commit.message }}" | grep -oP 'v\K[0-9]+\.[0-9]+\.[0-9]+')
+          echo "version=$VERSION" >> "$GITHUB_OUTPUT"
+
+      - name: Criar e enviar a tag
+        env:
+          # ATENÇÃO: GITHUB_TOKEN não dispara outros workflows (ex: um
+          # segundo Action escutando "on: push tags" pra deploy). Se
+          # precisar encadear algo a partir da tag, troque por um
+          # Personal Access Token (secret RELEASE_PAT).
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: |
+          git tag "v${{ steps.version.outputs.version }}"
+          git push origin "v${{ steps.version.outputs.version }}"

package/templates/CLAUDE.root.md.tpl

@@ -0,0 +1,41 @@
+# {{PROJECT_NAME}} — contexto raiz
+
+Este arquivo é carregado em toda sessão do Claude Code. Mantenha curto —
+detalhes longos vão em `docs/architecture/` e são referenciados com `@`.
+
+## Stack
+- Linguagem/framework: {{LANGUAGE}}
+- Banco de dados: {{DATABASE}}
+- Mensageria: {{MESSAGING}}
+- Deploy: {{DEPLOY}}
+
+## Estrutura do repositório
+{{APPS_LIST}}
+
+Cada app/pacote acima tem seu próprio `CLAUDE.md` com padrões específicos,
+carregado automaticamente quando o Claude edita arquivos daquela pasta.
+
+## Referências de arquitetura
+- @docs/architecture/visao-geral.md
+- @docs/architecture/decisions.md
+- @specs/README.md
+
+## Regras globais
+- @.claude/rules/stack.md
+- @.claude/rules/convencoes.md
+- @.claude/rules/registro-decisoes.md
+
+## Fluxo de trabalho
+- Nova implementação: usar `/nova-implementacao`, que aciona o agente
+  `orchestrator` — ele conduz o fluxo spec-driven (specify → clarify →
+  plan → tasks → implement → validate) e delega para os agentes
+  especializados corretos.
+- Specs de features ficam em `specs/<slug>/` (requirements.md, design.md,
+  tasks.md) — ver @specs/README.md.
+
+{{LAYERS_SECTION}}
+## Comandos úteis
+- build: [definir]
+- test: [definir]
+- lint: [definir]
+- migrate: [definir]

package/templates/app/CLAUDE.app.md.tpl

@@ -0,0 +1,21 @@
+# {{APP_NAME}} — padrões deste pacote
+
+## Stack local
+- {{LANGUAGE}}
+- {{DATABASE}}
+- {{MESSAGING}}
+
+## Como implementar uma nova funcionalidade aqui
+1. Onde ficam as rotas/entradas: [definir]
+2. Onde fica a lógica de negócio: [definir]
+3. Como isolar por tenant (se multi-tenant): [definir]
+4. Padrão de resposta/erro: [definir]
+5. Onde ficam migrations: [definir]
+6. Onde ficam os testes: [definir]
+
+## Regras específicas de {{APP_NAME}}
+- [definir regras específicas deste pacote]
+
+{{LAYERS_SECTION}}
+## O que NÃO fazer aqui
+- [definir antipadrões conhecidos deste pacote]

package/templates/docs/architecture/README.md.tpl

@@ -0,0 +1,11 @@
+# Arquitetura — {{PROJECT_NAME}}
+
+Documentos de arquitetura detalhados ficam nesta pasta e são referenciados
+a partir dos `CLAUDE.md` via `@docs/architecture/<arquivo>.md`, mantendo
+os CLAUDE.md curtos.
+
+Sugestão de arquivos conforme o projeto crescer:
+- `visao-geral.md` — visão geral do sistema (já criado)
+- `multi-tenant.md` — estratégia de isolamento de tenant, se aplicável
+- `filas-eventos.md` — contratos de eventos/filas, se usar mensageria
+- `decisoes/ADR-000-exemplo.md` — Architecture Decision Records

package/templates/docs/architecture/decisions.md.tpl

@@ -0,0 +1,23 @@
+# Registro de decisões — {{PROJECT_NAME}}
+
+> Log append-only de decisões de arquitetura. Nunca edite ou apague uma
+> entrada antiga — se uma decisão for revertida, adicione uma nova entrada
+> referenciando a anterior.
+>
+> Este arquivo é atualizado automaticamente pelos agentes durante o
+> desenvolvimento (ver instrução em `.claude/rules/registro-decisoes.md`)
+> e também pode ser atualizado manualmente com `/registrar-decisao`.
+
+## Formato de cada entrada
+
+```
+## [AAAA-MM-DD] Título curto da decisão
+- Contexto: por que essa decisão precisou ser tomada
+- Decisão: o que foi decidido
+- Alternativas descartadas: o que mais foi considerado e por que não foi escolhido
+- Impacto: o que isso muda no código/arquitetura existente
+```
+
+---
+
+<!-- novas entradas são adicionadas abaixo desta linha -->

package/templates/docs/architecture/visao-geral.md.tpl

@@ -0,0 +1,17 @@
+# Visão geral da arquitetura — {{PROJECT_NAME}}
+
+## Componentes
+{{APPS_LIST}}
+
+## Stack
+- Linguagem/framework: {{LANGUAGE}}
+- Banco de dados: {{DATABASE}}
+- Mensageria: {{MESSAGING}}
+- Deploy: {{DEPLOY}}
+
+## Fluxo de dados principal
+[descrever como os componentes acima se comunicam]
+
+## Decisões relevantes
+[registrar decisões de arquitetura importantes; para decisões maiores,
+criar um ADR em docs/architecture/decisoes/]

package/templates/specs/README.md.tpl

@@ -0,0 +1,32 @@
+# Specs — {{PROJECT_NAME}}
+
+Cada feature/tarefa não trivial ganha uma pasta própria aqui, no formato
+`specs/<slug-da-feature>/`, contendo três arquivos:
+
+```
+specs/<slug-da-feature>/
+  requirements.md   — o que precisa ser feito e por quê
+  design.md          — como será feito (decisões técnicas, impacto)
+  tasks.md            — quebra em subtarefas executáveis
+```
+
+Não crie pastas separadas por tipo (`specs/requirements/`,
+`specs/design/`) — os três arquivos de uma mesma feature ficam sempre
+juntos, na pasta da feature. O slug da pasta é o mesmo usado na branch
+(`feature/<slug>`).
+
+## Fluxo (gerado pelo agente `orchestrator`)
+1. **specify** — `requirements.md`: contexto, requisitos, critério de
+   conclusão.
+2. **clarify** — antes de seguir para o design, o `orchestrator` confirma
+   com o usuário qualquer ambiguidade encontrada nos requisitos.
+3. **plan** — `design.md`: decisões técnicas, trade-offs, impacto em
+   outras camadas/apps.
+4. **tasks** — `tasks.md`: lista de subtarefas, cada uma já mapeada para
+   o agente especializado que vai executá-la.
+5. **implement** — delegação para os agentes especializados.
+6. **validate** — o `reviewer` confirma que a implementação satisfaz o
+   que está em `requirements.md` e `design.md`, não só padrões de código.
+
+Specs concluídas não são apagadas — servem de histórico e documentação
+viva de por que a feature foi construída daquele jeito.