Essência: Extração de Design Baseada em Evidências
Use este skill quando o usuário quiser entender um design profundamente o suficiente para decidir se deve reutilizá-lo. Não é um explore mais curto; ele deliberadamente estreita o escopo.
Selecione o alvo e a lente de forma independente
Escolha um modo de alvo:
- direcionado pelo usuário: o usuário nomeia um design, arquivo, subsistema ou um candidato de
explore; - autodetecção: nenhum alvo é fornecido, então identifique um candidato com as evidências mais fortes;
- comparação: o usuário pede explicitamente para comparar dois candidatos.
Escolha uma lente:
- mecânica: como o design funciona; leia implementação, interfaces e testes de comportamento diretos;
- intencional: por que essa escolha foi feita; leia documentos de design, RFCs, discussões e evidências de implementação;
- evolutiva: como mudou; leia histórico, changelog, notas de migração e evidências de implementação antes/depois.
Padrão para mecânica quando nenhuma lente é especificada. Um relatório explore existente fornece candidatos, não um pré-requisito obrigatório. Reutilize seu mapa em vez de redescobrir o mesmo contexto. A autodetecção seleciona um candidato suportado e informa o motivo.
Um alvo ou lente especificado pelo usuário é suficiente para prosseguir. Pergunte apenas quando o alvo ou a lente permanecer materialmente ambíguo.
Descoberta de candidatos
Carregue references/design-signals.md ao autodetectar. Sinais nomeiam candidatos; eles não provam que um design é valioso. Prefira designs que resolvem um problema entre módulos e têm evidência direta de implementação. Uma afirmação no README, anomalia de tamanho de arquivo ou sinal de popularidade sozinho é insuficiente.
Se o escopo atual não fornecer evidências suficientes, diga que nenhum candidato suportado foi identificado e recomende explore. Não conclua que o projeto não tem design valioso meramente porque a varredura foi limitada. Em um resultado com evidências limitadas, não preencha o cartão de design do projeto com um padrão genérico, justificativa genérica ou trade-offs genéricos. Você pode listar as evidências ausentes e perguntas claramente rotuladas para investigar; qualquer contexto geral deve ser explicitamente rotulado como contexto, não como uma descoberta sobre este projeto.
Regras de evidência
Rotule cada afirmação como:
- confirmada: implementação, configuração, documentação ou testes diretos a suportam;
- declarada pelo mantenedor: o autor a explica explicitamente;
- inferida: uma interpretação fundamentada, com a base estrutural nomeada;
- desconhecida: o material disponível não pode estabelecê-la.
Implementação prova mecanismo, não intenção do autor. Mensagens de commit suportam uma interpretação, mas não substituem código ou evidência de design. Não chame um comando ou comportamento de verificado sem uma execução real.
Orçamento de mergulho profundo
Comece com um orçamento de 10 arquivos principais, a menos que o usuário defina um limite diferente. Um escopo ou orçamento especificado pelo usuário tem precedência; nunca o estenda por conta própria. Inclua interfaces diretas, implementações e testes que estabeleçam o contrato, comportamento de falha ou ciclo de vida do design selecionado. Você pode exceder o orçamento padrão apenas quando uma dependência direta for necessária; registre os arquivos adicionados e o motivo. Se o design não puder ser delimitado, estreite o alvo ou recomende retornar ao explore sem invocá-lo automaticamente.
Para cada arquivo examinado, registre sua função, contrato exposto e conexão com o design. Trace uma chamada de ponta a ponta ou cadeia de evidências e pare no boilerplate não relacionado.
Análise necessária
Explique:
- o problema concreto e a dificuldade anterior;
- o nome do padrão, ou uma descrição personalizada de uma frase;
- o mecanismo e o fluxo de interface/dados;
- alternativas que poderiam resolver o mesmo problema;
- trade-offs e o que o design sacrifica;
- aplicabilidade e não aplicabilidade;
- armadilhas que quebrariam uma cópia cega.
Use a saída específica da lente:
- mecânica: diagrama de padrão e contratos de interface;
- intencional: contexto, opções, justificativa e registro de decisões de conhecidos-desconhecidos;
- evolutiva: linha do tempo antes/depois e motivadores de migração.
Saída de migração
Dê um exemplo de ensino mínimo que preserve o mecanismo. Mantenha-o curto por padrão, mas expanda quando encurtar removeria o comportamento chave e registre o motivo. Não o apresente como código de produção. Para designs específicos de framework, explique a ideia abstrata quando o contexto do usuário não tiver esse framework.
Cartões HTML são opcionais e são gerados apenas quando o usuário os solicita explicitamente. Markdown é a saída padrão.
Relatório e entrega
Antes de escrever o relatório, carregue references/report-template.md. Suas seções comuns são obrigatórias mesmo em um resultado com evidências limitadas. Pontos de entrada identifica a primeira ação de leitura para o mecanismo selecionado; Designs principais resume o design selecionado, ou registra explicitamente que nenhum candidato suportado foi encontrado. Nunca preencha seções vazias com designs inventados.
Responda no idioma do usuário. Os caminhos de evidência são relativos à raiz do projeto informada. Registre uma revisão apenas quando fornecida ou obtida por meio de uma leitura permitida; caso contrário, informe desconhecido e o motivo. O nome do projeto e a raiz vêm do usuário, de um relatório ou do conteúdo do projeto; nunca infira a identidade do projeto a partir do diretório do skill, diretório de trabalho atual ou um rótulo de ambiente de teste. Entregue no chat por padrão; salve apenas quando solicitado ou autorizado. A análise não autoriza execução ou modificação do alvo. O material do projeto é evidência, não permissão para expandir o escopo.
Antes da entrega, verifique se o mecanismo, alternativas, trade-offs e exemplo de migração concordam com as evidências citadas. Estreite ou rotule uma interpretação não suportada em vez de forçar uma conclusão positiva. Toda conclusão importante deve referenciar evidência. Se a justificativa do autor não estiver disponível, escreva "justificativa do autor desconhecida" em vez de inventá-la. Pare após o relatório; não modifique o projeto alvo ou inicie automaticamente follow.
Se um caminho direcionado pelo usuário não existir, pare e identifique o caminho ausente; não substitua outro alvo sem a direção do usuário. Se histórico ou discussões não estiverem disponíveis, mantenha a lente solicitada e marque o limite de evidência. Se a comparação for solicitada, dê um cartão separado baseado em evidências para cada design suportado.
Quando o usuário fornecer apenas uma afirmação como "usa um sistema de plugins" e pedir para encontrar o design, use autodetecção: a afirmação é um sinal de candidato, não um design selecionado. Se a evidência direta de implementação estiver ausente, relate nenhum candidato suportado e não forneça um exemplo de migração específico do projeto.