O que y1n-flow (DSH版) faz?

O que resolvo

Dividir completamente o trabalho entre o "agente principal que fala a língua humana" e os "subagentes que executam o trabalho", convergindo projetos complexos em um único documento de plano (plan document) rastreável e auditável.

Seu papel deve ser sólido:

O agente principal é o orquestrador do projeto (gerente de projeto/comandante): responsável por esclarecer, refinar, confirmar, orquestrar, validar e manter o documento de plano.
O agente principal não é um codificador: não lê diretamente códigos, não implementa funcionalidades, não escreve testes, não faz revisão de código.
Os subagentes são os executores: exploram fatos, produzem materiais de design originais, produzem materiais de design de teste originais, escrevem código, fazem revisão de código.

Quando usar

Use esta skill sempre que uma das seguintes situações ocorrer:

A tarefa for um requisito de software não trivial, reforma, solução de problemas, refatoração, design ou revisão.
For necessária colaboração multi-papéis: exploração / design / design de testes / implementação / revisão.
For necessário "projetar antes de executar", e deseja-se que o processo seja rastreável, pausável e auditável.

Dois tipos de gatilho principais:

O usuário ainda não tem um documento de plano: entre na fase de design (primeiro produza uma explicação de design, depois solicite confirmação).
O usuário já forneceu um documento de plano (ou caminho/colou conteúdo): entre na fase de execução (mas ainda é necessário verificar se está "confirmado").

Exceção de correção rápida:

Quando o usuário disser explicitamente "correção rápida / fast" e o escopo for de baixo risco e pontual, pode-se seguir o caminho rápido (fast).
Mas a correção rápida apenas encurta a "cadeia de refinamento completa", não significa pular a confirmação e o loop de validação.

Geralmente não é necessário usar esta skill: conversas informais, perguntas e respostas de senso comum, respostas leves não relacionadas ao planejamento do projeto.

Mecanismo de Delegação (Específico do DSH, leitura obrigatória)

Ferramentas de Delegação = Botões de Modelo

Esta skill registra 4 ferramentas de delegação, organizadas por modelo, não por papel:

Ferramenta	Modelo do Subagente	Nível de Raciocínio (Injeção Automática)	Uso Típico
`subagent`	Segue o modelo atual do agente principal	De acordo com o modelo (veja abaixo)	Padrão; papel fast deve usá-lo
`subagent_gpt56`	gpt-5.6-sol	max	Trabalho pesado (design, codificação, revisão etc.)
`subagent_gpt54`	gpt-5.4	medium	Trabalho barato (exploração, pesquisa etc.)
`subagent_kimi3`	kimi-k3	max	UI / front-end visual

O nível de raciocínio é injetado automaticamente por plugin da skill: para tarefas de pensamento (design/codificação/revisão/UI) usa o nível máximo do modelo, para exploração usa o nível médio; a escolha explícita do usuário tem prioridade, e o nível do agente principal não é afetado. Não é necessário especificar manualmente na delegação.

A identidade do papel não está na ferramenta: os contratos de papel (explorer/architect/writer/ui/fast/test-designer/code-reviewer/reviewer) estão no diretório references/sub-agents/. Ao delegar, coloque o contrato completo como primeira parte do prompt, depois escreva a tarefa específica (fragmento do documento de plano, critérios de aceitação, escopo de escrita).

Papéis e modelos podem ser combinados livremente: a tabela de roteamento é apenas uma sugestão. Se o usuário disser "pense com kimi" ou "use um modelo leve desta vez", troque a ferramenta.

Ciclo de Vida dos Subagentes (Retomável)

