EvolveHQ/docflow

brainstorm

Transforme um problema difuso em um conjunto estruturado de ADRs candidatos e itens de plano. Este skill é generativo e somente leitura/proposta — nunca escreve ADRs ou arquivos de plano diretamente. Após aprovação, entrega cada candidato aos skills new-adr e new-plan.

Etapa 0 — Pré-condições e contexto

1. Confirme que o repositório está inicializado (ou observe que a saída pode alimentar uma execução nova do skill bootstrap).
2. Leia CONVENTIONS.md para a forma e ciclo de vida dos ADRs, e examine INDEX.md + ADRs existentes para que os candidatos não dupliquem ou contradigam o que já existe, e que as dependências apontem para ADRs reais.

Etapa 0.5 — Avaliação (executar primeiro)

Execute o protocolo de avaliação compartilhado antes de decompor:

• Reutilize respostas fornecidas primeiro. Trate as escolhas aplicáveis já fornecidas na requisição ou nesta sessão, incluindo profundidade, como respondidas. Resuma-as sem perguntar novamente; os padrões nunca substituem escolhas explícitas. Se todas as escolhas materiais forem fornecidas, prossiga. Pergunte apenas sobre uma escolha material ausente ou conflitante. Uma preferência do repositório sozinha não é uma resposta atual ou concessão de execução.

• Seletor de profundidade para escolhas não resolvidas. Se a profundidade não for fornecida e restarem escolhas, pergunte quão profunda esta avaliação deve ir: expressa — cada escolha assume seu padrão recomendado; apenas perguntas sem padrão derivável (o essencial de texto livre) ainda são feitas; guiada — apenas as perguntas marcadas como alto impacto abaixo, mais o essencial de texto livre; completa — todas as perguntas abaixo. Se o CONVENTIONS.md do repositório registrar uma Assessment depth:, pré-selecione-a como a opção recomendada ao perguntar; uma profundidade registrada nunca é aplicada silenciosamente. Caso contrário, recomende completa quando a requisição chegou com pouco ou nenhum contexto e expressa quando já está totalmente especificada. Em qualquer pergunta, o operador pode responder "padrões daqui em diante" ou "vá mais fundo"; honre a mudança imediatamente.

• Faça as perguntas abaixo uma de cada vez, cada uma com uma opção recomendada e uma justificativa de uma linha; aguarde cada resposta.

• Use seleção estruturada (escolha única ou múltipla). Se o host expuser uma ferramenta de pergunta estruturada de seleção única/múltipla, use-a e marque a opção recomendada; caso contrário, liste opções A/B/C em texto simples e nomeie a recomendada. Use texto livre apenas onde um conjunto enumerável é impossível (por exemplo, a declaração do objetivo).

• O operador decide. Nunca prossiga além de uma pergunta sem resposta, e nunca adivinhe o escopo quando invocado sem contexto.

Perguntas (pule qualquer uma que a requisição já responda):

1. Objetivo / problema — texto livre (a resposta aberta inevitável; perguntada em toda profundidade) se ainda não fornecida.
2. Saída — apenas ADRs candidatos, ou ADRs + itens de plano. Recomendado: ADRs + itens de plano.
3. Profundidade da decomposição — rápida (principais candidatos) ou completa (decomposição total). Recomendado: rápida primeiro, expandir sob demanda.

Nenhuma pergunta aqui é marcada como alto impacto — uma execução guiada se comporta como expressa para este skill.

Este skill ainda não escreve nada até que você aprove o esboço.

Etapa 1 — Entender o problema

Pergunte pelo objetivo/funcionalidade/problema se não for fornecido. Investigue limites de escopo, restrições e as preocupações regulatórias/de qualidade que importam para este repositório. Não comece a decompor até que o objetivo esteja claro.

Etapa 2 — Decompor

Produza uma lista de candidatos. Para cada ADR candidato:

• Número proposto (próximo disponível, contíguo), título de trabalho, forma (capacidade vs. tecnologia se o repositório separar).
• Escopo de uma linha — a única decisão que captura.
• Dependências de outros candidatos ou ADRs existentes.

Uma decisão por ADR. Se um candidato agrupar várias decisões, divida-o e explique por quê. Se um candidato for na verdade um ADR existente que precisa de revisão, diga isso em vez de propor um novo número.

Etapa 3 — Ordenar o trabalho

Proponha uma ordenação de plano (quais itens de plan/todo/, em que sequência) respeitando as arestas de dependência. Observe onde o trabalho pode ser paralelizado (entrada útil para o skill agent-wave).

Etapa 4 — Revisar e entregar

Apresente o conjunto completo como um esboço revisável (candidatos + dependências + ordenação). Aceite edições. Não escreva nada ainda. Uma vez que o usuário aprove, crie-os invocando o skill new-adr por candidato e o skill new-plan por item enfileirado — ou entregue o esboço aprovado para esses skills.

Barreira de segurança: se o problema for muito vago para decompor sem inventar requisitos, diga isso e peça mais, em vez de produzir ADRs especulativos.

Nomeie as opções acordadas e as decisões restantes; a discussão sozinha não escreve artefatos.

Relatório de encerramento

Termine toda execução, incluindo execuções bloqueadas, com falha e interrompidas, com uma seção intitulada exatamente Status rápido, contendo estes três rótulos:

• Esta execução: apenas as ações realmente tentadas e seus resultados; cite a saída exata e o código de saída de cada portão de verificação, incluindo timeouts ou interrupções.
• Geral: implementado, parcialmente verificado, verificado, bloqueado, com falha ou desconhecido. Uma subetapa aprovada não é uma aprovação geral; evidência incompleta ou ausente nunca se torna sucesso.
• Ainda a fazer: toda ação restante, descoberta não resolvida, verificação, limpeza ou entrada necessária. Escreva Nenhum apenas quando toda a tarefa estiver verificavelmente completa; nunca omita trabalho porque um orçamento terminou.

Mensagens de progresso rotineiras não precisam de bloco. Mantenha os resultados finais breves e distinga trabalho preparado em um PR de trabalho confirmado como enviado.