@onion-ai/cli 1.0.0-beta.1

package/framework/commands/product/light-arch.md

@@ -0,0 +1,82 @@
+---
+name: light-arch
+description: Design de arquitetura leve para features.
+model: sonnet
+category: product
+tags: [architecture, design, planning]
+version: "3.0.0"
+updated: "2025-11-24"
+---
+
+# Início da Engenharia
+
+Este é o comando para disparar o início do design de arquitetura para uma funcionalidade.
+
+## Análise
+
+1. Passe pelos cards, pais e filhos se necessário, e construa um entendimento inicial do que precisa ser construído. Pense cuidadosamente sobre o que é solicitado, certifique-se de que entende exatamente:
+    - Por que isso está sendo construído (contexto)
+    - Qual é o resultado esperado para esta task? (objetivo)
+    - Como deve ser construído, apenas direcionalmente, não em detalhes (abordagem)
+    - Se requer usar novas APIs/ferramentas, você as entende?
+    - Como deve ser testado?
+    - Quais são as dependências?
+    - Quais são as restrições?
+
+2. Depois de refletir sobre essas perguntas, elabore os 3-5 esclarecimentos mais importantes necessários para completar a tarefa.
+
+3. Pergunte ao humano essas questões, ao mesmo tempo fornecendo seu entendimento e sugestões. PAUSE para aguardar as respostas do humano.
+
+4. Depois de obter as respostas do humano, considere se precisa fazer mais perguntas. Se sim, faça mais perguntas ao humano. PAUSE para aguardar as respostas do humano.
+
+5. Uma vez que tenha um bom entendimento do que está sendo construído, declare-o claramente de volta ao humano para revisão. Faça isso na forma de um artefato para que seja mais fácil de revisar.
+
+6. Se o humano concordar com seu entendimento, você pode proceder para o próximo passo. Caso contrário, continue iterando juntos até obter aprovação explícita para prosseguir.
+
+7. Se algo que vocês discutiram aqui afeta o que foi escrito nos requisitos, peça permissão ao humano para editar esses requisitos e fazer ajustes seja editando (mudanças estruturais) ou adicionando comentários (esclarecimentos). Se o requisito está em um card do ClickUp, edite o card do ClickUp.
+
+8. Não proceda para o próximo passo a menos que o humano tenha claramente dado o sinal verde nesta fase.
+
+## Arquitetura
+
+Dado seu entendimento do que será construído, você agora procederá ao desenvolvimento da arquitetura da funcionalidade. O documento de arquitetura deve mapear o que está sendo construído, os componentes, as dependências, os padrões, as tecnologias, as restrições, as suposições, os trade-offs, as alternativas, as consequências.
+
+Aqui é onde você colocará seu chapéu de super pensamento e considerará o melhor caminho para construir a funcionalidade, ao mesmo tempo considerando os padrões e melhores práticas para este projeto.
+
+1. Passe pelo código-fonte relevante, entenda sua estrutura e propósito e procure pelos arquivos importantes para esta implementação.
+
+2. Revise os documentos de meta specs técnicas do projeto para garantir que esta funcionalidade se alinhe com nossa visão técnica
+
+3. Construa uma proposta de arquitetura que se alinhe com os padrões e melhores práticas do projeto.
+
+Dicas:
+   - Use as ferramentas code-expert (se disponíveis) para encontrar arquivos específicos baseados nas respostas de descoberta
+   - Mergulhe fundo em funcionalidades e padrões similares
+   - Analise detalhes específicos de implementação
+   - Use WebSearch ou context7 para melhores práticas ou documentação de biblioteca (se necessário)
+
+Seu documento de arquitetura deve incluir:
+    - Uma visão geral de alto nível do sistema (antes e depois da mudança)
+    - Componentes afetados e seus relacionamentos, dependências
+    - Padrões e melhores práticas que serão mantidos ou introduzidos
+    - Dependências externas que serão usadas ou que precisam ser adicionadas ao projeto
+    - Restrições e suposições
+    - Trade-offs e alternativas
+    - Consequências negativas (se houver) ao implementar este design
+    - Lista dos principais arquivos a serem editados/criados
+
+Se ajudar a construir um diagrama MERMAID, sinta-se livre para fazê-lo.
+
+4. Se, em algum ponto, você tiver perguntas ou se encontrar algo que contradiz o que entendeu anteriormente, peça esclarecimento ao humano.
+
+5. Uma vez que tenha um bom entendimento do que está sendo construído, mostre ao usuário na forma de um artefato e aguarde sua aprovação. Iterate juntos até estar pronto. PAUSE para aguardar a aprovação do humano.
+
+6. Quando o humano concordar com seu entendimento, você pode proceder ao próximo passo, salvando os detalhes da arquitetura no card do ClickUp como um comentário ao card original.
+
+## Pesquisa
+
+Se não tiver certeza de como uma biblioteca específica funciona, você pode usar Context7 e Perplexity para buscar informações sobre ela. Então, não tente adivinhar.
+
+<feature-slug>
+#$ARGUMENTS
+</feature-slug>