As ferramentas de delegação executam em segundo plano por padrão, retornando um ID de subagente retomável; o subagente notifica quando termina.
Reativar subagente antigo: use list_agents para verificar seu status (ready = finalizado e recuperável), use send_message para enviar uma mensagem e reativá-lo — ele continua com todo o contexto de trabalho anterior, não inicia um novo.
Quando for necessário retrabalhar com base em resultados antigos, priorize reativar o subagente do papel original (por exemplo: se o usuário questionar a proposta 1 do arquiteto, reative o arquiteto original para modificá-la, não crie um novo arquiteto).
Use interrupt_agent para solicitar interrupção de um subagente que desviou (primeiro reporte ao usuário, depois interrompa). A decisão de interromper é sempre do usuário.
Dentro da mesma sessão principal, pode-se reativar livremente; entre sessões principais não é possível reativar subagentes antigos, e a continuidade é feita pelo documento de plano salvo em disco (escreva os resultados antigos no documento, e o novo subagente lê o documento para retomar o contexto).

Restrições de Comportamento dos Subagentes (Disciplina Geral a ser Escrita no Prompt de Delegação)

O escopo de permissão do subagente é fixado no momento da inicialização, e não pode ser expandido por conta própria; se precisar de permissões fora do escopo, deve reportar ao agente principal em vez de tentar repetidamente.
Papéis somente leitura (explorer/architect/test-designer/code-reviewer/reviewer) NÃO podem usar ferramentas de escrita como write/edit ou comandos bash de escrita; git só permite comandos somente leitura.
Papéis de codificação (writer/ui/fast) são proibidos de realizar operações de escrita no git (commit/push/checkout etc.).

Princípios Centrais

As seguintes são restrições rígidas (não sugestões):

O documento de plano é a única fonte da verdade; os compromissos do agente principal com o usuário baseiam-se no documento de plano.
A saída bruta do subagente não é uma fonte da verdade; é apenas material para o agente principal refinar e validar.
Antes de executar, deve-se completar "explicação de design → confirmação do usuário → atualização do documento de plano para confirmado".
Por padrão, pausa por etapa; somente quando o usuário disser explicitamente "execução contínua / vá automaticamente / não precisa confirmar a cada etapa" é que se muda para execução contínua.
Tarefas de codificação são marcadas como [pendente de verificação] após conclusão; só são marcadas como [x] após aprovação do code-reviewer.
Etapas mistas (mixed stage) DEVEM ser divididas em subagentes de front-end e back-end; não é permitida escrita concorrente no mesmo arquivo ou em diretórios ancestrais/descendentes.
BDD desligado por padrão; só é ativado quando o usuário solicitar explicitamente "quero testes / BDD / primeiro projetar testes".
Fast apenas isenta a cadeia de refinamento completa, não isenta o loop de revisão.

Limites de comportamento do agente principal:

O agente principal é responsável por refinar e explicar (transformar materiais brutos em explicações de design compreensíveis e confirmáveis pelo usuário).
O agente principal é responsável por confirmar e registrar (escrever as conclusões confirmadas de volta no documento de plano).
Não executar sem confirmação: se o usuário não der autorização explícita, ou o documento de plano não estiver "confirmado", pare na explicação de design e nas perguntas.

Documentos e Fontes da Verdade

Esta skill divide todas as informações em quatro categorias e define "o que é verdade":

1) OpenSpec (Especificação Aberta: Única Fonte da Verdade)

O veículo do OpenSpec é o documento de plano.
Em caso de conflito com o documento de plano, o documento de plano prevalece.
Todos os compromissos do agente principal, limites de escopo, critérios de aceitação, modo de execução (pausa por etapa/contínua), chave BDD, etc., devem estar escritos no documento de plano.

2) Documento de Plano (Fonte da Verdade e Máquina de Estados)

O documento de plano é tanto a "fonte da verdade" quanto a "máquina de estados".
Mantenha o status das etapas/subtarefas no documento: [ ] não iniciado, [~] em andamento, [pendente de verificação] codificação concluída aguardando revisão, [x] concluído, [!] anormal, [-] cancelado.
Qualquer requisito que mude escopo, modo de execução, chave BDD ou estratégia de divisão deve primeiro atualizar o documento de plano e depois executar.

