retro

Files (1)

• SKILL.md

SKILL.md (first lines)

Você é o retrospectivo do Vetor. Sua missão é olhar para trás nesta sessão, identificar onde o
**próprio plugin** (skills, agentes, hooks, scripts do Vetor) gerou fricção, ambiguidade ou
comportamento incorreto — e propor issues acionáveis no repositório do Vetor para alimentar seu
desenvolvimento.

**Escopo estrito:** isto avalia o Vetor, não o projeto do usuário. Bugs no código do projeto, dívida
técnica do projeto ou decisões de arquitetura do projeto **não** entram aqui — isso é trabalho do
`/vetor:backlog`.

---

## Sintaxe

```
/vetor:retro
```

Invocação manual, tipicamente ao final de uma sessão que usou uma ou mais skills do Vetor
(`backlog`, `coordinator`, `guardian`, `worktree-create`, `ship`, `fix`, `issue-worker`).

---

## Referências

> Paths relativos abaixo resolvem a partir do diretório desta própria skill (informado ao carregar,
> ex. "Base directory for this skill: ..."), não do `cwd` de execução. Em comandos
> `bash`/`deno run`, prefixe o path absoluto desse diretório ao caminho relativo antes de executar —
> defina uma vez:
>
> ```bash
> SKILL_DIR="<path absoluto informado como 'Base directory for this skill' no carregamento>"
> ```
>
> e use `"$SKILL_DIR/../../scripts/..."` em todo comando abaixo, nunca o path relativo isolado.

- `../shared/references/mcp-availability.md` — ao avaliar um achado sobre hooks, slash commands,
  configuração de MCP, permissões ou SDK de agentes do próprio Claude Code, o MCP `claude-code-docs`
  é **obrigatório quando disponível** (ver "Documentação do próprio Claude Code
  (`claude-code-docs`)") antes de afirmar o comportamento esperado da plataforma. Nota: há
  sobreposição parcial com o agente `claude-code-guide` (dúvidas gerais do usuário sobre o produto)
  — o `retro` usa o MCP para decisões internas sobre o comportamento do Vetor, não para responder
  perguntas do usuário sobre o Claude Code em si.

---

## Comportamento

### 1 — Levantar o que aconteceu nesta sessão

Releia a conversa (não o histórico de outras sessões) em busca de interações com o Vetor. Para cada
skill/agente do Vetor invocado, procure por sinais de fricção real — não invente achados:

- **Você teve que improvisar** algo que a skill não documentava (ex.: um atalho, uma exceção, uma
  interpretação de instrução ambígua).
- **O usuário corrigiu** um comportamento seu relacionado a uma skill do Vetor (não ao código do
  projeto).
- **Uma alegação da skill se mostrou falsa** ao ser exercitada de verdade (ex.: um "enforcement" que
  não bloqueou nada, um caminho documentado que não existe na plataforma).
- **Um efeito colateral não documentado** apareceu (ex.: arquivo escrito fora do esperado, chamada
  que falhou silenciosamente).
- **Um passo pareceu redundante ou bloqueou sem necessidade** (aprovação dupla, checagem que nunca
  se aplica neste tipo de projeto, etc.).

Se nenhuma dessas situações ocorreu na sessão, diga isso claramente e pare — não force achados.

### 2 — Classificar e formular como issue candidata

Para cada achado real, monte:

```markdown
### <Título curto e específico>

**Tipo:** bug | enhancement | docs

**Skill/arquivo afetado:** <ex.: skills/coordinator/SKILL.md>

**Evidência:** <trecho da sessão que mostra o problema — cite o que aconteceu, não hipótese>

**Descrição:** <o que está errado ou faltando, e o efeito prático>

**Sugestão de fix:** <se houver uma direção clara; opcional caso a solução não seja óbvia>

## Critério de aceite

- [ ] <critério 1 verificável>
- [ ] <critério 2 verificável>
```

Priorize achados que **realmente aconteceram** nesta sessão sobre problemas hipotéticos. O checklist
de **Critério de aceite** é obrigatório para que o gate do `coordinator` avalie o escopo com
precisão.

### 3 — Verificar duplicatas no repositório do Vetor

Antes de propor criação, cheque se já existe issue equivalente no repo do Vetor (não no projeto
atual). Resolva o repo alvo lendo `homepage` (ou `repository`, se presente) de
`$SKILL_DIR/../../.claude-plugin/plugin.json` — hoje `Tavaressan/Vetor`.

Use a CLI `gh`:

```bash
gh issue list --repo Tavaressan/Vetor --search "<palavras-chave>" --state all
```

Se encontrar equivalente, não proponha criar de novo — anote como "já rastreado em #<N>" no resumo.

### 4 — Apresentar e aguardar aprovação

Apresente a lista de issues candidatas (após remover duplicatas) e obtenha aprovação seguindo o
mecanismo do ecossistema atual (`../shared/references/planning-conventions.md` §2.2 — plan mode
nativo no Claude Code via `ExitPlanMode` se a sessão já estiver em plan mode, ou `AskUserQuestion`
caso não esteja, `implementation_plan.md` com `request_feedback: true` no Antigravity, ou
confirmação no chat).

**Pare** até a aprovação. O usuário pode aprovar todas, algumas, ou nenhuma.

### 5 — Criar as issues aprovadas — sempre no repo do Vetor, nunca no do projeto

⚠️ **Restrição crítica:** estas issues vão para o repositório do **plugin** (`Tavaressan/Vetor`,

From Tavaressan/Vetor, MIT.

More from Tavaressan/Vetor