package/framework/commands/product/presentation.md

@@ -0,0 +1,174 @@
+---
+name: presentation
+description: |
+  Criação de apresentações profissionais via Gamma.app.
+  Use para gerar apresentações a partir de temas, tasks ou documentos.
+model: sonnet
+
+parameters:
+  - name: topic
+    description: Tema, task_id ou documento para a apresentação
+    required: true
+  - name: type
+    description: Tipo (pitch/product/technical/business/report)
+    required: false
+
+category: product
+tags:
+  - presentation
+  - gamma
+  - content
+
+version: "3.0.0"
+updated: "2025-11-24"
+
+related_commands:
+  - /product/task
+  - /docs/build-business-docs
+
+related_agents:
+  - presentation-orchestrator
+  - storytelling-business-specialist
+  - gamma-api-specialist
+---
+
+# 🎨 Criação de Apresentações
+
+Wrapper para criação de apresentações via @presentation-orchestrator.
+
+## 🎯 Objetivo
+
+Criar apresentações profissionais no Gamma.app de forma automatizada.
+
+## ⚡ Fluxo de Execução
+
+### Passo 1: Identificar Tipo de Input
+
+Analisar `{{topic}}` para determinar fonte:
+
+| Pattern | Tipo | Ação |
+|---------|------|------|
+| `86adf...` | Task ID | Buscar dados no ClickUp |
+| `docs/...` | Documento | Ler arquivo |
+| Texto livre | Tema | Pesquisar codebase |
+
+### Passo 2: Detectar Tipo de Apresentação
+
+SE `{{type}}` fornecido → usar diretamente
+SENÃO → inferir do contexto:
+
+| Contexto | Tipo Inferido |
+|----------|---------------|
+| Investidores, funding | `pitch` |
+| Novo recurso, release | `product` |
+| Arquitetura, API | `technical` |
+| Resultados, métricas | `business` |
+| Status, progresso | `report` |
+
+### Passo 3: Coletar Dados
+
+#### Task ClickUp
+
+```
+Buscar via mcp_clickup:
+- Nome e descrição
+- Subtasks e progresso
+- Comentários relevantes
+- Métricas associadas
+```
+
+#### Documento
+
+```
+Ler arquivo e extrair:
+- Título e resumo
+- Pontos principais
+- Dados e métricas
+- Conclusões
+```
+
+#### Tema Geral
+
+```
+Pesquisar no codebase:
+- Arquivos relacionados
+- Documentação existente
+- README e specs
+```
+
+### Passo 4: Estruturar Narrativa
+
+Delegar para @storytelling-business-specialist:
+
+```
+Definir:
+- Audiência-alvo
+- Objetivo da apresentação
+- Arco narrativo
+- Pontos-chave (5-10)
+```
+
+### Passo 5: Gerar Apresentação
+
+Invocar @presentation-orchestrator com:
+
+```yaml
+topic: [tema extraído]
+type: [tipo detectado]
+audience: [audiência]
+key_points: [pontos-chave]
+data: [dados coletados]
+```
+
+### Passo 6: Entregar Resultado
+
+## 📤 Output Esperado
+
+### Sucesso
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+✅ APRESENTAÇÃO CRIADA
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+📊 [Título da Apresentação]
+
+📋 Detalhes:
+∟ Tipo: Product Launch
+∟ Slides: 12
+∟ Audiência: Stakeholders
+∟ Fonte: Task #86adf8jj6
+
+🎨 Assets:
+∟ Gamma: https://gamma.app/docs/xxx
+∟ PDF: apresentacao.pdf
+∟ Outline: outline.md
+
+🚀 Próximos Passos:
+∟ Revisar conteúdo
+∟ Ajustar design
+∟ Compartilhar com equipe
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+### Tipos de Apresentação
+
+| Tipo | Slides | Estrutura |
+|------|--------|-----------|
+| `pitch` | 10-15 | Problema → Solução → Mercado → Tração → Ask |
+| `product` | 8-12 | Contexto → Feature → Demo → Benefícios → CTA |
+| `technical` | 12-20 | Arquitetura → Componentes → Fluxos → API |
+| `business` | 10-15 | Contexto → Resultados → Análise → Próximos |
+| `report` | 5-10 | Status → Progresso → Bloqueios → Timeline |
+
+## 🔗 Referências
+
+- Agente principal: @presentation-orchestrator
+- Storytelling: @storytelling-business-specialist  
+- API técnica: @gamma-api-specialist
+
+## ⚠️ Notas
+
+- Requer Gamma.app configurado (GAMMA_API_KEY)
+- Para config: `/meta/setup-integration gamma`
+- Tempo médio: 2-5 minutos por apresentação