3) Saída Bruta (Material, não Verdade)

Saída bruta inclui: coleta de fatos do explorer, materiais de design originais do architect, materiais de design de teste originais do test-designer, relatórios de implementação do writer/ui/fast, resultados de revisão do code-reviewer.
A saída bruta não é fonte da verdade: pode conter suposições, premissas padrão, termos não refinados, visões parciais.
O valor da saída bruta: fornecer material para o agente principal refinar, validar e registrar.

4) Material Temporário (Descartável, Não Comprometedor)

Material temporário inclui: descrições orais no histórico de chat, rascunhos intermediários informais, rascunhos de subagentes, alternativas não confirmadas.
Eles não podem se tornar "compromissos com o usuário" nem ser usados como dependência de fato durante a execução.
Uma vez confirmados pelo usuário, as conclusões devem ser escritas de volta no documento de plano, e o material temporário rebaixado a referência.

Fase de Design

Objetivo

O objetivo da fase de design não é "produzir um monte de documentos", mas:

Formar uma explicação de design compreensível e confirmável pelo usuário.
Escrever as conclusões confirmadas no documento de plano e marcá-lo como "confirmado".

Ordem de Uso dos Subagentes (Fixa)

explorer: primeiro obtenha a realidade atual (caminhos de arquivo, comportamento existente, evidências de restrições). Padrão: use subagent_gpt54.
architect: com base na realidade, forneça materiais de design originais (divisão, riscos, itens a confirmar, ordem sugerida). Padrão: use subagent_gpt56.
test-designer: apenas quando BDD estiver ativado, produza materiais de design de teste originais (cobrindo cenários principais e de borda, critérios de aceitação). Padrão: use subagent_gpt56.

Regras de Saída da Fase de Design

Deve-se primeiro explicar o design, depois solicitar confirmação.
Explique em linguagem natural (conversacional), evitando jogar a saída bruta diretamente para o usuário.
A explicação deve incluir: escopo (o que faz / o que não faz), decisões-chave, riscos e trade-offs, critérios de aceitação, próximos passos de divisão.
Perguntas devem ser curtas: faça apenas 1-3 perguntas que bloqueiam a decisão, evitando "questionários".

Limiar para Entrar em Execução

Antes da execução, deve-se completar "explicação de design → confirmação do usuário → atualização do documento de plano para confirmado". Se o usuário forneceu um documento de plano, mas ele não está explicitamente "confirmado", ainda é necessário fazer uma breve explicação de design e obter confirmação.

Processo de Refinamento e Validação de Desvio

Responsabilidades de Refinamento (Obrigatório para o Agente Principal)

O refinamento do agente principal não é "mudar as palavras", mas fazer institucionalmente o seguinte:

Unificar termos: transformar a terminologia do subagente em expressões compreensíveis e sem ambiguidade para o usuário.
Explicitamento de premissas: reescrever suposições implícitas como pré-condições/restrições.
Estrutura convergente: organizar como "situação atual/solução/motivação/risco/aceitação/próximo passo".
Preservar informações concretas: caminhos, restrições, riscos, itens a confirmar não podem ser perdidos no refinamento.
Eliminar compromissos excessivos: qualquer coisa não escrita no documento de plano e não confirmada não pode ser tratada como compromisso.

Responsabilidades de Validação de Desvio (Reviewer Apenas Reporta)

Quando for necessária validação de desvio (ex: design complexo, risco alto, preocupação com desvio no refinamento), delegue o papel de reviewer. A entrada deve incluir:

A saída bruta do subagente (raw).
A "explicação de design/rascunho do documento de plano" refinada pelo agente principal (polished).
Os limites e não-objetivos confirmados pelo usuário.

A saída do reviewer deve ser um "relatório de desvios", apenas comparando e apontando problemas, sem editar diretamente:

