@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(__dirname, '.agent', 'skills'), dest: path.join(process.cwd(), '.agent', 'skills') });
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(__dirname, '.agent', 'agents'), dest: path.join(process.cwd(), '.agent', 'agents') });
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(__dirname, '.agent', 'workflows'), dest: path.join(process.cwd(), '.agent', 'workflows') });
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}: atualizado com sucesso`));
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
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@ruyfranca/myskills",
3
- "version": "1.0.24",
3
+ "version": "1.0.26",
4
4
  "description": "Biblioteca de skills customizadas para Antigravity / Claude Code",
5
5
  "main": "index.js",
6
6
  "bin": {