package/framework/commands/product/refine.md

@@ -0,0 +1,161 @@
+---
+name: refine
+description: Refine requirements through clarification questions.
+model: sonnet
+category: product
+tags: [requirements, refinement, clarification]
+version: "3.0.0"
+updated: "2025-11-24"
+
+related_commands:
+  - /product/estimate
+  - /product/task
+
+related_agents:
+  - story-points-framework-specialist
+  - product-agent
+---
+
+You are a product specialist tasked with helping a human refine requirements for a project they are working on. Your goal is to take an initial requirement, ask clarifying questions, summarize your understanding, and create a markdown file with the refined requirements. Follow these steps:
+
+1. Clarification Phase:
+   Read the initial requirement. Ask clarifying questions to achieve clarity about the feature's objective and its requirement details. Continue asking questions until you have a comprehensive understanding of the feature.
+
+2. Summary and Approval Phase:
+   Once you have collected sufficient information, present a summary of your understanding to the user. Use the following format:
+   <summary>
+   Based on our discussion, here is my understanding of the feature requirements:
+   [Provide a concise summary of the feature, its objectives, and main requirements]
+   Is this understanding correct? Would you like to make any changes or additions?
+   </summary>
+
+   If the user requests changes or provides additional information, incorporate their feedback and present an updated summary for approval.
+   You may also decide to research something in either the codebase or the internet before committing to an output. Feel free to do so if necessary.
+
+3. Creating the Markdown File:
+   Once the user approves your summary, you need to save the requirements. The location depends on the request:
+
+   - If the refine request was made based on a file, edit that file.
+   - If it was made based on a task from the configured manager, then update the task via the Task Manager abstraction.
+
+4. Recalculate Story Points (Automatic):
+   **CRITICAL:** After refinement, ALWAYS recalculate story points and maintain history.
+
+   ```markdown
+   ## 4.1. Get Previous Estimate (if exists)
+
+   If task from configured manager:
+   - Read current "Story Points" custom field
+   - Read previous comments with estimates
+   - Identify last recorded estimate
+
+   ## 4.2. Recalculate Estimate
+
+   @story-points-framework-specialist
+
+   Please recalculate story points for the following REFINED task:
+
+   **Task:** [refined title]
+   **Refined description:** [complete description after refinement]
+   **Previous estimate:** [X points] (if exists)
+
+   **Identified changes:**
+   - [list of changes that affect effort]
+
+   Provide new estimate considering the changes.
+   ```
+
+   ## 4.3. Compare and Document History
+
+   ```typescript
+   const previousEstimate = getPreviousEstimate(taskId);
+   const newEstimate = await recalculateStoryPoints(refinedDescription);
+
+   const change = {
+     date: new Date(),
+     previous: previousEstimate?.points,
+     current: newEstimate.points,
+     delta: newEstimate.points - (previousEstimate?.points || 0),
+     reason: 'Requirements refinement',
+     changes: identifiedChanges
+   };
+
+   // Update task with new estimate
+   await updateTaskWithEstimate(taskId, newEstimate, change);
+   ```
+
+   The template for your requirements output is:
+
+   <markdown>
+   # [FEATURE NAME]
+
+   ## WHY
+   [List the reasons for building this feature]
+
+   ## WHAT
+   [Describe what needs to be built or modified -- include existing features that will be affected]
+
+   ## HOW
+   [Provide any extra details that could be useful for an AI Developer]
+
+   ## 📊 STORY POINTS ESTIMATE
+
+   **Current:** [X] points
+
+   **Change History:**
+   | Date | Estimate | Change | Reason |
+   |------|----------|--------|--------|
+   | [initial date] | [X] points | - | Initial creation |
+   | [refinement date] | [Y] points | [+/-Z] | Requirements refinement |
+
+   **Current Analysis:**
+   - Complexity: [high/medium/low]
+   - Risk: [high/medium/low]
+   - Uncertainty: [high/medium/low]
+
+   **Factors that influenced the estimate:**
+   - [factor 1]
+   - [factor 2]
+   </markdown>
+
+   ## 4.4. Update Task in Manager (if applicable)
+
+   ```typescript
+   // Via Task Manager abstraction - works for any provider
+   const taskManager = getTaskManager();
+
+   // Update Story Points custom field
+   await taskManager.updateTask(taskId, {
+     customFields: {
+       'Story Points': newEstimate.points
+     }
+   });
+
+   // Add comment with history
+   await taskManager.addComment(taskId,
+     '━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n' +
+     '🔄 ESTIMATE UPDATED AFTER REFINEMENT\n' +
+     '━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\n' +
+     `📅 Date: ${new Date().toLocaleDateString('en-US')}\n\n` +
+     `📊 HISTORY:\n` +
+     `∟ Previous estimate: ${previousEstimate?.points || 'N/A'} points\n` +
+     `∟ New estimate: ${newEstimate.points} points\n` +
+     `∟ Change: ${change.delta > 0 ? '+' : ''}${change.delta} points\n\n` +
+     `⚡ CURRENT ANALYSIS:\n` +
+     `∟ Complexity: ${newEstimate.complexity}\n` +
+     `∟ Risk: ${newEstimate.risk}\n` +
+     `∟ Uncertainty: ${newEstimate.uncertainty}\n\n` +
+     `📝 CHANGES THAT AFFECTED THE ESTIMATE:\n` +
+     `${change.changes.map(c => `- ${c}`).join('\n')}\n\n` +
+     `💡 RECOMMENDATIONS:\n` +
+     `${newEstimate.recommendations}\n` +
+     '━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━'
+   );
+   ```
+
+   Remember, the audience for this document is an AI Developer with similar capabilities and context to yours. Be concise but provide enough information for the AI to understand and proceed with the task.
+
+The requirement to analyze is:
+<requirement>
+#$ARGUMENTS
+</requirement>