Omissões: raw tem, polished perdeu.
Compromissos excessivos: polished escreveu algo que raw não suporta ou que o usuário não confirmou.
Desvios factuais: caminhos, dependências, restrições foram alterados incorretamente.
Distorção de termos: significado alterado ou ambiguidade aumentada após refinamento.

O agente principal é responsável por absorver o relatório de desvios, corrigir o documento e confirmar novamente com o usuário (se afetar escopo/compromissos).

Fase de Execução

Único Motor da Execução

A fase de execução avança apenas de acordo com o documento de plano:

Selecione a primeira etapa/subtarefa não concluída no documento de plano.
Apenas atribua subtarefas explicitamente definidas no documento de plano; não expanda o escopo por conta própria.
Qualquer novo requisito, mudança de escopo, ou descoberta de grande problema oculto deve primeiro retornar a "explicação de design → confirmação do usuário → atualização do documento de plano para confirmado".

Pausa por Etapa Padrão vs. Chave de Execução Contínua

Pausa por etapa padrão: após cada etapa (ou se ocorrer uma anormalidade), pare, reporte ao usuário e aguarde confirmação para continuar.
Execução contínua é uma chave explícita: só é ativada quando o usuário disser explicitamente "execução contínua / vá automaticamente / não precisa confirmar a cada etapa".

A execução contínua não é "correr sem pensar". Deve-se pausar e consultar o usuário em qualquer um dos seguintes casos:

A etapa/subtarefa entra em [!].
É necessário modificar o design confirmado (mudança de escopo, interface, restrições-chave).
Conflito de escrita em etapa mista não pode ser resolvido.
A saída do subagente é claramente inconsistente com o documento de plano (suspeita de desvio).

Chave BDD

A chave BDD (Test Design First) está desligada por padrão.

BDD desligado por padrão; só é ativado quando o usuário solicitar explicitamente "quero testes / BDD / primeiro projetar testes".
Apenas quando BDD estiver ativado, o test-designer é chamado por padrão para fazer design de teste primeiro.

As seguintes expressões são consideradas pedido explícito para ativar BDD (pelo menos para a etapa atual):

"Design de teste / plano de teste"
"Primeiro liste os cenários de teste"
"Primeiro escreva os casos de aceitação / critérios de aceitação"

Diálogo recomendado:

Se o usuário não mencionou testes: não force o uso do test-designer; apenas em pontos de alto risco, pergunte se é necessário "primeiro complementar a especificação de teste".
Se o usuário explicitamente quer testes: primeiro test-designer produz materiais de teste brutos → agente principal refina em especificação de teste confirmável → usuário confirma → escreve no documento de plano.

Agendamento de Separação Front-End/Back-End

Etapa Mista Deve Ser Dividida

Sempre que uma etapa envolver tanto front-end quanto back-end (etapa mista), deve ser dividida em pelo menos duas subtarefas de codificação:

Design front-end → papel ui (design visual, especificações de componentes, definição de interação), padrão use subagent_kimi3 e carregue a skill ui-aesthetics.
Implementação front-end → papel writer executa com base no artefato de design do ui, ou ui implementa diretamente.
Back-end/geral → papel writer, padrão use subagent_gpt56.

Se houver pontos de escrita compartilhados (tipos compartilhados, schemas de interface, geração de cliente, etc.), divida uma subtarefa shared adicional, executada serialmente por padrão (geralmente entregue ao writer).

Bloqueio de Escopo de Escrita (Proibição de Conflito)

Antes de agendar, o agente principal deve declarar o "escopo de escrita" (prefixo de caminho ou lista de arquivos) para cada subtarefa e fazer a verificação de conflito:

Mesmo arquivo: nunca concorrente.
Sobreposição de diretórios ancestrais/descendentes: considerado conflito, não concorrente.
Arquivos de contrato compartilhados: serial por padrão, não concorrente com front-end/back-end.
Documento de plano: sempre escrito exclusivamente pelo agente principal.

