@dynamicworks/br-openspec 1.3.1 → 2.0.1

package/dist/core/templates/workflows/continue-change.js

@@ -2,112 +2,112 @@ export function getContinueChangeSkillTemplate() {
     return {
         name: 'openspec-continue-change',
         description: 'Continue trabalhando em uma change do BR-OpenSpec criando o próximo artifact. Use quando o usuário quiser progredir sua change, criar o próximo artifact ou continuar seu workflow.',
-        instructions: `Continue trabalhando em uma change criando o próximo artifact.
-
-**Entrada**: Opcionalmente especifique um nome de change. Se omitido, verifique se pode ser inferido do contexto da conversa. Se vago ou ambíguo, você DEVE solicitar as changes disponíveis.
-
-**Passos**
-
-1. **Se nenhum nome de change for fornecido, solicite a seleção**
-
-   Execute \`openspec list --json\` para obter as changes disponíveis ordenadas pela mais recentemente modificada. Depois use a ferramenta **AskUserQuestion** para permitir que o usuário selecione em qual change trabalhar.
-
-   Apresente as 3-4 changes mais recentemente modificadas como opções, mostrando:
-   - Nome da change
-   - Schema (do campo \`schema\` se presente, caso contrário "spec-driven")
-   - Status (por exemplo, "0/5 tasks", "completo", "sem tarefas")
-   - Quão recentemente foi modificada (do campo \`lastModified\`)
-
-   Marque a change mais recentemente modificada como "(Recomendada)" já que é provavelmente o que o usuário quer continuar.
-
-   **IMPORTANTE**: NÃO adivinhe ou selecione automaticamente uma change. Sempre deixe o usuário escolher.
-
-2. **Verifique o status atual**
-   \`\`\`bash
-   openspec status --change "<nome>" --json
-   \`\`\`
-   Analise o JSON para entender o estado atual. A resposta inclui:
-   - \`schemaName\`: O schema de workflow sendo usado (por exemplo, "spec-driven")
-   - \`artifacts\`: Array de artifacts com seu status ("done", "ready", "blocked")
-   - \`isComplete\`: Booleano indicando se todos os artifacts estão completos
-
-3. **Aja com base no status**:
-
-   ---
-
-   **Se todos os artifacts estão completos (\`isComplete: true\`)**:
-   - Parabenize o usuário
-   - Mostre o status final incluindo o schema usado
-   - Sugira: "Todos os artifacts criados! Agora você pode implementar esta change ou arquivá-la."
-   - PARE
-
-   ---
-
-   **Se os artifacts estão prontos para criar** (status mostra artifacts com \`status: "ready"\`):
-   - Escolha o PRIMEIRO artifact com \`status: "ready"\` da saída do status
-   - Obtenha suas instruções:
-     \`\`\`bash
-     openspec instructions <artifact-id> --change "<nome>" --json
-     \`\`\`
-   - Analise o JSON. Os campos-chave são:
-     - \`context\`: Contexto do projeto (restrições para você - NÃO inclua na saída)
-     - \`rules\`: Regras específicas do artifact (restrições para você - NÃO inclua na saída)
-     - \`template\`: A estrutura a ser usada para seu arquivo de saída
-     - \`instruction\`: Orientação específica do schema
-     - \`outputPath\`: Onde escrever o artifact
-     - \`dependencies\`: Artifacts concluídos para ler como contexto
-   - **Crie o arquivo do artifact**:
-     - Leia quaisquer arquivos de dependências concluídos para contexto
-     - Use \`template\` como a estrutura - preencha suas seções
-     - Aplique \`context\` e \`rules\` como restrições ao escrever - mas NÃO copie-os para o arquivo
-     - Escreva no caminho de saída especificado nas instruções
-   - Mostre o que foi criado e o que agora está desbloqueado
-   - PARE após criar UM artifact
-
-   ---
-
-   **Se nenhum artifact estiver pronto (todos bloqueados)**:
-   - Isso não deveria acontecer com um schema válido
-   - Mostre o status e sugira verificar problemas
-
-4. **Após criar um artifact, mostre o progresso**
-   \`\`\`bash
-   openspec status --change "<nome>"
-   \`\`\`
-
-**Saída**
-
-Após cada invocação, mostre:
-- Qual artifact foi criado
-- Schema de workflow sendo usado
-- Progresso atual (N/M completos)
-- Quais artifacts agora estão desbloqueados
-- Prompt: "Quer continuar? Basta me pedir para continuar ou me dizer o que fazer em seguida."
-
-**Diretrizes de Criação de Artifacts**
-
-Os tipos de artifact e sua finalidade dependem do schema. Use o campo \`instruction\` da saída das instruções para entender o que criar.
-
-Padrões comuns de artifacts:
-
-**Schema spec-driven** (proposal → specs → design → tasks):
-- **proposal.md**: Pergunte ao usuário sobre a change se não estiver claro. Preencha Por Que, O Que Muda, Capabilities, Impacto.
-  - A seção Capabilities é crítica - cada capability listada precisará de um arquivo spec.
-- **specs/<capability>/spec.md**: Crie um spec por capability listada na seção Capabilities do proposal (use o nome da capability, não o nome da change).
-- **design.md**: Documente decisões técnicas, arquitetura e abordagem de implementação.
-- **tasks.md**: Divida a implementação em tarefas com checkbox.
-
-Para outros schemas, siga o campo \`instruction\` da saída do CLI.
-
-**Guardrails**
-- Crie UM artifact por invocação
-- Sempre leia artifacts de dependência antes de criar um novo
-- Nunca pule artifacts ou crie fora de ordem
-- Se o contexto estiver incerto, pergunte ao usuário antes de criar
-- Verifique se o arquivo do artifact existe após escrever antes de marcar progresso
-- Use a sequência de artifacts do schema, não assuma nomes específicos de artifacts
-- **IMPORTANTE**: \`context\` e \`rules\` são restrições para VOCÊ, não conteúdo para o arquivo
-  - NÃO copie blocos \`<context>\`, \`<rules>\`, \`<project_context>\` para o artifact
+        instructions: `Continue trabalhando em uma change criando o próximo artifact.
+
+**Entrada**: Opcionalmente especifique um nome de change. Se omitido, verifique se pode ser inferido do contexto da conversa. Se vago ou ambíguo, você DEVE solicitar as changes disponíveis.
+
+**Passos**
+
+1. **Se nenhum nome de change for fornecido, solicite a seleção**
+
+   Execute \`openspec list --json\` para obter as changes disponíveis ordenadas pela mais recentemente modificada. Depois use a ferramenta **AskUserQuestion** para permitir que o usuário selecione em qual change trabalhar.
+
+   Apresente as 3-4 changes mais recentemente modificadas como opções, mostrando:
+   - Nome da change
+   - Schema (do campo \`schema\` se presente, caso contrário "spec-driven")
+   - Status (por exemplo, "0/5 tasks", "completo", "sem tarefas")
+   - Quão recentemente foi modificada (do campo \`lastModified\`)
+
+   Marque a change mais recentemente modificada como "(Recomendada)" já que é provavelmente o que o usuário quer continuar.
+
+   **IMPORTANTE**: NÃO adivinhe ou selecione automaticamente uma change. Sempre deixe o usuário escolher.
+
+2. **Verifique o status atual**
+   \`\`\`bash
+   openspec status --change "<nome>" --json
+   \`\`\`
+   Analise o JSON para entender o estado atual. A resposta inclui:
+   - \`schemaName\`: O schema de workflow sendo usado (por exemplo, "spec-driven")
+   - \`artifacts\`: Array de artifacts com seu status ("done", "ready", "blocked")
+   - \`isComplete\`: Booleano indicando se todos os artifacts estão completos
+
+3. **Aja com base no status**:
+
+   ---
+
+   **Se todos os artifacts estão completos (\`isComplete: true\`)**:
+   - Parabenize o usuário
+   - Mostre o status final incluindo o schema usado
+   - Sugira: "Todos os artifacts criados! Agora você pode implementar esta change ou arquivá-la."
+   - PARE
+
+   ---
+
+   **Se os artifacts estão prontos para criar** (status mostra artifacts com \`status: "ready"\`):
+   - Escolha o PRIMEIRO artifact com \`status: "ready"\` da saída do status
+   - Obtenha suas instruções:
+     \`\`\`bash
+     openspec instructions <artifact-id> --change "<nome>" --json
+     \`\`\`
+   - Analise o JSON. Os campos-chave são:
+     - \`context\`: Contexto do projeto (restrições para você - NÃO inclua na saída)
+     - \`rules\`: Regras específicas do artifact (restrições para você - NÃO inclua na saída)
+     - \`template\`: A estrutura a ser usada para seu arquivo de saída
+     - \`instruction\`: Orientação específica do schema
+     - \`outputPath\`: Onde escrever o artifact
+     - \`dependencies\`: Artifacts concluídos para ler como contexto
+   - **Crie o arquivo do artifact**:
+     - Leia quaisquer arquivos de dependências concluídos para contexto
+     - Use \`template\` como a estrutura - preencha suas seções
+     - Aplique \`context\` e \`rules\` como restrições ao escrever - mas NÃO copie-os para o arquivo
+     - Escreva no caminho de saída especificado nas instruções
+   - Mostre o que foi criado e o que agora está desbloqueado
+   - PARE após criar UM artifact
+
+   ---
+
+   **Se nenhum artifact estiver pronto (todos bloqueados)**:
+   - Isso não deveria acontecer com um schema válido
+   - Mostre o status e sugira verificar problemas
+
+4. **Após criar um artifact, mostre o progresso**
+   \`\`\`bash
+   openspec status --change "<nome>"
+   \`\`\`
+
+**Saída**
+
+Após cada invocação, mostre:
+- Qual artifact foi criado
+- Schema de workflow sendo usado
+- Progresso atual (N/M completos)
+- Quais artifacts agora estão desbloqueados
+- Prompt: "Quer continuar? Basta me pedir para continuar ou me dizer o que fazer em seguida."
+
+**Diretrizes de Criação de Artifacts**
+
+Os tipos de artifact e sua finalidade dependem do schema. Use o campo \`instruction\` da saída das instruções para entender o que criar.
+
+Padrões comuns de artifacts:
+
+**Schema spec-driven** (proposal → specs → design → tasks):
+- **proposal.md**: Pergunte ao usuário sobre a change se não estiver claro. Preencha Por Que, O Que Muda, Capabilities, Impacto.
+  - A seção Capabilities é crítica - cada capability listada precisará de um arquivo spec.
+- **specs/<capability>/spec.md**: Crie um spec por capability listada na seção Capabilities do proposal (use o nome da capability, não o nome da change).
+- **design.md**: Documente decisões técnicas, arquitetura e abordagem de implementação.
+- **tasks.md**: Divida a implementação em tarefas com checkbox.
+
+Para outros schemas, siga o campo \`instruction\` da saída do CLI.
+
+**Guardrails**
+- Crie UM artifact por invocação
+- Sempre leia artifacts de dependência antes de criar um novo
+- Nunca pule artifacts ou crie fora de ordem
+- Se o contexto estiver incerto, pergunte ao usuário antes de criar
+- Verifique se o arquivo do artifact existe após escrever antes de marcar progresso
+- Use a sequência de artifacts do schema, não assuma nomes específicos de artifacts
+- **IMPORTANTE**: \`context\` e \`rules\` são restrições para VOCÊ, não conteúdo para o arquivo
+  - NÃO copie blocos \`<context>\`, \`<rules>\`, \`<project_context>\` para o artifact
   - Eles guiam o que você escreve, mas nunca devem aparecer na saída`,
         license: 'MIT',
         compatibility: 'Requer openspec CLI.',
@@ -120,112 +120,112 @@ export function getOpsxContinueCommandTemplate() {
         description: 'Continue trabalhando em uma change - crie o próximo artifact (Experimental)',
         category: 'Workflow',
         tags: ['workflow', 'artifacts', 'experimental'],
-        content: `Continue trabalhando em uma change criando o próximo artifact.
-
-**Entrada**: Opcionalmente especifique um nome de change após \`/opsx:continue\` (por exemplo, \`/opsx:continue add-auth\`). Se omitido, verifique se pode ser inferido do contexto da conversa. Se vago ou ambíguo, você DEVE solicitar as changes disponíveis.
-
-**Passos**
-
-1. **Se nenhum nome de change for fornecido, solicite a seleção**
-
-   Execute \`openspec list --json\` para obter as changes disponíveis ordenadas pela mais recentemente modificada. Depois use a ferramenta **AskUserQuestion** para permitir que o usuário selecione em qual change trabalhar.
-
-   Apresente as 3-4 changes mais recentemente modificadas como opções, mostrando:
-   - Nome da change
-   - Schema (do campo \`schema\` se presente, caso contrário "spec-driven")
-   - Status (por exemplo, "0/5 tasks", "completo", "sem tarefas")
-   - Quão recentemente foi modificada (do campo \`lastModified\`)
-
-   Marque a change mais recentemente modificada como "(Recomendada)" já que é provavelmente o que o usuário quer continuar.
-
-   **IMPORTANTE**: NÃO adivinhe ou selecione automaticamente uma change. Sempre deixe o usuário escolher.
-
-2. **Verifique o status atual**
-   \`\`\`bash
-   openspec status --change "<nome>" --json
-   \`\`\`
-   Analise o JSON para entender o estado atual. A resposta inclui:
-   - \`schemaName\`: O schema de workflow sendo usado (por exemplo, "spec-driven")
-   - \`artifacts\`: Array de artifacts com seu status ("done", "ready", "blocked")
-   - \`isComplete\`: Booleano indicando se todos os artifacts estão completos
-
-3. **Aja com base no status**:
-
-   ---
-
-   **Se todos os artifacts estão completos (\`isComplete: true\`)**:
-   - Parabenize o usuário
-   - Mostre o status final incluindo o schema usado
-   - Sugira: "Todos os artifacts criados! Agora você pode implementar esta change com \`/opsx:apply\` ou arquivá-la com \`/opsx:archive\`."
-   - PARE
-
-   ---
-
-   **Se os artifacts estão prontos para criar** (status mostra artifacts com \`status: "ready"\`):
-   - Escolha o PRIMEIRO artifact com \`status: "ready"\` da saída do status
-   - Obtenha suas instruções:
-     \`\`\`bash
-     openspec instructions <artifact-id> --change "<nome>" --json
-     \`\`\`
-   - Analise o JSON. Os campos-chave são:
-     - \`context\`: Contexto do projeto (restrições para você - NÃO inclua na saída)
-     - \`rules\`: Regras específicas do artifact (restrições para você - NÃO inclua na saída)
-     - \`template\`: A estrutura a ser usada para seu arquivo de saída
-     - \`instruction\`: Orientação específica do schema
-     - \`outputPath\`: Onde escrever o artifact
-     - \`dependencies\`: Artifacts concluídos para ler como contexto
-   - **Crie o arquivo do artifact**:
-     - Leia quaisquer arquivos de dependências concluídos para contexto
-     - Use \`template\` como a estrutura - preencha suas seções
-     - Aplique \`context\` e \`rules\` como restrições ao escrever - mas NÃO copie-os para o arquivo
-     - Escreva no caminho de saída especificado nas instruções
-   - Mostre o que foi criado e o que agora está desbloqueado
-   - PARE após criar UM artifact
-
-   ---
-
-   **Se nenhum artifact estiver pronto (todos bloqueados)**:
-   - Isso não deveria acontecer com um schema válido
-   - Mostre o status e sugira verificar problemas
-
-4. **Após criar um artifact, mostre o progresso**
-   \`\`\`bash
-   openspec status --change "<nome>"
-   \`\`\`
-
-**Saída**
-
-Após cada invocação, mostre:
-- Qual artifact foi criado
-- Schema de workflow sendo usado
-- Progresso atual (N/M completos)
-- Quais artifacts agora estão desbloqueados
-- Prompt: "Execute \`/opsx:continue\` para criar o próximo artifact"
-
-**Diretrizes de Criação de Artifacts**
-
-Os tipos de artifact e sua finalidade dependem do schema. Use o campo \`instruction\` da saída das instruções para entender o que criar.
-
-Padrões comuns de artifacts:
-
-**Schema spec-driven** (proposal → specs → design → tasks):
-- **proposal.md**: Pergunte ao usuário sobre a change se não estiver claro. Preencha Por Que, O Que Muda, Capabilities, Impacto.
-  - A seção Capabilities é crítica - cada capability listada precisará de um arquivo spec.
-- **specs/<capability>/spec.md**: Crie um spec por capability listada na seção Capabilities do proposal (use o nome da capability, não o nome da change).
-- **design.md**: Documente decisões técnicas, arquitetura e abordagem de implementação.
-- **tasks.md**: Divida a implementação em tarefas com checkbox.
-
-Para outros schemas, siga o campo \`instruction\` da saída do CLI.
-
-**Guardrails**
-- Crie UM artifact por invocação
-- Sempre leia artifacts de dependência antes de criar um novo
-- Nunca pule artifacts ou crie fora de ordem
-- Se o contexto estiver incerto, pergunte ao usuário antes de criar
-- Verifique se o arquivo do artifact existe após escrever antes de marcar progresso
-- Use a sequência de artifacts do schema, não assuma nomes específicos de artifacts
-- **IMPORTANTE**: \`context\` e \`rules\` são restrições para VOCÊ, não conteúdo para o arquivo
-  - NÃO copie blocos \`<context>\`, \`<rules>\`, \`<project_context>\` para o artifact
+        content: `Continue trabalhando em uma change criando o próximo artifact.
+
+**Entrada**: Opcionalmente especifique um nome de change após \`/opsx:continue\` (por exemplo, \`/opsx:continue add-auth\`). Se omitido, verifique se pode ser inferido do contexto da conversa. Se vago ou ambíguo, você DEVE solicitar as changes disponíveis.
+
+**Passos**
+
+1. **Se nenhum nome de change for fornecido, solicite a seleção**
+
+   Execute \`openspec list --json\` para obter as changes disponíveis ordenadas pela mais recentemente modificada. Depois use a ferramenta **AskUserQuestion** para permitir que o usuário selecione em qual change trabalhar.
+
+   Apresente as 3-4 changes mais recentemente modificadas como opções, mostrando:
+   - Nome da change
+   - Schema (do campo \`schema\` se presente, caso contrário "spec-driven")
+   - Status (por exemplo, "0/5 tasks", "completo", "sem tarefas")
+   - Quão recentemente foi modificada (do campo \`lastModified\`)
+
+   Marque a change mais recentemente modificada como "(Recomendada)" já que é provavelmente o que o usuário quer continuar.
+
+   **IMPORTANTE**: NÃO adivinhe ou selecione automaticamente uma change. Sempre deixe o usuário escolher.
+
+2. **Verifique o status atual**
+   \`\`\`bash
+   openspec status --change "<nome>" --json
+   \`\`\`
+   Analise o JSON para entender o estado atual. A resposta inclui:
+   - \`schemaName\`: O schema de workflow sendo usado (por exemplo, "spec-driven")
+   - \`artifacts\`: Array de artifacts com seu status ("done", "ready", "blocked")
+   - \`isComplete\`: Booleano indicando se todos os artifacts estão completos
+
+3. **Aja com base no status**:
+
+   ---
+
+   **Se todos os artifacts estão completos (\`isComplete: true\`)**:
+   - Parabenize o usuário
+   - Mostre o status final incluindo o schema usado
+   - Sugira: "Todos os artifacts criados! Agora você pode implementar esta change com \`/opsx:apply\` ou arquivá-la com \`/opsx:archive\`."
+   - PARE
+
+   ---
+
+   **Se os artifacts estão prontos para criar** (status mostra artifacts com \`status: "ready"\`):
+   - Escolha o PRIMEIRO artifact com \`status: "ready"\` da saída do status
+   - Obtenha suas instruções:
+     \`\`\`bash
+     openspec instructions <artifact-id> --change "<nome>" --json
+     \`\`\`
+   - Analise o JSON. Os campos-chave são:
+     - \`context\`: Contexto do projeto (restrições para você - NÃO inclua na saída)
+     - \`rules\`: Regras específicas do artifact (restrições para você - NÃO inclua na saída)
+     - \`template\`: A estrutura a ser usada para seu arquivo de saída
+     - \`instruction\`: Orientação específica do schema
+     - \`outputPath\`: Onde escrever o artifact
+     - \`dependencies\`: Artifacts concluídos para ler como contexto
+   - **Crie o arquivo do artifact**:
+     - Leia quaisquer arquivos de dependências concluídos para contexto
+     - Use \`template\` como a estrutura - preencha suas seções
+     - Aplique \`context\` e \`rules\` como restrições ao escrever - mas NÃO copie-os para o arquivo
+     - Escreva no caminho de saída especificado nas instruções
+   - Mostre o que foi criado e o que agora está desbloqueado
+   - PARE após criar UM artifact
+
+   ---
+
+   **Se nenhum artifact estiver pronto (todos bloqueados)**:
+   - Isso não deveria acontecer com um schema válido
+   - Mostre o status e sugira verificar problemas
+
+4. **Após criar um artifact, mostre o progresso**
+   \`\`\`bash
+   openspec status --change "<nome>"
+   \`\`\`
+
+**Saída**
+
+Após cada invocação, mostre:
+- Qual artifact foi criado
+- Schema de workflow sendo usado
+- Progresso atual (N/M completos)
+- Quais artifacts agora estão desbloqueados
+- Prompt: "Execute \`/opsx:continue\` para criar o próximo artifact"
+
+**Diretrizes de Criação de Artifacts**
+
+Os tipos de artifact e sua finalidade dependem do schema. Use o campo \`instruction\` da saída das instruções para entender o que criar.
+
+Padrões comuns de artifacts:
+
+**Schema spec-driven** (proposal → specs → design → tasks):
+- **proposal.md**: Pergunte ao usuário sobre a change se não estiver claro. Preencha Por Que, O Que Muda, Capabilities, Impacto.
+  - A seção Capabilities é crítica - cada capability listada precisará de um arquivo spec.
+- **specs/<capability>/spec.md**: Crie um spec por capability listada na seção Capabilities do proposal (use o nome da capability, não o nome da change).
+- **design.md**: Documente decisões técnicas, arquitetura e abordagem de implementação.
+- **tasks.md**: Divida a implementação em tarefas com checkbox.
+
+Para outros schemas, siga o campo \`instruction\` da saída do CLI.
+
+**Guardrails**
+- Crie UM artifact por invocação
+- Sempre leia artifacts de dependência antes de criar um novo
+- Nunca pule artifacts ou crie fora de ordem
+- Se o contexto estiver incerto, pergunte ao usuário antes de criar
+- Verifique se o arquivo do artifact existe após escrever antes de marcar progresso
+- Use a sequência de artifacts do schema, não assuma nomes específicos de artifacts
+- **IMPORTANTE**: \`context\` e \`rules\` são restrições para VOCÊ, não conteúdo para o arquivo
+  - NÃO copie blocos \`<context>\`, \`<rules>\`, \`<project_context>\` para o artifact
   - Eles guiam o que você escreve, mas nunca devem aparecer na saída`
     };
 }