name: create-project description: Inicializar um novo projeto no layout padrão do usuário — .claude-root, .dir-locals.el (root: abreviação de link org), code/, spcfctn/code/ (com seu próprio repositório git) e um diretório .claude/ com seu próprio repositório git e um CLAUDE.md que define o idioma do projeto e seu código curto de duas letras (escolhido pelo usuário a partir das opções que o agente propõe) — e traduzir quaisquer arquivos já existentes para esse idioma. Use sempre que o usuário pedir para criar, iniciar, configurar, inicializar ou "оформити" um novo projeto (ou para trazer um diretório existente e vazio para o layout padrão).

create-project

Habilidade para criar um novo projeto na estrutura padrão do usuário. Tudo é feito de acordo com as regras globais de ~/.claude/rules/ (principalmente project-meta.md, spcfctn-code.md, org-babel.md, file-editing.md); aqui está apenas a sequência de ações.

A invocação explícita desta habilidade é a permissão para criar spcfctn/ (a regra global "peça ao usuário para criar spcfctn/" não se aplica aqui — o usuário já pediu).

Passo 0 — Preparação

A raiz do projeto é o diretório de trabalho atual (ou o diretório nomeado pelo usuário). Verifique o que já existe lá: ls -la, find -L (considere symlinks).
Se .claude-root, .claude/CLAUDE.md etc. já existirem — este não é um projeto novo: não sobrescreva nada, apenas complete o que está faltando e informe o que já estava presente.
Se spcfctn/ já fizer parte de um repositório compartilhado (monorepo) — não o divida. No relatório, diga isso e sugira uma divisão em subdiretórios preservando o histórico no próximo commit (spcfctn-code.md).
Antes de cada solicitação de permissão, forneça um breve resumo em ucraniano (file-editing.md).

Passo 1 — Idioma do projeto

Se o usuário não especificou o idioma na solicitação — pergunte via AskUserQuestion ("Em qual idioma o projeto será conduzido?": ucraniano, inglês, outro). Não escreva nenhum texto em prosa até saber o idioma.
O idioma do projeto se aplica aos arquivos do repositório (código, comentários, commits, org/md) e aos artefatos externos do projeto (tarefas Jira, páginas Confluence). O idioma do chat com o usuário é separado, sempre ucraniano.

Passo 1a — Código do projeto

Cada projeto tem seu próprio código curto de duas letras. Três letras — apenas em último caso, quando não houver opções aceitáveis de duas letras. A caixa não é fixa: depende do contexto de uso (por exemplo, chave de tarefa Jira — maiúsculas, KB-1676; prefixo em código ou nome — conforme a convenção do local, geralmente minúsculas). Portanto, nas propostas, mostre o código sem vinculação a caixa, e no CLAUDE.md registre na forma de uso principal e indique onde cada forma se aplica.