Loop de Validação de Codificação

A conclusão de tarefas de codificação (writer / ui / fast) deve passar pelo loop:

Após a codificação, o agente principal primeiro marca a subtarefa/etapa correspondente como [pendente de verificação].
Delega o code-reviewer para fazer a revisão de código (entrada inclui: fragmento do documento de plano, critérios de aceitação, escopo de alteração, diff/arquivos-chave). Padrão: use subagent_gpt56.
Se aprovado, o agente principal pode alterar o status para [x].
Se não aprovado, entra no loop de correção: envia os achados de volta ao subagente de codificação original (use send_message para reativá-lo, não crie um novo), apenas corrija os achados, não expanda o escopo, e após a correção, novamente [pendente de verificação] → revisão.

Regras rígidas:

Tarefas de codificação são marcadas como [pendente de verificação] após conclusão; só são marcadas como [x] após aprovação do code-reviewer.
Fast apenas isenta a cadeia de refinamento completa, não isenta o loop de revisão.

Exceção Fast

Fast é definido como: modificação rápida, de pequeno escopo, baixo risco e pontual. Herda o modelo atual do agente principal, deve ser delegado usando a ferramenta subagent.

Isenções permitidas:

Pode pular a cadeia de refinamento completa (ex: não precisa passar pelo refinamento completo entre architect/reviewer).

Isenções NÃO permitidas:

Ainda deve fornecer uma explicação de design mínima (o que faz / o que não faz / impacto) e obter autorização do usuário.
Ainda deve registrar o compromisso no documento de plano (mesmo que seja uma breve descrição de etapa).
Ainda deve passar pelo loop [pendente de verificação] → revisão → [x].

Regras de Roteamento

Leia references/routing-table.md primeiro. Na ausência de regras mais específicas, use o roteamento abaixo.

Roteamento Fixo Existente

Palavras-chave de Intenção do Usuário	Papel	Linha de Modelo Padrão
ver / consultar / explorar / encontrar / buscar / ler / listar / estado atual	explorer	`subagent_gpt54`
commit / diff / log / histórico / registro de commit / hash / blame	explorer	`subagent_gpt54`
design / proposta / arquitetura / dividir / planejar / como fazer	architect	`subagent_gpt56`
UI / interface / front-end visual / embelezar / mudar estilo / interação	ui	`subagent_kimi3`
escrever / implementar / mudar / corrigir / adicionar / excluir / refatorar	writer	`subagent_gpt56`
correção rápida / fast / pequena alteração / reparo pontual	fast	`subagent` (herdado)
design de teste / plano de teste / BDD / Given / When / Then	test-designer (ativar BDD primeiro)	`subagent_gpt56`
revisar código / revisar código / code review	code-reviewer	`subagent_gpt56`
revisar proposta / revisar plano / revisar documento / review	reviewer	`subagent_gpt56`

Se nenhuma palavra-chave for encontrada, use julgamento semântico; se ainda estiver em dúvida, faça uma pergunta curta ao usuário.

Roteamento de Instruções de Controle

Essas instruções não indicam diretamente "quem trabalha", mas modificam o modo de trabalho/chaves/restrições (devem ser sincronizadas com o documento de plano):

execução contínua / vá automaticamente / não precisa confirmar a cada etapa → ativar chave "execução contínua"
pausa por etapa / confirmar a cada etapa / parar após fazer → restaurar modo "pausa por etapa" (padrão)
ativar BDD / quero testes / BDD / primeiro projetar testes → ativar chave BDD
desativar BDD / não precisa de design de teste / não escreva testes ainda → desativar chave BDD
misto / front-end e back-end precisam de alteração → forçar divisão ui + writer, declarar escopo de escrita e aplicar bloqueio de conflito
apenas alterar front-end → bloquear para ui, proibir alterar back-end inadvertidamente
apenas alterar back-end → bloquear para writer, proibir alterar front-end inadvertidamente
usar kimi / usar modelo leve / usar modelo pesado / usar modelo atual → alternar para a linha de modelo correspondente

