@ruyfranca/myskills 1.0.24 → 1.0.26
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -0,0 +1,132 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: doc-coauthoring
|
|
3
|
+
description: Structured workflow for collaborative document creation. Use when writing documentation, proposals, technical specs, decision docs, PRDs, design docs, RFCs, or any substantial writing task. Guides through Context Gathering, Refinement and Structure, and Reader Testing stages.
|
|
4
|
+
tags: [documentation, writing, co-authoring, prd, rfc, spec, proposal, design-doc]
|
|
5
|
+
triggers: [write a doc, draft a proposal, create a spec, write up, PRD, design doc, decision doc, RFC, documentation, technical spec, co-author]
|
|
6
|
+
risk: safe
|
|
7
|
+
source: sickn33/antigravity-awesome-skills
|
|
8
|
+
date_added: "2026-03-15"
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# Doc Co-Authoring Workflow
|
|
12
|
+
|
|
13
|
+
Workflow estruturado para co-criação colaborativa de documentos. Atua como guia ativo, conduzindo o usuário por 3 etapas: **Coleta de Contexto**, **Refinamento & Estrutura** e **Teste com Leitor**.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Quando Ativar
|
|
18
|
+
|
|
19
|
+
**Gatilhos:**
|
|
20
|
+
- Usuário menciona escrever documentação: "escreve uma doc", "cria um PRD", "preciso de uma spec"
|
|
21
|
+
- Tipos específicos: **PRD, design doc, decision doc, RFC, proposta técnica**
|
|
22
|
+
- Qualquer tarefa de escrita substancial
|
|
23
|
+
|
|
24
|
+
**Oferta inicial:**
|
|
25
|
+
Ofereça o workflow estruturado. Explique as 3 etapas:
|
|
26
|
+
1. **Coleta de Contexto**: usuário fornece todo o contexto enquanto você faz perguntas
|
|
27
|
+
2. **Refinamento & Estrutura**: construir cada seção iterativamente via brainstorming e edição
|
|
28
|
+
3. **Teste com Leitor**: testar o doc com um Claude "sem contexto" para encontrar pontos cegos
|
|
29
|
+
|
|
30
|
+
Se o usuário recusar, trabalhe de forma livre. Se aceitar, inicie o **Estágio 1**.
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## Estágio 1: Coleta de Contexto
|
|
35
|
+
|
|
36
|
+
**Objetivo:** Fechar a lacuna entre o que o usuário sabe e o que você sabe.
|
|
37
|
+
|
|
38
|
+
### Coleta Ativa
|
|
39
|
+
Peça ao usuário que despeje tudo o que sabe sobre o tópico. Enquanto ele fala:
|
|
40
|
+
- Faça perguntas de acompanhamento sobre pontos que precisam de esclarecimento
|
|
41
|
+
- Identifique lacunas ou suposições
|
|
42
|
+
- Continue até ter contexto suficiente para guiar de forma inteligente
|
|
43
|
+
|
|
44
|
+
### Questões Típicas de Contexto
|
|
45
|
+
- **Propósito**: O que este documento alcança?
|
|
46
|
+
- **Audiência**: Quem vai ler? O que eles já sabem?
|
|
47
|
+
- **Escopo**: O que está dentro/fora do escopo?
|
|
48
|
+
- **Restrições**: Prazo, comprimento, formato, aprovadores?
|
|
49
|
+
- **Sucesso**: Como saber se o doc fez seu trabalho?
|
|
50
|
+
|
|
51
|
+
---
|
|
52
|
+
|
|
53
|
+
## Estágio 2: Refinamento & Estrutura
|
|
54
|
+
|
|
55
|
+
Trabalhe **uma seção por vez**:
|
|
56
|
+
|
|
57
|
+
### Passo 1: Perguntas Clarificadoras
|
|
58
|
+
Anuncie que vai trabalhar na seção [NOME DA SEÇÃO]. Faça 5-10 perguntas específicas sobre o que deve ser incluído.
|
|
59
|
+
|
|
60
|
+
### Passo 2: Brainstorming
|
|
61
|
+
Para a seção, faça brainstorming de 5-20 itens que poderiam ser incluídos. Numere cada um. Ofereça mais se o usuário quiser.
|
|
62
|
+
|
|
63
|
+
### Passo 3: Curação
|
|
64
|
+
Pergunte quais pontos manter, remover ou combinar:
|
|
65
|
+
- "Manter 1, 4, 7, 9"
|
|
66
|
+
- "Remover 3 (duplica o 1)"
|
|
67
|
+
- "Combinar 11 e 12"
|
|
68
|
+
|
|
69
|
+
Se o usuário der feedback livre ("ficou bom" ou "gostei de maioria, mas..."), extraia suas preferências e prossiga.
|
|
70
|
+
|
|
71
|
+
### Passo 4: Verificação de Lacunas
|
|
72
|
+
Baseado no que selecionou, pergunte se está faltando algo importante.
|
|
73
|
+
|
|
74
|
+
### Passo 5: Rascunho
|
|
75
|
+
Escreva o conteúdo da seção. Use `str_replace` para substituir o texto placeholder.
|
|
76
|
+
|
|
77
|
+
**Instrução para o usuário (inclua ao rascunhar a PRIMEIRA seção):**
|
|
78
|
+
*"Em vez de editar o doc diretamente, me diga o que mudar. Isso me ajuda a aprender seu estilo para as próximas seções. Por exemplo: 'Remove o bullet X - já coberto por Y' ou 'Deixa o terceiro parágrafo mais conciso'."*
|
|
79
|
+
|
|
80
|
+
### Passo 6: Refinamento Iterativo
|
|
81
|
+
Conforme o usuário dá feedback:
|
|
82
|
+
- Use `str_replace` para edits (nunca reimprima o doc inteiro)
|
|
83
|
+
- Continue até o usuário estar satisfeito com a seção
|
|
84
|
+
- Após 3+ iterações sem mudanças substanciais, pergunte se algo pode ser removido sem perder informação
|
|
85
|
+
|
|
86
|
+
**Repita para todas as seções.**
|
|
87
|
+
|
|
88
|
+
### Perto da Conclusão
|
|
89
|
+
Quando 80%+ das seções estiverem prontas:
|
|
90
|
+
1. Releia o documento inteiro e verifique: fluxo/consistência, redundância, "slop" genérico, frases sem peso
|
|
91
|
+
2. Forneça feedback final
|
|
92
|
+
3. Pergunte se está pronto para o Teste com Leitor
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
## Estágio 3: Teste com Leitor
|
|
97
|
+
|
|
98
|
+
**Objetivo:** Pegar pontos cegos antes que outras pessoas leiam.
|
|
99
|
+
|
|
100
|
+
### Abordagem de Teste
|
|
101
|
+
Analise o documento como se fosse um leitor **sem nenhum contexto da conversa**:
|
|
102
|
+
|
|
103
|
+
**Passo 1: Prever Perguntas do Leitor**
|
|
104
|
+
Liste 3-5 perguntas que um leitor novo faria ao ler o doc.
|
|
105
|
+
|
|
106
|
+
**Passo 2: Verificações Adicionais**
|
|
107
|
+
- O propósito/audiência fica claro nos primeiros parágrafos?
|
|
108
|
+
- Existem termos ou siglas não definidas?
|
|
109
|
+
- Alguma seção pressupõe conhecimento que o leitor não teria?
|
|
110
|
+
- O fluxo faz sentido sem saber da conversa que levou a isso?
|
|
111
|
+
|
|
112
|
+
**Passo 3: Relatório e Correção**
|
|
113
|
+
Para cada problema encontrado:
|
|
114
|
+
- Descreva o problema
|
|
115
|
+
- Sugira como corrigir
|
|
116
|
+
- Ofereça fazer a correção
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
## Revisão Final
|
|
121
|
+
|
|
122
|
+
- [ ] Propósito claro nos primeiros parágrafos?
|
|
123
|
+
- [ ] Audiência definida?
|
|
124
|
+
- [ ] Escopo explícito?
|
|
125
|
+
- [ ] Sem termos não definidos?
|
|
126
|
+
- [ ] Fluxo coerente entre seções?
|
|
127
|
+
- [ ] Cada frase carrega peso?
|
|
128
|
+
|
|
129
|
+
## Related Skills
|
|
130
|
+
- `writing-plans` — para planos de implementação técnica
|
|
131
|
+
- `documentation-templates` — templates e estrutura de documentação
|
|
132
|
+
- `brainstorming` — exploração criativa de ideias antes de escrever
|
|
@@ -0,0 +1,150 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: skill-developer
|
|
3
|
+
description: Guide for creating and managing skills in Antigravity/Claude Code. Use when creating new skills, understanding YAML frontmatter format, writing SKILL.md files, setting up trigger patterns, following the 500-line rule, or debugging skill activation issues.
|
|
4
|
+
tags: [skill-development, antigravity, claude-code, yaml, frontmatter, triggers, skill-creation]
|
|
5
|
+
triggers: [create a skill, new skill, skill template, skill frontmatter, SKILL.md, skill trigger, skill activation, 500-line rule, add skill to project]
|
|
6
|
+
risk: safe
|
|
7
|
+
source: sickn33/antigravity-awesome-skills
|
|
8
|
+
date_added: "2026-03-15"
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# Skill Developer Guide
|
|
12
|
+
|
|
13
|
+
Guia completo para criar e gerenciar skills no Antigravity/Claude Code, seguindo as melhores práticas da Anthropic incluindo a regra das 500 linhas e o padrão de divulgação progressiva.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Estrutura de uma Skill
|
|
18
|
+
|
|
19
|
+
```
|
|
20
|
+
.agent/skills/
|
|
21
|
+
└── minha-skill/
|
|
22
|
+
├── SKILL.md ← arquivo principal (obrigatório, < 500 linhas)
|
|
23
|
+
└── references/ ← detalhes opcionais referenciados pelo SKILL.md
|
|
24
|
+
└── guia-avancado.md
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## Template de SKILL.md
|
|
30
|
+
|
|
31
|
+
```markdown
|
|
32
|
+
---
|
|
33
|
+
name: minha-skill
|
|
34
|
+
description: Descrição breve incluindo palavras-chave que disparam esta skill.
|
|
35
|
+
Mencione tópicos, tipos de arquivo e casos de uso. Seja explícito sobre termos gatilho.
|
|
36
|
+
tags: [tag1, tag2, tag3]
|
|
37
|
+
triggers: [frase gatilho 1, frase gatilho 2, keyword]
|
|
38
|
+
risk: safe
|
|
39
|
+
source: community
|
|
40
|
+
date_added: "2025-01-15"
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
# Nome da Skill
|
|
44
|
+
|
|
45
|
+
## Propósito
|
|
46
|
+
Para que esta skill serve.
|
|
47
|
+
|
|
48
|
+
## Quando Usar
|
|
49
|
+
Cenários específicos e condições.
|
|
50
|
+
|
|
51
|
+
## Informação Principal
|
|
52
|
+
A orientação real, documentação, padrões, exemplos.
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## Regras de Ouro (Anthropic Best Practices)
|
|
58
|
+
|
|
59
|
+
| Regra | Detalhe |
|
|
60
|
+
|-------|---------|
|
|
61
|
+
| **< 500 linhas** | SKILL.md deve ter menos de 500 linhas — use arquivos de referência para detalhes |
|
|
62
|
+
| **Descrição com keywords** | Inclua TODOS os termos que disparam esta skill (max 1024 chars) |
|
|
63
|
+
| **Títulos claros** | Nomes em minúsculo com hífens, forma gerundiva preferida (verb + -ing) |
|
|
64
|
+
| **Exemplos reais** | Inclua exemplos de código reais, não genéricos |
|
|
65
|
+
| **Divulgação progressiva** | SKILL.md = visão geral; `references/` = profundidade |
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Campos do Frontmatter
|
|
70
|
+
|
|
71
|
+
```yaml
|
|
72
|
+
---
|
|
73
|
+
name: nome-da-skill # obrigatório: identificador único
|
|
74
|
+
description: "texto..." # obrigatório: inclui triggers e contexto
|
|
75
|
+
tags: [tag1, tag2] # recomendado: para indexação e busca
|
|
76
|
+
triggers: [frase, keyword] # recomendado: termos que ativam a skill
|
|
77
|
+
risk: safe # safe | caution | dangerous
|
|
78
|
+
source: community # origem da skill
|
|
79
|
+
date_added: "2025-01-15" # data de adição
|
|
80
|
+
---
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
---
|
|
84
|
+
|
|
85
|
+
## Como Criar uma Skill — Passo a Passo
|
|
86
|
+
|
|
87
|
+
### 1. Crie o arquivo
|
|
88
|
+
```bash
|
|
89
|
+
mkdir -p .agent/skills/minha-skill
|
|
90
|
+
touch .agent/skills/minha-skill/SKILL.md
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
### 2. Escreva o conteúdo
|
|
94
|
+
Siga o template acima. Foque em:
|
|
95
|
+
- **Propósito**: o que esta skill FAZ?
|
|
96
|
+
- **Quando usar**: condições específicas, não genéricas
|
|
97
|
+
- **Exemplos**: código real, comandos reais
|
|
98
|
+
|
|
99
|
+
### 3. Teste os gatilhos
|
|
100
|
+
Confirme que os `triggers` no frontmatter cobrem as frases que o usuário usaria naturalmente.
|
|
101
|
+
|
|
102
|
+
Exemplos de bons triggers:
|
|
103
|
+
```yaml
|
|
104
|
+
triggers: [create new component, add react component, novo componente react]
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
### 4. Adicione ao GEMINI.md ou arquivos de configuração
|
|
108
|
+
Para que o Antigravity indexe a skill, ela precisa estar no diretório `.agent/skills/` do projeto.
|
|
109
|
+
|
|
110
|
+
### 5. Iterate
|
|
111
|
+
- Teste com 3+ cenários reais antes de considerar pronto
|
|
112
|
+
- Refine os triggers baseado no uso real
|
|
113
|
+
- Adicione sections `references/` se ultrapassar 500 linhas
|
|
114
|
+
|
|
115
|
+
---
|
|
116
|
+
|
|
117
|
+
## Checklist de Qualidade
|
|
118
|
+
|
|
119
|
+
```
|
|
120
|
+
[ ] SKILL.md tem menos de 500 linhas?
|
|
121
|
+
[ ] Frontmatter tem `name` e `description`?
|
|
122
|
+
[ ] Description inclui palavras-chave que ativariam esta skill?
|
|
123
|
+
[ ] Triggers são naturais e cobrem variações de linguagem?
|
|
124
|
+
[ ] Há pelo menos um exemplo real no conteúdo?
|
|
125
|
+
[ ] A skill tem um propósito claro e delimitado?
|
|
126
|
+
[ ] Se > 300 linhas, há `references/` para detalhes?
|
|
127
|
+
```
|
|
128
|
+
|
|
129
|
+
---
|
|
130
|
+
|
|
131
|
+
## Divulgação Progressiva
|
|
132
|
+
|
|
133
|
+
Para skills complexas, divida o conteúdo:
|
|
134
|
+
|
|
135
|
+
```
|
|
136
|
+
SKILL.md (visão geral, < 500 linhas)
|
|
137
|
+
├── Propósito e quando usar
|
|
138
|
+
├── Conceitos chave com exemplos breves
|
|
139
|
+
└── Links para: [guia-avancado.md](./references/guia-avancado.md)
|
|
140
|
+
|
|
141
|
+
references/guia-avancado.md (detalhe técnico)
|
|
142
|
+
├── Tópico 1 aprofundado
|
|
143
|
+
├── Tópico 2 aprofundado
|
|
144
|
+
└── Edge cases e troubleshooting
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
## Related Skills
|
|
148
|
+
- `intelligent-routing` — como o Antigravity faz o roteamento automático de skills
|
|
149
|
+
- `clean-code` — boas práticas aplicadas à própria escrita de skills
|
|
150
|
+
- `brainstorming` — exploração antes de criar uma skill nova
|
|
@@ -0,0 +1,124 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: uncle-bob-craft
|
|
3
|
+
description: Applies Uncle Bob's body of work for code review and writing. Use when reviewing code, refactoring, discussing architecture, evaluating SOLID principles, identifying code smells, or discussing Clean Architecture, Clean Code, The Clean Coder principles.
|
|
4
|
+
tags: [clean-code, clean-architecture, solid, code-review, craftsmanship, refactoring, code-smells]
|
|
5
|
+
triggers: [code review, clean code, SOLID, refactor, architecture review, code smell, dependency rule, uncle bob, clean architecture, single responsibility, open closed, liskov, interface segregation, dependency inversion]
|
|
6
|
+
risk: safe
|
|
7
|
+
source: sickn33/antigravity-awesome-skills
|
|
8
|
+
date_added: "2026-03-15"
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
# Uncle Bob Craft
|
|
12
|
+
|
|
13
|
+
Agrega os princípios dos livros do Uncle Bob para **revisão** e **escrita** de código: nomenclatura e funções (Clean Code), arquitetura e fronteiras (Clean Architecture), profissionalismo e estimativa (The Clean Coder), valores ágeis (Clean Agile), e uso vs abuso de design patterns.
|
|
14
|
+
|
|
15
|
+
> **Não substitui** o linter, formatter ou testes automatizados do projeto — esses permanecem responsabilidade das ferramentas do projeto.
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## Quando Usar
|
|
20
|
+
|
|
21
|
+
- **Code review**: Aplique Dependency Rule, fronteiras, SOLID, e heurísticas de smell; sugira refactors concretos
|
|
22
|
+
- **Refactoring**: Decida o que extrair, onde desenhar fronteiras, e se um design pattern é justificado
|
|
23
|
+
- **Discussão de arquitetura**: Verifique camadas, direção de dependências, e separação de interesses
|
|
24
|
+
- **Design patterns**: Avalie uso correto vs cargo-cult ou overuse antes de introduzir um pattern
|
|
25
|
+
- **Estimativa e profissionalismo**: Aplique ideias do Clean Coder (dizer não, ritmo sustentável, estimativas de 3 pontos)
|
|
26
|
+
|
|
27
|
+
---
|
|
28
|
+
|
|
29
|
+
## Fontes por Livro
|
|
30
|
+
|
|
31
|
+
| Fonte | Foco |
|
|
32
|
+
|-------|------|
|
|
33
|
+
| **Clean Code** | Nomes, funções, comentários, formatação, testes, classes, smells |
|
|
34
|
+
| **Clean Architecture** | Dependency Rule, camadas, fronteiras, SOLID na arquitetura |
|
|
35
|
+
| **The Clean Coder** | Profissionalismo, estimativa, dizer não, ritmo sustentável |
|
|
36
|
+
| **Clean Agile** | Valores, Iron Cross, TDD, refactoring, pair programming |
|
|
37
|
+
| **Design Patterns** | Quando usar, abuso, cargo cult |
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## Dependency Rule (Clean Architecture)
|
|
42
|
+
|
|
43
|
+
```
|
|
44
|
+
Externas → Frameworks/Drivers
|
|
45
|
+
→ Interface Adapters
|
|
46
|
+
→ Application Business Rules
|
|
47
|
+
→ Enterprise Business Rules (Entities)
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
- Dependências apontam **para dentro** (em direção às Entities)
|
|
51
|
+
- Camadas internas **não conhecem** camadas externas
|
|
52
|
+
- **Violação**: quando uma Entity importa algo de um Controller
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## SOLID em Contexto
|
|
57
|
+
|
|
58
|
+
| Princípio | Verificação Rápida |
|
|
59
|
+
|-----------|-------------------|
|
|
60
|
+
| **SRP** | Esta classe/função tem mais de um motivo para mudar? |
|
|
61
|
+
| **OCP** | Posso adicionar comportamento sem modificar código existente? |
|
|
62
|
+
| **LSP** | Posso substituir por uma subclasse sem quebrar o sistema? |
|
|
63
|
+
| **ISP** | A interface tem métodos que os clientes não usam? |
|
|
64
|
+
| **DIP** | Módulos de alto nível dependem de abstrações, não de implementações? |
|
|
65
|
+
|
|
66
|
+
---
|
|
67
|
+
|
|
68
|
+
## Design Patterns: Uso vs Abuso
|
|
69
|
+
|
|
70
|
+
- **Use patterns** quando resolvem um problema de design real (variação de comportamento, ciclo de vida, cross-cutting)
|
|
71
|
+
- **Evite cargo-cult**: não adicione Factory/Strategy/Repository só porque o codebase "deveria" tê-los
|
|
72
|
+
- **Sinais de abuso**: nome do pattern em toda classe, camadas que só delegam sem lógica, patterns que tornam código simples mais difícil
|
|
73
|
+
- **Regra de ouro**: introduza um pattern na terceira duplicação ou segunda razão para mudar
|
|
74
|
+
|
|
75
|
+
---
|
|
76
|
+
|
|
77
|
+
## Code Smells e Heurísticas
|
|
78
|
+
|
|
79
|
+
| Smell | Significado |
|
|
80
|
+
|-------|-------------|
|
|
81
|
+
| **Rigidity** | Pequena mudança força muitas edições |
|
|
82
|
+
| **Fragility** | Mudanças quebram áreas não relacionadas |
|
|
83
|
+
| **Immobility** | Difícil de reusar em outro contexto |
|
|
84
|
+
| **Viscosity** | Fácil de hackear, difícil de fazer a coisa certa |
|
|
85
|
+
| **Needless Complexity** | Abstração especulativa ou não usada |
|
|
86
|
+
| **Needless Repetition** | DRY violado; mesma ideia em múltiplos lugares |
|
|
87
|
+
| **Opacity** | Código difícil de entender |
|
|
88
|
+
|
|
89
|
+
---
|
|
90
|
+
|
|
91
|
+
## Aplicação por Contexto
|
|
92
|
+
|
|
93
|
+
| Contexto | Aplicar |
|
|
94
|
+
|----------|---------|
|
|
95
|
+
| **Code review** | Dependency Rule e fronteiras; SOLID em contexto; listar smells; sugerir 1-2 refactors concretos (ex: extrair função, inverter dependência); verificar testes |
|
|
96
|
+
| **Escrevendo código** | Prefira funções pequenas e responsabilidade única; dependa para dentro (Clean Architecture); escreva testes primeiro quando fazendo TDD; evite patterns até duplicação ou variação justificar |
|
|
97
|
+
| **Refactoring** | Identifique um smell por vez; refatore em pequenos passos com testes verdes; melhore nomes e estrutura antes de adicionar comportamento |
|
|
98
|
+
|
|
99
|
+
---
|
|
100
|
+
|
|
101
|
+
## Ao Fazer Code Review
|
|
102
|
+
|
|
103
|
+
```
|
|
104
|
+
1. Dependency Rule está sendo respeitada?
|
|
105
|
+
2. SOLID violations óbvias?
|
|
106
|
+
3. Code smells presentes?
|
|
107
|
+
4. Nomes comunicam intenção?
|
|
108
|
+
5. Funções fazem uma coisa?
|
|
109
|
+
6. Testes presentes e significativos?
|
|
110
|
+
7. Design patterns justificados (ou desnecessários)?
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
**Formato de sugestão:**
|
|
114
|
+
```
|
|
115
|
+
Smell: [nome]
|
|
116
|
+
Local: [arquivo/função]
|
|
117
|
+
Refactor: [sugestão concreta]
|
|
118
|
+
Justificativa: [qual princípio ou heurística]
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
## Related Skills
|
|
122
|
+
- `clean-code` — regras práticas de código limpo
|
|
123
|
+
- `code-reviewer` — processo de code review
|
|
124
|
+
- `software-architecture` — padrões de arquitetura limpa e DDD
|
package/index.js
CHANGED
|
@@ -175,19 +175,21 @@ program
|
|
|
175
175
|
.option('-w, --workflows', 'Atualiza apenas os workflows')
|
|
176
176
|
.action(async (options) => {
|
|
177
177
|
const updateAll = !options.skills && !options.agents && !options.workflows;
|
|
178
|
+
const destRoot = process.cwd();
|
|
179
|
+
const srcRoot = __dirname;
|
|
178
180
|
|
|
179
181
|
console.log(chalk.cyan('\n🔄 Atualizando kit do Antigravity...\n'));
|
|
180
182
|
|
|
181
183
|
const tasks = [];
|
|
182
184
|
|
|
183
185
|
if (updateAll || options.skills) {
|
|
184
|
-
tasks.push({ label: 'skills', src: path.join(
|
|
186
|
+
tasks.push({ label: 'skills', src: path.join(srcRoot, '.agent', 'skills'), dest: path.join(destRoot, '.agent', 'skills') });
|
|
185
187
|
}
|
|
186
188
|
if (updateAll || options.agents) {
|
|
187
|
-
tasks.push({ label: 'agents', src: path.join(
|
|
189
|
+
tasks.push({ label: 'agents', src: path.join(srcRoot, '.agent', 'agents'), dest: path.join(destRoot, '.agent', 'agents') });
|
|
188
190
|
}
|
|
189
191
|
if (updateAll || options.workflows) {
|
|
190
|
-
tasks.push({ label: 'workflows', src: path.join(
|
|
192
|
+
tasks.push({ label: 'workflows', src: path.join(srcRoot, '.agent', 'workflows'), dest: path.join(destRoot, '.agent', 'workflows') });
|
|
191
193
|
}
|
|
192
194
|
|
|
193
195
|
for (const task of tasks) {
|
|
@@ -198,9 +200,60 @@ program
|
|
|
198
200
|
try {
|
|
199
201
|
await fs.ensureDir(task.dest);
|
|
200
202
|
await fs.copy(task.src, task.dest, { overwrite: true });
|
|
201
|
-
console.log(chalk.green(` ✅ ${task.label}:
|
|
203
|
+
console.log(chalk.green(` ✅ ${task.label}: copiado`));
|
|
202
204
|
} catch (err) {
|
|
203
|
-
console.error(chalk.red(` ❌ ${task.label}: erro — ${err.message}`));
|
|
205
|
+
console.error(chalk.red(` ❌ ${task.label}: erro na cópia — ${err.message}`));
|
|
206
|
+
continue;
|
|
207
|
+
}
|
|
208
|
+
}
|
|
209
|
+
|
|
210
|
+
// Rewrite hardcoded paths (file:///...mySkills...) to point to the dest project
|
|
211
|
+
if (destRoot !== srcRoot) {
|
|
212
|
+
console.log(chalk.cyan('\n🔧 Corrigindo paths nos arquivos copiados...\n'));
|
|
213
|
+
|
|
214
|
+
const srcPathEncoded = `file://${srcRoot}`;
|
|
215
|
+
const destPathEncoded = `file://${destRoot}`;
|
|
216
|
+
|
|
217
|
+
const dirsToFix = [
|
|
218
|
+
path.join(destRoot, '.agent', 'workflows'),
|
|
219
|
+
path.join(destRoot, '.agent', 'agents'),
|
|
220
|
+
path.join(destRoot, '.agent', 'rules'),
|
|
221
|
+
path.join(destRoot, '.agent', 'skills'),
|
|
222
|
+
];
|
|
223
|
+
|
|
224
|
+
let fixedFiles = 0;
|
|
225
|
+
|
|
226
|
+
for (const dir of dirsToFix) {
|
|
227
|
+
if (!await fs.pathExists(dir)) continue;
|
|
228
|
+
|
|
229
|
+
const walk = async (currentDir) => {
|
|
230
|
+
const entries = await fs.readdir(currentDir, { withFileTypes: true });
|
|
231
|
+
for (const entry of entries) {
|
|
232
|
+
const fullPath = path.join(currentDir, entry.name);
|
|
233
|
+
if (entry.isDirectory()) {
|
|
234
|
+
await walk(fullPath);
|
|
235
|
+
} else if (['.md', '.txt', '.json'].includes(path.extname(entry.name))) {
|
|
236
|
+
try {
|
|
237
|
+
const content = await fs.readFile(fullPath, 'utf8');
|
|
238
|
+
if (content.includes(srcPathEncoded)) {
|
|
239
|
+
const fixed = content.replaceAll(srcPathEncoded, destPathEncoded);
|
|
240
|
+
await fs.writeFile(fullPath, fixed, 'utf8');
|
|
241
|
+
fixedFiles++;
|
|
242
|
+
}
|
|
243
|
+
} catch {
|
|
244
|
+
// ignorar arquivos binários ou inacessíveis
|
|
245
|
+
}
|
|
246
|
+
}
|
|
247
|
+
}
|
|
248
|
+
};
|
|
249
|
+
|
|
250
|
+
await walk(dir);
|
|
251
|
+
}
|
|
252
|
+
|
|
253
|
+
if (fixedFiles > 0) {
|
|
254
|
+
console.log(chalk.green(` ✅ paths: ${fixedFiles} arquivo(s) corrigido(s)`));
|
|
255
|
+
} else {
|
|
256
|
+
console.log(chalk.gray(' ℹ️ paths: nenhuma substituição necessária'));
|
|
204
257
|
}
|
|
205
258
|
}
|
|
206
259
|
|
|
@@ -208,5 +261,6 @@ program
|
|
|
208
261
|
console.log(chalk.gray('💡 Dica: reinicie o Antigravity para carregar as novas skills/workflows.\n'));
|
|
209
262
|
});
|
|
210
263
|
|
|
264
|
+
|
|
211
265
|
program.parse();
|
|
212
266
|
|