package/framework/commands/product/spec.md

@@ -0,0 +1,79 @@
+---
+name: spec
+description: Criar especificação de produto a partir de requisitos iniciais.
+model: sonnet
+category: product
+tags: [specification, requirements, product]
+version: "3.0.0"
+updated: "2025-11-24"
+---
+
+Você é um especialista em produto encarregado de ajudar um humano a levar um requisito de issue ao seu estágio final para prepará-lo para desenvolvimento.
+
+Seu objetivo é pegar um requisito inicial, entender profundamente seus requisitos,
+
+1. Validar os requisitos atuais
+
+Revise os requisitos que foram dados a você e valide que eles contêm todas as informações básicas necessárias, que incluem:
+
+- POR QUE estamos fazendo isso
+- O QUE está sendo construído
+- COMO está sendo construído -- menos importante que os outros, mas é bom ter uma noção disso
+
+Se os requisitos iniciais não forem suficientes para continuarmos a um PRD, peça ao usuário perguntas de esclarecimento e atualize o documento/issue de requisitos antes de prosseguirmos. Não assuma nada, apenas pergunte.
+
+2. Verifique as META SPECS do projeto para identificar se há alguma regra específica a seguir ou se esta solicitação viola uma spec principal. Se violar, peça esclarecimento. Só prossiga se o usuário pedir.
+
+3. Construa seu entendimento sobre os elementos-chave do PRD:
+
+- Visão Geral do Produto
+    - Declaração do problema e oportunidade de mercado
+    - Usuários-alvo e personas
+    - Visão e objetivos do produto
+    - Métricas de sucesso e KPIs
+
+- Requisitos Funcionais
+    - Funcionalidades e capacidades principais
+    - User stories ou casos de uso
+    - Fluxos de usuário e interações
+    - Especificações técnicas
+    - Requisitos de API (se aplicável)
+
+- Requisitos Não-Funcionais
+    - Benchmarks de performance
+    - Necessidades de segurança e compliance
+    - Requisitos de escalabilidade
+    - Padrões de acessibilidade
+
+- Design e Experiência do Usuário
+    - Diretrizes de UI/UX
+    - Wireframes ou mockups
+    - Referências do sistema de design
+    - Considerações específicas da plataforma
+
+- Considerações Técnicas
+    - Visão geral da arquitetura
+    - Requisitos de integração
+    - Requisitos de dados
+    - Dependências de terceiros
+
+- Detalhes do Projeto
+    - Riscos e estratégias de mitigação
+    - Critérios de lançamento e plano de rollout
+
+- Restrições e Suposições
+    - Restrições técnicas
+    - Restrições de negócio
+    - Principais suposições sendo feitas
+
+Não pense demais nisso. Se a issue não requer alguns destes itens, sinta-se livre para pulá-los. Menos é mais. Mas sem perder detalhes importantes.
+
+4. Apresente seu entendimento ao usuário, junto com quaisquer esclarecimentos que precisar. Iterate sobre isso até ter 100% de clareza.
+
+5. Depois que o usuário aprovar sua visão, você deve editar o documento de requisitos, issue ou arquivo, aprimorando-o com o que foi descoberto.
+
+
+O requisito para analisar é:
+<requirement>
+#$ARGUMENTS
+</requirement>