Setup leandrocfe Skills
Faz o scaffold da configuração por-repo que as engineering skills assumem:
- Issue tracker — onde issues vivem (GitHub por default; markdown local também é suportado out of the box)
- Triage labels — as strings usadas para as cinco roles canônicas de triage
- Domain docs — onde
CONTEXT.mde ADRs vivem, e as regras de consumo para lê-los
Esta é uma skill prompt-driven, não um script determinístico. Explore, apresente o que achou, confirme com o usuário, depois escreva.
Processo
1. Explore
Olhe o repo atual para entender o estado inicial. Leia o que existe; não assuma:
git remote -ve.git/config— é um repo GitHub? Qual?AGENTS.mdeCLAUDE.mdna raiz do repo — algum existe? Já há uma seção## Agent skillsem algum?CONTEXT.mdeCONTEXT-MAP.mdna raiz do repodocs/adr/e quaisquer diretóriossrc/*/docs/adr/docs/agents/— output anterior desta skill já existe?.scratch/— sinal de que uma convenção de issue tracker em markdown local já está em uso- A skill
triageestá instalada? (uma pasta de skilltriageao lado desta, outriagenas suas skills disponíveis.) Isso decide se a Seção B roda ou não. - Sinais de monorepo — um
pnpm-workspace.yaml, um campoworkspacesnopackage.json, ou umpackages/*populado comsrc/próprio. Presentes só num repo multi-package genuinamente grande; a ausência deles significa single-context, que é quase todo repo.
2. Apresente findings e pergunte
Resuma o que está presente e o que falta. Depois tome as seções em ordem — uma seção, uma resposta, depois a próxima.
Lidere cada seção com a resposta recomendada, para o usuário poder aceitá-la numa palavra. Dê um explainer de uma linha só quando a escolha genuinamente ramifica; pule a seção inteira quando a exploração já a resolveu (Seção B quando triage não está instalada, Seção C quando não há monorepo).
Seção A — Issue tracker.
Explainer: O "issue tracker" é onde issues vivem para este repo. Skills como
to-tickets,triageeto-specleem e escrevem nele — precisam saber se chamamgh issue create, escrevem um markdown sob.scratch/ou seguem algum outro workflow que você descreve. Escolha o lugar onde você de fato rastreia trabalho deste repo.
Postura default: estas skills foram desenhadas para GitHub. Se um git remote aponta para GitHub, proponha. Se um git remote aponta para GitLab (gitlab.com ou host self-hosted), proponha GitLab. Senão (ou se o usuário preferir), ofereça:
- GitHub — issues vivem no GitHub Issues do repo (usa CLI
gh) - GitLab — issues vivem no GitLab Issues do repo (usa CLI
glab) - Markdown local — issues vivem como arquivos sob
.scratch/<feature>/neste repo (bom para projetos solo ou repos sem remote) - Other (Jira, Linear, etc.) — peça ao usuário para descrever o workflow num parágrafo; a skill registra como prosa freeform
Registre a escolha em docs/agents/issue-tracker.md. Os templates GitHub e GitLab carregam uma flag "PRs como superfície de request", com default off — deixe-a off e não a levante; um usuário que quer PRs externos na fila de triage pode virar a flag no arquivo depois.
Seção B — Vocabulário de triage labels. Pule esta seção inteira se a skill triage não estiver instalada (a exploração te disse) — uma skill não instalada não precisa de labels.
Se estiver instalada, faça exatamente uma pergunta:
Você quer manter os triage labels default? (recomendado: sim)
Os defaults são as cinco roles canônicas, cada string de label igual ao seu nome: needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix. Em sim, escreva-os como estão. Só se o usuário disser não — geralmente porque o tracker dele já usa outros nomes (ex.: bug:triage para needs-triage) — colete os overrides para o triage aplicar labels existentes em vez de criar duplicatas.
Seção C — Docs de domínio. Default para single-context — um CONTEXT.md + docs/adr/ na raiz do repo. Isso serve para quase todo repo; escreva sem perguntar.
Ofereça multi-context — um CONTEXT-MAP.md na raiz apontando para arquivos CONTEXT.md por contexto — só quando a exploração achou sinais de monorepo. Aí confirme qual layout ele quer.
3. Confirme e edite
Mostre ao usuário um rascunho de:
- O bloco
## Agent skillspara adicionar a qualquer um entreCLAUDE.md/AGENTS.mdque estiver sendo editado (veja step 4 para regras de seleção) - O conteúdo de
docs/agents/issue-tracker.md,docs/agents/domain.mdedocs/agents/triage-labels.md(o último só quandotriageestá instalada)
Deixe ele editar antes de escrever.
4. Escreva
Escolha o arquivo a editar:
- Se
CLAUDE.mdexistir, edite. - Senão se
AGENTS.mdexistir, edite. - Se nenhum existir, pergunte ao usuário qual criar — não escolha por ele.
Nunca crie AGENTS.md quando CLAUDE.md já existe (ou vice-versa) — sempre edite o que já está lá.
Se um bloco ## Agent skills já existe no arquivo escolhido, atualize seu conteúdo in-place em vez de anexar duplicata. Não sobrescreva edits do usuário nas seções ao redor.
O bloco:
## Agent skills
### Issue tracker
[resumo de uma linha de onde issues são rastreadas]. Veja `docs/agents/issue-tracker.md`.
### Triage labels
[resumo de uma linha do vocabulário de labels]. Veja `docs/agents/triage-labels.md`.
### Domain docs
[resumo de uma linha do layout — "single-context" ou "multi-context"]. Veja `docs/agents/domain.md`.
Inclua o sub-bloco ### Triage labels, e escreva docs/agents/triage-labels.md, só quando triage está instalada e a Seção B rodou. Quando não está, ambos são omitidos.
Depois escreva os docs files usando os templates seed nesta pasta de skill como ponto de partida:
- issue-tracker-github.md — issue tracker GitHub
- issue-tracker-gitlab.md — issue tracker GitLab
- issue-tracker-local.md — issue tracker markdown local
- triage-labels.md — mapeamento de labels (só se
triageestá instalada) - domain.md — regras de consumidor de docs de domínio + layout
Para issue trackers "other", escreva docs/agents/issue-tracker.md do zero usando a descrição do usuário.
5. Done
Diga ao usuário que o setup está completo e quais engineering skills agora vão ler desses arquivos. Mencione que ele pode editar docs/agents/*.md direto depois — re-rodar esta skill só é necessário se ele quiser trocar de issue tracker ou recomeçar do zero.