Não invente um código silenciosamente e não pegue o primeiro que vier: proponha explicitamente 3–4 opções interessantes que você mesmo goste (derivadas do nome do projeto, sua essência ou jogo de palavras — com uma breve explicação do porquê) e deixe o usuário escolher uma ou sugerir a própria. É conveniente fazer isso via AskUserQuestion (a primeira opção é a melhor na sua avaliação, marcada como "(Recommended)"; "Other" é adicionado automaticamente para o código próprio do usuário).
Verifique se o código escolhido não coincide com códigos de projetos existentes do usuário (pesquise em ~/.claude/projects/*/memory, .claude/CLAUDE.md de projetos vizinhos, se necessário locate); se coincidir, informe e ofereça outras opções.
Registre o código em .claude/CLAUDE.md (passo 3) e mencione no relatório final.

Passo 2 — Estrutura

Crie na raiz:

O quê	Conteúdo
`.claude-root`	arquivo vazio (marca a raiz do diretório de trabalho compartilhado)
`.dir-locals.el`	formulário abaixo, obrigatoriamente com quebra de linha final
`code/`	diretório vazio (aqui irão sub-repositórios/código)
`spcfctn/code/`	diretório, se ainda não existir (`spcfctn/` crie você mesmo, veja acima), e dentro dele um `git init` separado (ação rotineira, não precisa pedir permissão) e `.gitignore` com a única linha `*~`; não faça commit até que o usuário peça. O próprio `spcfctn/` não é um repositório
`.mcp.json`	vazio: `{"mcpServers": {}}` (`project-meta.md` — apenas MCP de escopo `project`, nunca `user`)
`env.org`	fonte literária de `.env.example` — veja abaixo
`.claude/`	veja passo 3

env.org — uma seção para cada servidor MCP do projeto (* Nome do MCP), descrevendo em prosa quais variáveis são necessárias e para quê; cada seção é tanglada (:noweb-ref) para um .env.example compartilhado (público, mostra apenas os NOMES das variáveis com placeholders, sem valores reais — org-babel.md, o modelo "multi-alvo" não é necessário aqui, o alvo é único). O .env real (com permissões 600, project-meta.md) o usuário configura por conta própria — não crie nem edite; .gitignore para ele na raiz do projeto não é necessário, pois a raiz nunca é um repositório git (project-meta.md). Se no momento da criação do projeto ainda não houver servidores MCP — env.org pode ficar com uma única frase de modelo ("Nenhum MCP conectado ainda") em vez de seções, e retorne quando o primeiro servidor aparecer.

.dir-locals.el (abreviatura root: para links org, portátil, sem caminhos hardcoded):

((org-mode
  . ((eval . (add-to-list 'org-link-abbrev-alist
                          (cons "root" (locate-dominating-file default-directory ".dir-locals.el")))))))

(No arquivo em si, isso é elisp puro — as linhas #+begin_example/#+end_example não entram.)

Se spcfctn/ui/ for necessário (análise de layouts) — será criado depois, conforme a necessidade; não crie diretórios vazios antecipadamente. Cada subdiretório de spcfctn/ que aparecer depois (ui/, deploy/ etc.) recebe imediatamente seu próprio git init e .gitignore com *~ — o próprio spcfctn/ não é um repositório. Não crie diretórios draft/, raw/, data/ até que haja o que colocar neles, e não adicione seus padrões ao .gitignore antecipadamente (project-meta.md).

Passo 3 — `.claude/`

mkdir .claude e separado git init exatamente em .claude/ (mesmo que a raiz seja um repositório git ou esteja dentro de outro). Esta é uma ação rotineira, não precisa pedir permissão. Não faça commit até que o usuário peça.
.claude/.gitignore:
```
settings.local.json
*~
```
(*~ — padrão genérico para arquivos de backup do Emacs, incluindo *.~undo-tree~; com quebra de linha final.)
.claude/CLAUDE.md — no idioma do projeto. Mínimo:
- seção sobre o idioma: toda a prosa do projeto (documentação, comentários de código, mensagens de commit, títulos org etc.) — no idioma do projeto; também artefatos Jira/Confluence; o chat com o usuário permanece em ucraniano;
- código do projeto (passo 1a) — em linha separada, ex.: "Código do projeto: kb (em chaves de tarefa Jira — KB)";
- descrição breve da estrutura: .claude-root marca a raiz; code/ — código; spcfctn/code/ — documentação da prática de código existente (git próprio); .claude/ — intenções e convenções do projeto (git próprio).
Não invente nada adicional (chave Jira, assignee etc.) — isso aparecerá no decorrer do trabalho.
Não escreva nada em settings.local.json — é pessoal e fora do git.

Passo 4 — Raiz não está no git

A raiz do projeto nunca é um repositório git (project-meta.md): não faça git init na raiz e não crie um .gitignore raiz. Se já houver .git na raiz — não mexa e informe o usuário no relatório. Se houver um .mcp.json raiz — não faça nada com ele.

Passo 5 — Tradução de arquivos existentes

Tudo o que estava no projeto antes da criação (exceto arquivos *~, .git, binários e os próprios arquivos de serviço recém-criados) — traduza para o idioma do projeto, se estiver em outro idioma:

Escreva o texto com tradução completa, preservando estrutura, tabelas, blocos de código, identificadores e citações (mensagens de erro mantenha no original).
Ucraniano: "перелік" em vez de "список" (para list); "зачіпка" para hook; não traduza identificadores e classes CSS (org-babel.md).
.md apenas o agente edita; .org — não remova edições incompreensíveis do usuário, pergunte. Para arquivos org com :tangle, edite a fonte org e tangle via emacsclient (org-babel.md).
Após editar parágrafos (prosa, não blocos de código nem tabelas), ajuste as quebras de linha com fill-paragraph real via emacsclient --eval (para org — primeiro (font-lock-ensure)); escreva o parágrafo em new_string/Write como uma única linha. Se emacsclient não conectar — peça ao usuário para iniciar o servidor, não simule.
Para prosa org/md, após isso, execute a habilidade org-lint.
Se parte do conteúdo se referir a arquivos/projetos que não estão aqui — não "corrija" os links, apenas traduza o texto ao redor.

Passo 6 — Relatório

Liste brevemente qual código do projeto foi escolhido, o que foi criado, o que já existia, o que foi traduzido, e lembre: commits em .claude/ e nos subdiretórios de spcfctn/ não foram feitos (faça quando solicitado).

O que não fazer

Não edite .env/.env.* (project-meta.md) e não crie .mcp.json com segredos.
Não escreva nada nos arquivos CLAUDE.md/.claude/ de sub-repositórios de componentes em code/* — apenas no .claude/ raiz.
Não invente regras de idioma pelo usuário — apenas o idioma solicitado.
Não atribua um código de projeto sozinho sem propor opções e obter a escolha do usuário.
Não faça git init na raiz do projeto nem na raiz de spcfctn/: repositórios apenas em .claude/, em code/* e nos subdiretórios de spcfctn/*.

EugineKosenko/majordom

O que é majordom?

Perguntar na sua IA favorita

Documentação