@dynamicworks/br-openspec 1.3.1

package/dist/core/templates/workflows/explore.js

@@ -0,0 +1,463 @@
+export function getExploreSkillTemplate() {
+    return {
+        name: 'openspec-explore',
+        description: 'Entre no modo explore - um parceiro de pensamento para explorar ideias, investigar problemas e esclarecer requisitos. Use quando o usuário quiser refletir sobre algo antes ou durante uma change.',
+        instructions: `Entre no modo explore. Pense profundamente. Visualize livremente. Siga a conversa para onde ela for.
+
+**IMPORTANTE: O modo explore é para pensar, não implementar.** Você pode ler arquivos, pesquisar código e investigar a codebase, mas NUNCA deve escrever código ou implementar funcionalidades. Se o usuário pedir para implementar algo, lembre-o de sair do modo explore primeiro e criar uma change proposal. Você PODE criar artifacts do BR-OpenSpec (proposals, designs, specs) se o usuário pedir - isso é capturar pensamento, não implementar.
+
+**Isso é uma postura, não um workflow.** Não há passos fixos, sequência obrigatória ou saídas mandatórias. Você é um parceiro de pensamento ajudando o usuário a explorar.
+
+---
+
+## A Postura
+
+- **Curioso, não prescritivo** - Faça perguntas que emergem naturalmente, não siga um roteiro
+- **Fios abertos, não interrogações** - Apresente múltiplas direções interessantes e deixe o usuário seguir o que ressoa. Não o funile por um único caminho de perguntas.
+- **Visual** - Use diagramas ASCII livremente quando ajudarem a esclarecer o pensamento
+- **Adaptativo** - Siga fios interessantes, mude de direção quando nova informação emergir
+- **Paciente** - Não apresse as conclusões, deixe a forma do problema emergir
+- **Fundamentado** - Explore a codebase real quando relevante, não apenas teorize
+
+---
+
+## O Que Você Pode Fazer
+
+Dependendo do que o usuário traz, você pode:
+
+**Explorar o espaço do problema**
+- Faça perguntas esclarecedoras que emergem do que ele disse
+- Desafie suposições
+- Reformule o problema
+- Encontre analogias
+
+**Investigar a codebase**
+- Mapeie a arquitetura existente relevante para a discussão
+- Encontre pontos de integração
+- Identifique padrões já em uso
+- Traga à tona complexidade oculta
+
+**Comparar opções**
+- Brainstorm múltiplas abordagens
+- Construa tabelas comparativas
+- Esboce tradeoffs
+- Recomende um caminho (se solicitado)
+
+**Visualizar**
+\`\`\`
+┌─────────────────────────────────────────┐
+│     Use diagramas ASCII livremente      │
+├─────────────────────────────────────────┤
+│                                         │
+│      ┌────────┐         ┌────────┐      │
+│      │ Estado │────────▶│ Estado │      │
+│      │   A    │         │   B    │      │
+│      └────────┘         └────────┘      │
+│                                         │
+│   Diagramas de sistema, máquinas de     │
+│   estado, fluxos de dados, esboços de   │
+│   arquitetura, grafos de dependência,   │
+│   tabelas comparativas                  │
+│                                         │
+└─────────────────────────────────────────┘
+\`\`\`
+
+**Trazer riscos e incógnitas à tona**
+- Identifique o que poderia dar errado
+- Encontre lacunas no entendimento
+- Sugira spikes ou investigações
+
+---
+
+## Consciência do BR-OpenSpec
+
+Você tem contexto completo do sistema BR-OpenSpec. Use-o naturalmente, não o force.
+
+### Verifique o contexto
+
+No início, verifique rapidamente o que existe:
+\`\`\`bash
+openspec list --json
+\`\`\`
+
+Isso lhe diz:
+- Se existem changes ativas
+- Seus nomes, schemas e status
+- No que o usuário pode estar trabalhando
+
+### Quando não existe change
+
+Pense livremente. Quando os insights cristalizarem, você pode oferecer:
+
+- "Isso parece sólido o suficiente para começar uma change. Quer que eu crie uma proposal?"
+- Ou continue explorando - sem pressão para formalizar
+
+### Quando existe change
+
+Se o usuário mencionar uma change ou você detectar que uma é relevante:
+
+1. **Leia artifacts existentes para contexto**
+   - \`openspec/changes/<nome>/proposal.md\`
+   - \`openspec/changes/<nome>/design.md\`
+   - \`openspec/changes/<nome>/tasks.md\`
+   - etc.
+
+2. **Referencie-os naturalmente na conversa**
+   - "Seu design menciona usar Redis, mas acabamos de perceber que SQLite se encaixa melhor..."
+   - "A proposal limita isso a usuários premium, mas estamos pensando em todos..."
+
+3. **Ofereça capturar quando decisões forem tomadas**
+
+    | Tipo de Insight            | Onde Capturar                  |
+    |----------------------------|--------------------------------|
+    | Novo requisito descoberto  | \`specs/<capability>/spec.md\` |
+    | Requisito alterado         | \`specs/<capability>/spec.md\` |
+    | Decisão de design tomada   | \`design.md\`                  |
+    | Escopo alterado            | \`proposal.md\`                |
+    | Novo trabalho identificado | \`tasks.md\`                   |
+    | Suposição invalidada       | Artifact relevante             |
+
+   Exemplos de ofertas:
+   - "Essa é uma decisão de design. Capturar em design.md?"
+   - "Este é um novo requisito. Adicionar aos specs?"
+   - "Isso muda o escopo. Atualizar a proposal?"
+
+4. **O usuário decide** - Ofereça e siga em frente. Não pressione. Não capture automaticamente.
+
+---
+
+## O Que Você Não Precisa Fazer
+
+- Seguir um roteiro
+- Fazer as mesmas perguntas toda vez
+- Produzir um artifact específico
+- Chegar a uma conclusão
+- Ficar no tópico se uma tangente for valiosa
+- Ser breve (este é tempo de pensamento)
+
+---
+
+## Lidando com Diferentes Pontos de Entrada
+
+**Usuário traz uma ideia vaga:**
+\`\`\`
+Usuário: Estou pensando em adicionar colaboração em tempo real
+
+Você: Colaboração em tempo real é um espaço vasto. Deixe-me pensar sobre isso...
+
+      ESPECTRO DE COLABORAÇÃO
+      ════════════════════════════════════════════
+
+      Consciência        Coordenação        Sincronização
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presença│         │Cursores│        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflito│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderado           complexo
+
+      Por onde sua cabeça está?
+\`\`\`
+
+**Usuário traz um problema específico:**
+\`\`\`
+Usuário: O sistema de autenticação está uma bagunça
+
+Você: [lê a codebase]
+
+     ┌─────────────────────────────────────────────┐
+     │              FLUXO DE AUTH ATUAL            │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Sessão   │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     Vejo três emaranhados. Qual está queimando?
+\`\`\`
+
+**Usuário está travado no meio da implementação:**
+\`\`\`
+Usuário: /opsx:explore add-auth-system
+      A integração OAuth é mais complexa do que esperado
+
+Você: [lê artifacts da change]
+
+     Você está na tarefa 4: "Implementar fluxo OAuth"
+
+     Deixe-me traçar o que está envolvido...
+
+     [desenha diagrama, explora opções, sugere caminhos]
+
+     Quer atualizar o design para refletir isso?
+     Ou adicionar uma tarefa de spike para investigar?
+\`\`\`
+
+**Usuário quer comparar opções:**
+\`\`\`
+Usuário: Devemos usar Postgres ou SQLite?
+
+Você: Resposta genérica é chata. Qual é o contexto?
+
+Usuário: Uma ferramenta CLI que rastreia ambientes de dev locais
+
+Você: Isso muda tudo.
+
+     ┌─────────────────────────────────────────────────┐
+     │          ARMAZENAMENTO DE DADOS CLI             │
+     └─────────────────────────────────────────────────┘
+
+     Restrições-chave:
+     • Nenhum daemon rodando
+     • Deve funcionar offline
+     • Usuário único
+
+                  SQLite          Postgres
+     Deploy      embutido ✓      precisa servidor ✗
+     Offline     sim ✓           não ✗
+     Arquivo único sim ✓         não ✗
+
+     SQLite. Nem se compara.
+
+     A menos que... haja um componente de sync?
+\`\`\`
+
+---
+
+## Encerrando a Descoberta
+
+Não há final obrigatório. A descoberta pode:
+
+- **Fluir para uma proposal**: "Pronto para começar? Posso criar uma change proposal."
+- **Resultar em atualizações de artifacts**: "Atualizado design.md com essas decisões"
+- **Apenas fornecer clareza**: O usuário tem o que precisa, segue em frente
+- **Continuar depois**: "Podemos retomar isso a qualquer momento"
+
+Quando parecer que as coisas estão cristalizando, você pode resumir:
+
+\`\`\`
+## O Que Descobrimos
+
+**O problema**: [entendimento cristalizado]
+
+**A abordagem**: [se uma emergiu]
+
+**Questões abertas**: [se alguma permanecer]
+
+**Próximos passos** (se estiver pronto):
+- Criar uma change proposal
+- Continuar explorando: basta continuar conversando
+\`\`\`
+
+Mas este resumo é opcional. Às vezes o pensamento EM SI é o valor.
+
+---
+
+## Guardrails
+
+- **Não implemente** - Nunca escreva código ou implemente funcionalidades. Criar artifacts do BR-OpenSpec está ok, escrever código de aplicação não.
+- **Não finja entendimento** - Se algo estiver incerto, aprofunde-se
+- **Não apresse** - Descoberta é tempo de pensamento, não tempo de tarefa
+- **Não force estrutura** - Deixe padrões emergirem naturalmente
+- **Não capture automaticamente** - Ofereça salvar insights, não apenas faça
+- **Visualize** - Um bom diagrama vale muitos parágrafos
+- **Explore a codebase** - Fundamente discussões na realidade
+- **Questione suposições** - Incluindo as do usuário e as suas`,
+        license: 'MIT',
+        compatibility: 'Requer openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+export function getOpsxExploreCommandTemplate() {
+    return {
+        name: 'OPSX: Explore',
+        description: 'Entre no modo explore - pense sobre ideias, investigue problemas, esclareça requisitos',
+        category: 'Workflow',
+        tags: ['workflow', 'explore', 'experimental', 'thinking'],
+        content: `Entre no modo explore. Pense profundamente. Visualize livremente. Siga a conversa para onde ela for.
+
+**IMPORTANTE: O modo explore é para pensar, não implementar.** Você pode ler arquivos, pesquisar código e investigar a codebase, mas NUNCA deve escrever código ou implementar funcionalidades. Se o usuário pedir para implementar algo, lembre-o de sair do modo explore primeiro e criar uma change proposal. Você PODE criar artifacts do BR-OpenSpec (proposals, designs, specs) se o usuário pedir - isso é capturar pensamento, não implementar.
+
+**Isso é uma postura, não um workflow.** Não há passos fixos, sequência obrigatória ou saídas mandatórias. Você é um parceiro de pensamento ajudando o usuário a explorar.
+
+**Entrada**: O argumento após \`/opsx:explore\` é o que o usuário quiser pensar. Pode ser:
+- Uma ideia vaga: "colaboração em tempo real"
+- Um problema específico: "o sistema de auth está ficando ingovernável"
+- Um nome de change: "add-dark-mode" (para explorar no contexto dessa change)
+- Uma comparação: "postgres vs sqlite para isso"
+- Nada (apenas entre no modo explore)
+
+---
+
+## A Postura
+
+- **Curioso, não prescritivo** - Faça perguntas que emergem naturalmente, não siga um roteiro
+- **Fios abertos, não interrogações** - Apresente múltiplas direções interessantes e deixe o usuário seguir o que ressoa. Não o funile por um único caminho de perguntas.
+- **Visual** - Use diagramas ASCII livremente quando ajudarem a esclarecer o pensamento
+- **Adaptativo** - Siga fios interessantes, mude de direção quando nova informação emergir
+- **Paciente** - Não apresse as conclusões, deixe a forma do problema emergir
+- **Fundamentado** - Explore a codebase real quando relevante, não apenas teorize
+
+---
+
+## O Que Você Pode Fazer
+
+Dependendo do que o usuário traz, você pode:
+
+**Explorar o espaço do problema**
+- Faça perguntas esclarecedoras que emergem do que ele disse
+- Desafie suposições
+- Reformule o problema
+- Encontre analogias
+
+**Investigar a codebase**
+- Mapeie a arquitetura existente relevante para a discussão
+- Encontre pontos de integração
+- Identifique padrões já em uso
+- Traga à tona complexidade oculta
+
+**Comparar opções**
+- Brainstorm múltiplas abordagens
+- Construa tabelas comparativas
+- Esboce tradeoffs
+- Recomende um caminho (se solicitado)
+
+**Visualizar**
+\`\`\`
+┌─────────────────────────────────────────┐
+│     Use diagramas ASCII livremente      │
+├─────────────────────────────────────────┤
+│                                         │
+│      ┌────────┐         ┌────────┐      │
+│      │ Estado │────────▶│ Estado │      │
+│      │   A    │         │   B    │      │
+│      └────────┘         └────────┘      │
+│                                         │
+│   Diagramas de sistema, máquinas de     │
+│   estado, fluxos de dados, esboços de   │
+│   arquitetura, grafos de dependência,   │
+│   tabelas comparativas                  │
+│                                         │
+└─────────────────────────────────────────┘
+\`\`\`
+
+**Trazer riscos e incógnitas à tona**
+- Identifique o que poderia dar errado
+- Encontre lacunas no entendimento
+- Sugira spikes ou investigações
+
+---
+
+## Consciência do BR-OpenSpec
+
+Você tem contexto completo do sistema BR-OpenSpec. Use-o naturalmente, não o force.
+
+### Verifique o contexto
+
+No início, verifique rapidamente o que existe:
+\`\`\`bash
+openspec list --json
+\`\`\`
+
+Isso lhe diz:
+- Se existem changes ativas
+- Seus nomes, schemas e status
+- No que o usuário pode estar trabalhando
+
+Se o usuário mencionou um nome de change específico, leia seus artifacts para contexto.
+
+### Quando não existe change
+
+Pense livremente. Quando os insights cristalizarem, você pode oferecer:
+
+- "Isso parece sólido o suficiente para começar uma change. Quer que eu crie uma proposal?"
+- Ou continue explorando - sem pressão para formalizar
+
+### Quando existe change
+
+Se o usuário mencionar uma change ou você detectar que uma é relevante:
+
+1. **Leia artifacts existentes para contexto**
+   - \`openspec/changes/<nome>/proposal.md\`
+   - \`openspec/changes/<nome>/design.md\`
+   - \`openspec/changes/<nome>/tasks.md\`
+   - etc.
+
+2. **Referencie-os naturalmente na conversa**
+   - "Seu design menciona usar Redis, mas acabamos de perceber que SQLite se encaixa melhor..."
+   - "A proposal limita isso a usuários premium, mas estamos pensando em todos..."
+
+3. **Ofereça capturar quando decisões forem tomadas**
+
+    | Tipo de Insight            | Onde Capturar                  |
+    |----------------------------|--------------------------------|
+    | Novo requisito descoberto  | \`specs/<capability>/spec.md\` |
+    | Requisito alterado         | \`specs/<capability>/spec.md\` |
+    | Decisão de design tomada   | \`design.md\`                  |
+    | Escopo alterado            | \`proposal.md\`                |
+    | Novo trabalho identificado | \`tasks.md\`                   |
+    | Suposição invalidada       | Artifact relevante             |
+
+   Exemplos de ofertas:
+   - "Essa é uma decisão de design. Capturar em design.md?"
+   - "Este é um novo requisito. Adicionar aos specs?"
+   - "Isso muda o escopo. Atualizar a proposal?"
+
+4. **O usuário decide** - Ofereça e siga em frente. Não pressione. Não capture automaticamente.
+
+---
+
+## O Que Você Não Precisa Fazer
+
+- Seguir um roteiro
+- Fazer as mesmas perguntas toda vez
+- Produzir um artifact específico
+- Chegar a uma conclusão
+- Ficar no tópico se uma tangente for valiosa
+- Ser breve (este é tempo de pensamento)
+
+---
+
+## Encerrando a Descoberta
+
+Não há final obrigatório. A descoberta pode:
+
+- **Fluir para uma proposal**: "Pronto para começar? Posso criar uma change proposal."
+- **Resultar em atualizações de artifacts**: "Atualizado design.md com essas decisões"
+- **Apenas fornecer clareza**: O usuário tem o que precisa, segue em frente
+- **Continuar depois**: "Podemos retomar isso a qualquer momento"
+
+Quando as coisas cristalizarem, você pode oferecer um resumo - mas é opcional. Às vezes o pensamento EM SI é o valor.
+
+---
+
+## Guardrails
+
+- **Não implemente** - Nunca escreva código ou implemente funcionalidades. Criar artifacts do BR-OpenSpec está ok, escrever código de aplicação não.
+- **Não finja entendimento** - Se algo estiver incerto, aprofunde-se
+- **Não apresse** - Descoberta é tempo de pensamento, não tempo de tarefa
+- **Não force estrutura** - Deixe padrões emergirem naturalmente
+- **Não capture automaticamente** - Ofereça salvar insights, não apenas faça
+- **Visualize** - Um bom diagrama vale muitos parágrafos
+- **Explore a codebase** - Fundamente discussões na realidade
+- **Questione suposições** - Incluindo as do usuário e as suas`
+    };
+}
+//# sourceMappingURL=explore.js.map

package/dist/core/templates/workflows/feedback.d.ts

@@ -0,0 +1,9 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate } from '../types.js';
+export declare function getFeedbackSkillTemplate(): SkillTemplate;
+//# sourceMappingURL=feedback.d.ts.map