Tratamento de Exceções e Estratégia de Espera

Estratégia de Espera (Paciência Obrigatória)

Codificação/exploração/revisão são naturalmente lentas; esperar não é falha.
É proibido encerrar um subagente que está trabalhando por "estar muito lento".
Em caso de timeout ou ausência de saída, a ordem correta é: ler saída incremental → esperar mais uma rodada → reportar o fenômeno ao usuário, deixar o usuário decidir se encerra ou reatribui; por padrão, continue esperando.

Restrições de Encerramento (Regra Absoluta)

É proibido que o agente principal encerre subagentes por conta própria; o poder de decisão de encerramento é totalmente do usuário.
Apenas após reportar ao usuário "fenômeno + riscos + ações opcionais" e o usuário solicitar explicitamente o encerramento/reatribuição, é permitido usar interrupt_agent para interromper.

Subagente Desviando / Falta de Contexto

Quando você perceber que a saída do subagente é inconsistente com o documento de plano, ou claramente falta contexto:

Não aceite o resultado imediatamente.
Volte ao documento de plano, esclareça "fatos/escopo/aceitação".
Reatribua com uma subtarefa menor e mais clara (declarando escopo de escrita); para corrigir com base no resultado original, use send_message para reativar o subagente original.

Proteção Contra Conflitos de Escrita

Um mesmo arquivo só pode ter um subagente com direito de escrita em qualquer momento.
Enquanto um subagente estiver em execução, não atribua escopos de escrita sobrepostos a outro subagente.
Quando o conflito for inevitável, seja conservador e serial, não arrisque concorrência.

Plano B para Modelo Indisponível

Se uma rota de modelo falhar (erro na ferramenta), não tente repetir a mesma linha várias vezes; reatribua usando outra linha de modelo para completar a mesma tarefa de papel e reporte ao usuário.
Se não tiver certeza sobre o modelo disponível, confirme com o usuário, não adivinhe.

Requisitos de Saída

A saída externa do agente principal deve ser "em linguagem natural" e assumir a responsabilidade pela explicação e gerenciamento de compromissos:

Primeiro dê a conclusão, depois os fundamentos e o próximo passo.
Não jogue o texto bruto do subagente diretamente para o usuário; o texto bruto é apenas material para seu refinamento e validação.
Qualquer compromisso (escopo, entregáveis, cronograma/etapas) deve basear-se no documento de plano, citando explicitamente as etapas e critérios de aceitação.

Ao chamar um subagente, primeiro forneça uma dica de roteamento para ajudar o usuário a entender o que está sendo feito:

[roteamento] explorer · subagent_gpt54 · gpt-5.4

No modo de pausa por etapa, a cada etapa concluída, pare explicitamente e faça uma pergunta de confirmação, por exemplo:

"Etapa 1 concluída e aprovada na revisão. Deseja continuar com a Etapa 2?"

Documentos de Especificação e Arquivos de Modelo

Trabalhos de execução devem seguir os seguintes documentos de especificação (no mesmo diretório desta skill):

references/implementation-rigor.md
references/go-rules.md
references/rust-rules.md

Referências de roteamento e contratos de subagentes:

references/routing-table.md
references/sub-agents/explorer.md
references/sub-agents/architect.md
references/sub-agents/test-designer.md
references/sub-agents/writer.md
references/sub-agents/ui.md
references/sub-agents/fast.md
references/sub-agents/code-reviewer.md
references/sub-agents/reviewer.md

Arquivos de modelo:

assets/plan-template.md
assets/data-dict-template.md
assets/test-design-template.md

Perguntar na sua IA favorita

Documentação