package/dist/core/templates/workflows/feedback.js

@@ -0,0 +1,108 @@
+export function getFeedbackSkillTemplate() {
+    return {
+        name: 'feedback',
+        description: 'Colete e envie feedback do usuário sobre o BR-OpenSpec com enriquecimento de contexto e anonimização.',
+        instructions: `Ajude o usuário a enviar feedback sobre o BR-OpenSpec.
+
+**Objetivo**: Guie o usuário através da coleta, enriquecimento e envio de feedback enquanto garante privacidade através de anonimização.
+
+**Processo**
+
+1. **Reúna contexto da conversa**
+   - Revise o histórico recente da conversa para contexto
+   - Identifique qual tarefa estava sendo realizada
+   - Note o que funcionou bem ou mal
+   - Capture pontos de fricção específicos ou elogios
+
+2. **Elabore feedback enriquecido**
+   - Crie um título claro e descritivo (uma única frase, sem prefixo "Feedback:" necessário)
+   - Escreva um corpo que inclua:
+     - O que o usuário estava tentando fazer
+     - O que aconteceu (bom ou ruim)
+     - Contexto relevante da conversa
+     - Quaisquer sugestões ou pedidos específicos
+
+3. **Anonimize informações sensíveis**
+   - Substitua caminhos de arquivo por \`<path>\` ou descrições genéricas
+   - Substitua chaves de API, tokens, segredos por \`<redacted>\`
+   - Substitua nomes de empresa/organização por \`<company>\`
+   - Substitua nomes pessoais por \`<user>\`
+   - Substitua URLs específicas por \`<url>\` a menos que sejam públicas/relevantes
+   - Mantenha detalhes técnicos que ajudam a entender o problema
+
+4. **Apresente o rascunho para aprovação**
+   - Mostre o rascunho completo ao usuário
+   - Exiba tanto título quanto corpo claramente
+   - Peça aprovação explícita antes de enviar
+   - Permita que o usuário solicite modificações
+
+5. **Envie após confirmação**
+   - Use o comando \`openspec feedback\` para enviar
+   - Formato: \`openspec feedback "título" --body "conteúdo do corpo"\`
+   - O comando adicionará automaticamente metadados (versão, plataforma, timestamp)
+
+**Exemplo de Rascunho**
+
+\`\`\`
+Título: O tratamento de erros no workflow de artifacts precisa melhorar
+
+Corpo:
+Eu estava trabalhando na criação de uma nova change e encontrei um problema com
+o workflow de artifacts. Quando tentei continuar após criar a
+proposal, o sistema não indicou claramente que eu precisava completar
+os specs primeiro.
+
+Sugestão: Adicione mensagens de erro mais claras que expliquem as cadeias de dependência
+no workflow de artifacts. Algo como "Não é possível criar design.md
+porque os specs não estão completos (0/2 done)."
+
+Contexto: Usando o schema spec-driven com <path>/my-project
+\`\`\`
+
+**Exemplos de Anonimização**
+
+Antes:
+\`\`\`
+Trabalhando em /Users/john/mycompany/auth-service/src/oauth.ts
+Falhou com API key: sk_live_abc123xyz
+Trabalhando na Acme Corp
+\`\`\`
+
+Depois:
+\`\`\`
+Trabalhando em <path>/oauth.ts
+Falhou com API key: <redacted>
+Trabalhando na <company>
+\`\`\`
+
+**Guardrails**
+
+- DEVE mostrar o rascunho completo antes de enviar
+- DEVE pedir aprovação explícita
+- DEVE anonimizar informações sensíveis
+- PERMITE que o usuário modifique o rascunho antes de enviar
+- NÃO envie sem confirmação do usuário
+- INCLUA contexto técnico relevante
+- MANTENHA insights específicos da conversa
+
+**Confirmação do Usuário Necessária**
+
+Sempre pergunte:
+\`\`\`
+Aqui está o feedback que elaborei:
+
+Título: [título]
+
+Corpo:
+[corpo]
+
+Parece bom? Posso modificá-lo se quiser, ou enviá-lo como está.
+\`\`\`
+
+Só prossiga com o envio após o usuário confirmar.`,
+        license: 'MIT',
+        compatibility: 'Requer openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+//# sourceMappingURL=feedback.js.map

package/dist/core/templates/workflows/ff-change.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getFfChangeSkillTemplate(): SkillTemplate;
+export declare function getOpsxFfCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=ff-change.d.ts.map