As artes obscuras da engenharia de skills — Paul Bakaus, geek renascentista

Ver no idioma original →

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: The Dark Arts of Skill Engineering — Paul Bakaus, Renaissance Geek · Canal: AI Engineer · 1:04:27 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de software com IA

Resumo

Paul Bakaus conta como criou Impeccable, uma skill de design que evoluiu de um prompt simples para uma extensão mais ampla do harness. Ele apresenta técnicas para melhorar a qualidade e a consistência dos resultados, como usar subagents para críticas independentes, introduzir fontes de divergência e persistir aprendizados entre sessões. Também explica como scripts, hooks e recursos do navegador integrado podem criar ciclos de validação e interação. Por fim, aborda as diferenças entre harnesses e modelos, os desafios de avaliar skills e a necessidade de testá-las antes de distribuí-las.

Pontos-chave

• Skills eficazes vão além de prompts: podem estender o harness com scripts, hooks e interações com ferramentas.
• Subagents com avaliações independentes ajudam a evitar que um modelo apenas aprove o próprio trabalho.
• Restrições simples podem trocar um clichê por outro; sementes aleatórias e seleção de alternativas ajudam a forçar divergência.
• Dividir uma skill em instruções específicas e rotas distintas reduz a confusão em tarefas de escopo amplo.
• Salvar críticas e preferências permite que a skill aproveite o contexto de sessões anteriores.
• Scripts podem fornecer instruções estruturadas ao modelo, embora isso possa prejudicar o prompt caching.
• Hooks funcionam como barreiras passivas e ciclos de correção, mas precisam permitir regras de exceção para falsos positivos.
• Harnesses e modelos diferem em permissões, ferramentas e comportamento; skills distribuídas precisam ser adaptadas e testadas em vários ambientes.
• Avaliar gosto estético continua difícil: os modelos podem ajudar em verificações funcionais, mas a avaliação humana ainda é importante.
• Skills compartilhadas devem ser testadas em diferentes modelos e harnesses, em vez de depender apenas de que funcionem na máquina de quem as criou.

Capítulos

Início	Capítulo	Resumo
00:13	Apresentação e origem de Impeccable	Paul Bakaus apresenta Impeccable e explica que a skill nasceu da necessidade de aproximar designs gerados por agentes de um sistema de design.
06:13	De prompts a extensões do harness	Bakaus defende que prompts têm limites e propõe pensar skills como extensões do harness.
12:08	Críticas independentes com subagents	Ele mostra como dois subagents com avaliações cegas entre si podem produzir uma crítica mais equilibrada.
17:06	Como forçar divergência	A palestra apresenta técnicas para afastar o modelo de escolhas previsíveis, incluindo sementes criativas e seleção por subagents.
22:37	Memória entre sessões	Bakaus explica como registrar críticas e preferências para que uma skill aproveite o histórico de trabalho.
29:16	Hooks como barreiras passivas	Ele descreve hooks que validam alterações automaticamente e podem corrigir ou bloquear resultados inadequados.
34:30	Iteração visual pelo navegador	Impeccable conecta o harness ao navegador integrado para selecionar elementos da página, testar variações e enviar orientações ao agente.
39:57	Diferenças entre harnesses e modelos	Bakaus compara permissões, ferramentas e comportamentos de diferentes harnesses e modelos, destacando a necessidade de adaptações específicas.
46:50	Compilar para diferentes ambientes	Ele explica por que Impeccable mantém versões e instruções ajustadas a cada harness e modelo, além de enfatizar o menor denominador comum.
50:12	Perguntas sobre cache e avaliação	Na sessão de perguntas, Bakaus esclarece os efeitos de instruções dinâmicas no prompt caching e descreve testes end-to-end e evals.
55:42	Avaliar gosto e qualidade	Bakaus comenta os limites dos modelos para avaliar gosto estético e defende combinar avaliações automáticas com julgamento humano.
58:24	O futuro das skills	Ele discute os limites da plataforma de skills e pede padrões mais rigorosos de teste para projetos distribuídos.
62:20	Distribuição de skills	A conversa aborda marketplaces, ferramentas de instalação e a falta de um padrão da indústria para distribuir skills entre harnesses.

Citações

A engenharia do harness é onde você deve chegar. — 06:13

Duas opiniões independentes superam um palpite confiante. — 12:08

Barreiras passivas são melhores do que um comando que ninguém lembra de executar. — 32:26

Se uma etapa puder ser pulada, ela será. — 48:31

Eu preferiria ver menos skills no ecossistema, mas que fossem realmente testadas e comprovadas. — 59:30

Conceitos e entidades

• Impeccable (ferramenta): Skill de design criada por Paul Bakaus que reúne instruções, scripts e hooks para apoiar o trabalho em interfaces.
• Paul Bakaus (pessoa): Criador de Impeccable e palestrante sobre engenharia de skills.
• Harness Engineering (conceito): Abordagem que trata uma skill como uma extensão do harness, não apenas como um conjunto de instruções em um prompt.
• anti-attractor (conceito): Técnica descrita por Bakaus para afastar o modelo de escolhas previsíveis por meio de sementes criativas ou aleatórias.
• subagent (conceito): Agente auxiliar que pode executar uma avaliação separada, sem acesso ao trabalho de outro agente.
• hooks (conceito): Mecanismos que executam verificações durante o trabalho do agente e podem orientar ou impedir alterações.
• prompt caching (conceito): Reutilização de conteúdo de prompt em chamadas repetidas, que pode ser afetada por instruções dinâmicas geradas por scripts.
• MCP (conceito): Protocolo mencionado como forma de estender harnesses e distribuir recursos, com possíveis efeitos de poluição do contexto.
• Claude Code (ferramenta): Harness citado na palestra como ambiente que oferece suporte a subagents, hooks e ferramentas de interação.
• Codex (ferramenta): Harness discutido na palestra por suas permissões e comportamentos específicos para subagents, perguntas ao usuário e tarefas em segundo plano.
• Cursor (ferramenta): Harness usado na demonstração do modo interativo de edição visual de Impeccable.
• Gemini (modelo): Modelo citado como exemplo de comportamentos recorrentes que podem exigir instruções específicas.
• Tailwind (ferramenta): Framework citado como exemplo de como escolhas de temas padrão podem influenciar amplamente a estética de interfaces.
• jQuery UI (ferramenta): Framework criado por Paul Bakaus, cujo tema padrão laranja ele usa como exemplo do impacto de padrões visuais.
• Playwright (ferramenta): Ferramenta mencionada como parte dos testes end-to-end de Impeccable.
• Skills.sh (ferramenta): Projeto citado como opção de distribuição de skills, embora tenha limitações para compilar versões por harness.

Tradução completa (pt-BR)

00:13 Olá, pessoal. Como vão? Acho que ainda tem algumas pessoas chegando, mas estou muito empolgado por estar aqui. Primeiro, deixa eu recarregar estes slides, porque meu claw code ainda estava compilando algo neles. Certo. O contraste está um pouco baixo, então tenham paciência comigo. Vou

00:44 tentar cobrir o máximo possível do que vocês não conseguem ler. Também ouvi dizer que o Wi-Fi não é dos melhores. Então, embora seja um workshop, espero que vocês levem muitas lições e possam aplicá-las quando quiserem. Tenho um repo de exemplo caso queiram acompanhar. Certo, antes de tudo, oi, meu nome é Paul. Fico muito feliz que vocês tenham vindo a esta sala. Sou o autor de Impeccable. Alguém aqui já usou Impeccable

01:16 por acaso? Posso ver algumas mãos? Certo, algumas pessoas. Legal. Para quem ainda não usou Impeccable, Impeccable é uma skill que criei principalmente para mim. No último ano, desenvolvi um grande app corporativo, com muitas visualizações, estados e outras coisas. Eu queria projetar rapidamente com meus agents, com Codex, com claw. Mas percebi que, embora ele me levasse rapidamente a algo que eu pudesse avaliar, normalizar o resultado de volta ao sistema de design era muito, muito

01:50 desafiador. Então, a primeira skill que criei para mim se chamava normalize e, de certa forma, trazia de volta ao sistema de design o que quer que o claw tivesse projetado. Foi assim que comecei. Também usei a skill de design refinada da Anthropic, como talvez muitos de vocês, quando comecei. A partir daí, isso foi se expandindo para cada vez mais skills de design, que me permitiram transformar o clawed code, depois o Codex e outros harnesses em algo mais parecido com um harness de design. Em certo momento, pensei que talvez outras pessoas também pudessem achar isso

02:22 útil. Então, disponibilizei como open source e, pelo visto, muita gente gostou. Se ainda não conferiram, experimentem. Está em impeccable.style. Mas hoje não vou falar especificamente sobre Impeccable. Vou falar sobre o que aprendi ao criar essas skills, porque o projeto foi crescendo. Começou como um prompt simples e chegou ao que é hoje. Muita gente olhou o código do Impeccable e viu um

02:54 monte de scripts na pasta scripts e pensou: “O que é tudo isso?”. Então, queria compartilhar com vocês um pouco do conhecimento que adquiri. Vamos começar. Vamos falar sobre as artes ocultas da engenharia de skill. [ofegante] Certo. A produção desta palestra está incrível. Então, antes de tudo, vocês já viram este tipo de design. Na verdade, este é um design

03:28 feito com a skill de design frontend e clawed code. Provavelmente todos já viram um design assim. É para um app fictício de leitura infantil para iPad. Tem uma fonte serifada em itálico. Tem um título principal em letras maiúsculas. E tem um texto de apoio, como uma chamada, ou seja lá como vocês queiram chamar isso. É aquela coisa no topo, tipo um rótulo esquisito. Tem fundos bege, que eu chamo de bege claw, bege claw.

03:58 E não é necessariamente um design ruim, certo? Mas acho que todos conseguem olhar para isso e dizer: “Bom, é claramente gerado por IA. É claramente uma porcaria”. E acontece que a porcaria é um alvo móvel. Talvez vocês achassem que porcaria era gradiente roxo, mas já passamos disso e chegamos ao bege claw. Certo, foi aqui que comecei. Comecei com um system prompt e uma oração, basicamente. Comecei a usar a skill de design frontend, como

04:32 muitos de vocês, e ela tem 55 linhas de instruções com exemplos. Sem scripts, sem roteamento, só prosa, certo? E você torce para dar certo. Às vezes dava certo, mas, na maioria das vezes, não. Por exemplo, vou ler alguns trechos. Talvez dê para ler bem, não sei. Mas, por exemplo, na skill de design de fontes, há frases como: “Nunca use a estética genérica de IA, fontes muito usadas como inter, robboto, arial e fontes do sistema; ou esquemas de cores clichês, especialmente gradientes roxos e fundos brancos.”

05:07 “Nunca acabe escolhendo opções comuns, como space grotesque, por exemplo.” Há dois problemas com essa abordagem. Primeiro, ela proíbe demais e, depois, uma proibição só leva o modelo ao próximo grupo de opções. Vou mostrar mais adiante por que isso é um problema. Você diz para ele não usar uma fonte, e ele simplesmente usa a próxima melhor que encontra no seu espaço latente. Então, isso não o torna mais criativo. É por isso que eu disse que a porcaria é um alvo móvel. Ele simplesmente escolhe a próxima melhor opção.

05:37 Aprendi essa lição do jeito difícil, porque, se vocês não perceberam, o motivo de termos começado a ver gradientes roxos foi o Tailwind. O tema padrão das páginas de exemplo do Tailwind era roxo. E, bem, anos antes disso, eu já tinha deixado a web laranja. Criei um framework chamado jQuery UI, e o primeiro tema padrão do jQuery UI era laranja. De uma hora para outra, a web ficou laranja — foi assim que chamei. Achei que as pessoas modificariam o tema, mas não modificaram. Então, aprendi a lição. Certo, a mediana é

06:13 a gravidade do modelo. Nem 250 linhas de prosa de skill artesanal, elaborada e linda conseguem mudar isso. Simplesmente não basta. Não ajuda o suficiente, certo? Está longe de ser suficiente. Aprendi isso do jeito difícil e espero que vocês não precisem passar pelo mesmo. Minha tese geral para esta palestra é que prompting é uma espécie de nível inicial, mas é no harness engineering que vocês devem chegar. Ao criar skills, devem mudar a forma de pensar. Devem pensar

06:45 nas skills da mesma forma que pensam no MCP como uma extensão do harness de programação, ou de qualquer harness que estejam usando. Não é só um prompt que você empacota; é algo além disso, ou, pelo menos, deveria ser pensado conceitualmente como algo além disso. É uma extensão do harness de quem estiver usando aquilo. E também oferece mais recursos do que apenas prompting. Quando comecei a pensar dessa forma, tudo se encaixou para mim. Prompting é um feitiço; harness é dominar a magia. Hoje vamos falar sobre nove artes ocultas

07:16 que aprendi durante o processo de criação do Impeccable. Vamos fazer subagents discutirem entre si. Vamos falar sobre como forçar divergência em vez de convergência, sobre roteamento como um modelo — provavelmente vocês já viram isso — e sobre como a maioria dos modelos modernos usa arquiteturas de mistura de especialistas, e Impeccable é criado como uma skill de mistura de especialistas. Vamos dar memória a eles. Vamos criar scripts que respondem de volta, e prometo

07:48 que isso vai fazer sentido. Hooks que rebatem, conectar o navegador em tempo real e usar mais recursos do harness. Compilar para todos os harnesses e projetar para o modelo mais fraco. Vamos começar. Número um: faça com que discutam. Se vocês estão criando algo como uma skill de crítica ou de revisão de código, há um problema enorme. Provavelmente notaram isso ao trabalhar com claw code ou Codex, não importa qual: se pedirem ao Codex ou ao claw code para revisar o próprio trabalho, geralmente ele vai avaliá-lo muito bem. É como se… quer dizer, eu já

08:24 construiu isso, fiz um ótimo trabalho, certo? É como corrigir a própria lição de casa. Não faz sentido, certo? Isso se ancora no que já criou. Isso não é nada bom. O que você pode fazer para resolver isso? Bem, pode fazer um modelo discutir com outro modelo, certo? Isso também se chama prompting adversarial. Então, você tem dois subagents, e eles nunca veem o trabalho um do outro. E é por isso que isso importa. No Impeccable, há um comando de crítica que realmente critica seu design. E

08:57 você pode direcioná-lo para sua landing page. Pode direcioná-lo para qualquer coisa. E há dois cenários específicos de falha. O primeiro — e é quase impossível de ler, então vou explicar — é uma página forte, certo? É uma página muito bonita, mas pode haver vários erros determinísticos. O Impeccable tem um mecanismo determinístico, um detector de design que consegue detectar coisas como contraste ruim e muitas fontes.

09:30 Talvez coisas que estejam perto demais da borda de um elemento. Então, ele detecta alguns problemas de acabamento, eu diria. Mas você pode ter um site realmente bonito, e então o detector é executado como parte da mesma skill e da mesma thread do modelo. O modelo vê a saída do detector e diz: “Bom, acho que há 500 problemas, então esse design deve ser ruim”. Esse é um caso. O outro é o oposto. O outro é uma página realmente péssima, ou talvez uma página vazia, mas não há

10:03 problemas detectados pelo detector determinístico. Então, o modelo pensa: “Não encontramos nenhum problema, então esse design deve ser ótimo”. Nenhum dos dois casos é bom. O que você quer — e é isso que a skill de crítica do Impeccable faz — é combinar duas coisas. Ela inicia dois subagents, e eles não têm acesso ao trabalho um do outro. É assim que se chega a uma crítica equilibrada. Então, o primeiro subagent

10:33 age como diretor de design. É um L&M que atua como diretor de design. Ele procura hierarquia, desleixo e heurísticas. E faz uma crítica como um humano faria, usando as ferramentas de navegador disponíveis. O segundo subagent executa o detector determinístico e também coleta evidências do navegador. Depois que chegam os resultados dos dois, a thread principal sintetiza ambos em uma única crítica, o que produz um resultado muito mais equilibrado. E antes de

11:06 continuar, percebi que ainda não mostrei onde fica o repo de exemplo. Então, vou abrir isso rapidinho. Se quiser clonar e tiver uma conexão de internet razoável, fique à vontade. Este é o PBA Aus/impeccable miners talks. A palestra está aqui, mas também há uma pasta dark arts com uma

11:37 pasta starter e uma pasta demos. A pasta demos tem uma página mediana bastante comum que você pode modificar. E, no starter kit, há o suficiente para criar uma espécie de Impeccable em miniatura, se quiser acompanhar ou experimentar por conta própria. Como parte disso, há também um tutorial aqui. Você vai acompanhar os pontos de verificação de dark arts e criar algo por conta própria. Eu sugeriria que você

12:08 saiba que, se gosta de fazer várias coisas ao mesmo tempo, ótimo. A propósito, você pode aplicar isso a qualquer coisa. Pode fazer uma revisão de código. Não precisa ser a skill de design. Mas eu queria ter algo para você experimentar. De volta aos slides. Duas opiniões sem viés são melhores do que um palpite confiante. Você pode usar isso, como eu já disse, para revisão de código e revisão de design, mas também para auditorias de segurança, que são um bom exemplo. Ou para criar um plano: uma crítica de RFC de um plano muito bom, em que vários LLMs como juízes discutem entre si até chegar a um bom resultado, ou para classificar saídas.

12:42 Agora, porém, há um problema. Codex, por que você não me deixa fazer isso? Isso é ruim. Acontece que, quando tentei isso pela primeira vez, o Codex nunca criou esses subagents. E fiquei batendo a cabeça na parede, pensando: “Por que será?”. Acontece que o Codex tem um modelo de permissões diferente do Claude Code e de outros harnesses. No Codex, o usuário precisa solicitar explicitamente

13:14 o uso de subagents para que qualquer coisa no harness use subagents. Então, se você estiver distribuindo uma skill, está sem sorte. A única maneira de fazer isso funcionar, até onde sei hoje, é dizer ao modelo: “Certo, se você tem recursos de subagents, mas não tem permissão, pare aqui e pergunte ao usuário”. E essa é basicamente a única maneira de fazer o Codex cumprir a instrução. Então, no Impeccable, se você vir algo que faça você pensar “hein?”,

13:47 provavelmente é por isso. Com todas as issues que as pessoas abriram e muitos testes da minha parte, parte desse conhecimento obscuro também foi incorporada às skills para que funcionem de verdade em diferentes harnesses. Por exemplo, aqui você vê um pseudocódigo de como isso funcionaria. E esta é outra coisa muito importante: muitas vezes, se o Codex percebe que pode se safar de alguma coisa, ele faz isso. Então, se não houver nenhuma penalidade por não iniciar subagents,

14:22 ele simplesmente não vai iniciá-los. É como se dissesse: “Bom, esse caminho é mais fácil. Vou por ele”. Então, o que você precisa dizer é: se não puder usar subagents, deve informar ao usuário que está oferecendo uma experiência inferior. O Codex detesta isso, então use a seu favor. Então, você pode vê-los discutindo. Não gravei um exemplo de verdade antes, porque pensei: “Vamos fazer ao vivo”. Então, vamos entrar no

14:56 Cursor e vou pedir uma crítica. Tomara que funcione. Não sei se o Composer inicia subagents bem o suficiente, mas vamos ver. Aliás, se você ainda não usou o Composer, é um modelo muito rápido e bem equilibrado

15:27 — é bem legal para trabalhos que você quer mostrar no palco, em particular. Certo, agora ele está fazendo alguma coisa. Acho que este repo tem uma versão antiga do Packable que não inicia agents. Entendi, essa é a parte ruim. Bem, talvez inicie.

16:01 Não tenho certeza se iniciou ou não, mas pelo menos quero mostrar o tipo de crítica que ele produz. Certo, agora está me fazendo várias perguntas sobre o que quero criar. Vou pular essa parte. E agora recebo uma crítica de design sobre o que está funcionando, quais são os problemas prioritários e os sinais de alerta para a persona. Agora, o

16:35 que eu queria mostrar de verdade, infelizmente, não apareceu nesta thread específica, mas podemos voltar a isso. Se você executar isso no Claude Code ou no Codex na versão mais recente, deverá ver com bastante clareza — no Claude Code, é muito fácil ver os subagents em execução e trabalhando. Ele inicia dois subagents, e você os vê trabalhando na parte inferior da thread do Claude Code. Certo, nível número dois: nosso ban só desloca o problema. Já falamos disso. Você aplica um ban e acaba entrando no espaço grotesco dos grafos de modelos.

17:06 Como resolver isso? Como forçar a divergência? Bem, um ban só move o modelo dentro do próprio cluster. O que criei para o Impeccable e para várias outras skills que lancei é algo que chamo de antiatrator. O antiatrator funciona criando uma espécie de semente aleatória. Ela pode vir da entrada do usuário ou de um script executado pelo modelo, que produz algo completamente inesperado para ele, porque é isso que você quer. E, neste caso,

17:40 Por exemplo, seria a seleção de fontes e, em vez de selecionar as opções seguras de fontes, a próxima etapa da previsão, ele foi para um espaço completamente diferente por meio de uma seed diferente. Há três técnicas, da mais fácil à mais difícil, que funcionam de maneiras diferentes. A primeira é algo que você pode fazer agora mesmo. É a mais simples: descartar as escolhas seguras. Basicamente, diga ao modelo: “Certo, diga suas três principais fontes”, e então o modelo

18:11 fica tipo: “Certo, tenho as três principais fontes”, e você diz: “Agora descarte-as.” E ele pergunta: “Mas por quê?”. Mas aí você basicamente descartou o próximo token previsto. Faça isso três vezes e então chegará a um espaço diferente, mais distante no espaço latente. Isso é possível, mas em algum momento ainda há convergência. Então, é uma técnica limitada. A segunda técnica é gerar muitas coisas diferentes e depois pedir a um sub

18:45 agent que as classifique. Fiz isso para uma biblioteca de shaders que criei, chamada radiant shaders, e o objetivo era criar cerca de cem shaders diferentes. O problema é que, toda vez que eu dizia “crie um novo shader” ou “crie ideias para dez novos shaders”, recebia as mesmas ideias repetidas. Resolvi isso de duas maneiras diferentes. Primeiro, criei algo inesperado, uma seed aleatória, uma seed criativa. Nesse caso, usei celebridades. Perguntei: “Como seria a Rihanna como shader?” ou “Como seria a Beyoncé como shader?” E

19:20 então o modelo dizia: “Deixe-me pensar nisso.” Essa foi a primeira coisa. Depois, pedi: “Gere cem dessas ideias” e, em seguida, criei um subagent para classificar todas elas. Isso é importante: precisa ser um subagent, porque ele não sabe nada do contexto anterior da sessão e pode, então, mudar completamente a ordem. A terceira técnica é criar uma seed aleatória com um script. Por exemplo, no Impeccable, quando você começa um projeto, ele chama um script chamado color.js. O color.js

19:55 tem mais de cem cores selecionadas manualmente. Não são paletas de cores completas, mas são cores primárias e funcionam como ponto de partida para uma paleta. O script lê essas cores, e então o modelo as usa como faísca criativa para criar uma paleta em torno delas para você. Você ainda pode dizer: “Não gosto disso.” Quer dizer, não gosto do que ele propôs, mas isso o leva em outra direção. Essas são algumas maneiras de criar divergência

20:25 e, quando você cria algo com o Impeccable, o mesmo briefing pode gerar resultados muito diferentes, dependendo das informações fornecidas pelo usuário, do script de cores que é executado e assim por diante. Fiz isso porque não queria que a internet inteira tivesse a mesma aparência de todo o resto. Número três: aqui está o problema. Se você coloca tudo em uma única skill, as coisas acabam se confundindo. O seguimento de instruções deixa de ser bom o bastante. Então, se você está criando uma skill de uso geral e vai expandindo, expandindo

20:56 e expandindo, em algum momento ela fica muito, muito confusa para o modelo. Aqui vai um exemplo concreto: a skill de design de frontend da Anthropic. A versão anterior — eles lançaram uma nova versão há três semanas — tinha uma linha que li antes e que dizia para evitar fontes do sistema. Isso faz sentido para o design de landing pages. Mas, para a interface de um produto, muitas vezes você quer que ela pareça o mais nativa possível. Então, as fontes do sistema são justamente o que você quer. Como resolver isso? Você pode dizer, quer dizer, pode

21:31 ter um enorme bloco de if/else em uma skill, dizendo: “Se o usuário quiser uma landing page, faça isto. Se quiser um produto, faça aquilo.” Mas isso fica muito complicado, desperdiça muitos tokens e, sinceramente, não funciona muito bem. O Impeccable começou como várias sub-skills diferentes e agora tem esse modelo de mistura de especialistas que faz o roteamento interno, inclusive em termos de recursos. Você pode chamar impeccable critique ou impeccable polish e um arquivo MD diferente é carregado nos bastidores para aquela tarefa específica. Então,

22:04 não é só um enorme arquivo MD de skill. Além disso — e isso é algo que muita gente não sabe —, nos bastidores, o Impeccable decide, com base no seu briefing e no que você informa, se você está tentando criar algo com foco em marca, como uma landing page ou algo que chame a atenção, ou se está criando o próprio produto. Então, ele muda de registro e carrega regras completamente diferentes para cada um, porque design de produto e design de marca são muito, muito diferentes. Isso também é algo que eu

22:37 recomendaria fazer ao criar algo de escopo maior. Isso funciona para skills grandes e com várias ferramentas, para skills com contexto sob demanda, para comportamentos específicos do público, toolkits de agent e coisas desse tipo. Número quatro: todo mundo começa do zero. Por padrão, as skills não têm memória de longo prazo. Elas não acumulam conhecimento ao longo do tempo, mas você pode fazer com que acumulem. Você tem uma pasta da skill e pode salvar coisas nela. Na verdade, no Claude, você tem até uma variável de ambiente que

23:09 aponta para o diretório em que pode salvar coisas, o que é bom. Acredito que nenhum outro harness oferece suporte a isso neste momento. Mas dá para contornar essa limitação. O Impeccable usa uma pasta impeccable na raiz do repo atual. Mas também é possível salvar coisas diretamente na pasta da skill. Talvez você possa pedir ao usuário que as ignore. Como isso funcionaria? Por exemplo, se você executar uma crítica no Impeccable, ela será salva como um arquivo nessa pasta e, por padrão, será ignorada pelo Git. Mas, se

23:45 mais tarde você disser: “Certo, acabei de executar uma crítica. Quero aprimorar minha página”, mesmo que faça isso em outra sessão, a skill usa aquela crítica anterior como sinal para entender o que descobrimos sobre a página. Ela pode consultar todas as críticas anteriores e observar a evolução da página. Por exemplo, em uma das críticas, você poderia dizer: “Não concordo com esta crítica. Não acho que você esteja certo e gosto mesmo das minhas fontes instrumentais.” Então, o modelo diria: “Certo, sem problema. Vou deixar isso anotado para depois.” E agora a skill é inteligente o bastante. Ela

24:20 criou contexto para entender: “Certo, essa é a preferência do usuário, então vou respeitá-la daqui em diante.” Engenharia cumulativa é um tema interessante também para skills. Você pode fazer com que elas levem em conta sessões anteriores usando essa técnica. Assim, as execuções se acumulam. Isso funciona muito bem para gradientes que podem ser retomados, agents retomáveis, acompanhamento do progresso, refatorações em várias sessões, migrações e coisas desse tipo. Por exemplo, uma das coisas que faço o tempo todo é refatorar meu código. E como faço isso? Com uma espécie de skill que se executa ao longo de várias sessões e trabalha em um arquivo por vez. Basicamente, digo: “Certo, aqui está seu arquivo TSX, ou o que for, para a sessão de hoje. Agora refatore tudo em torno deste arquivo e faça as conexões com ele.” E então ela vai acumulando contexto ao longo do tempo, até terminar a base de código inteira.

24:50 O que faço o tempo todo é refatorar meu código. E como faço isso? Com uma espécie de skill que se inicia em várias sessões e trabalha em um arquivo por vez. Então, basicamente, digo: “Certo, aqui está seu arquivo TSX, ou seja lá qual for, para a sessão de hoje. Agora refatore tudo ao redor deste arquivo e faça as ligações com ele.” E então ela vai acumulando contexto ao longo do tempo, até terminar completamente com toda a base de código.

25:22 Certo, número cinco. Regras enterradas acabam sendo ignoradas na leitura. Já falamos um pouco disso, mas quero destacar um aspecto um pouco diferente. Isso é especialmente relevante com modelos mais fracos. Se você está criando uma skill para si mesmo e só usa Opus ou só usa Codex, isso não é um problema tão grande, certo? Você sabe qual modelo está usando. Você sabe se funciona com o GPT-5.5, por exemplo. Para mim, está tudo bem, porque esse é o único modelo que uso. Mas, se você quer distribuir sua skill

25:56 para muitos usuários. É aí que as coisas ficam meio complicadas, porque alguns desses usuários podem estar usando isso. Alguns podem estar usando Haiku. Alguns podem estar usando Grock. Não sei. Alguns podem estar usando Gemini. Nunca se sabe. Às vezes conheço alguém que usa. Mas, na verdade, é aí que fica complicado, certo? Porque você precisa desenvolver para o mínimo denominador comum e, idealmente, para o modelo mais fraco em termos de

26:30 seguimento de instruções. Por exemplo, o GPD5 mini não é muito bom em seguir regras. Há coisas até no Impeccable que não funcionam com o GPD5 mini. Ele consistentemente não carrega certos arquivos MD que eu esperava que carregasse; consistentemente, não inicia o modo de vida. Então, há limites para o seguimento de instruções entre esses modelos, e isso fica especialmente ruim com skills mais longas, que têm muitas regras. Então, como contornar isso? Bem, o Impeccable é, de certa forma, biônico. Ele realmente

27:04 não é só prosa. É uma combinação de scripts que são executados em linha dentro da skill em determinados momentos. E, em seguida, há prosa ao redor deles. Por exemplo, toda vez que você chama o Impeccable, ele executa um arquivo chamado context.MJS. O context.MJS faz algumas coisas. A primeira é: se houver um product.MD — o do Impeccable —, que é quase como um design.MD, mas voltado à estratégia de produto. Ele ajuda a entender quem é o público-alvo ou o que você quer alcançar com aquilo, o que muitas vezes é mais importante

27:38 em uma entrevista de design do que, sabe, quão arredondadas você quer que sejam as bordas. Mas ele oferece suporte aos dois. Dá suporte a product.MD e design.MD e, por padrão, o context.MJS reúne esses arquivos e os envia para a sessão. Isso não é empolgante. Mas, quando esses arquivos não estão disponíveis, ele dá ao skill um JSON estruturado e diz: “A propósito, não há product.MD, e é exatamente isso que você deve fazer a respeito.” Ou

28:10 aqui vai outra coisa que o context.MJS faz: ele atualiza o próprio Impeccable quando há uma nova versão, agora com a sua permissão. Então, ele vai perguntar, mas vai dizer: “Ei, a propósito, há uma atualização disponível para a skill Impeccable, e aqui está o que você deve fazer para perguntar ao usuário se ele quer atualizar o Impeccable.” Então, ele faz muitas coisas ao mesmo tempo e sempre diz ao modelo exatamente o que fazer em seguida. E o mais interessante nisso é que descobri que isso funciona significativamente melhor do que alguma regra aleatória

28:43 na prosa do escopo principal. Quando você envia algo pelo valor de saída, pela saída padrão de um script, de alguma forma o modelo segue isso muito mais do que antes. Isso pode permitir uma configuração ciente do ambiente, integração dinâmica, controle com base no estado do repo, fluxos adaptativos, qualquer coisa, na verdade. Antes de encerrar esta sessão, uma das desvantagens dessa técnica, algo que é importante ter em mente, é o cache de prompt. Isso funciona super

29:16 bem para manter uma skill, por assim dizer, seguindo na direção certa em termos de seguimento de instruções, mas isso acontece às custas do cache de prompt. Se você precisa de cache de prompt, se executa a skill muitas e muitas vezes e quer que tudo fique em cache, esta não é uma boa técnica. Mas achei muito útil em cenários realmente interativos. Certo, número seis: hooks que revidam. É

29:46 algo que disponibilizei há pouco tempo e de que gosto muito. Quero mostrar o que quero dizer com isso. Muita gente tem o Impeccable nos sistemas, mas às vezes se esquece de executá-lo. Às vezes, pensa: “Não sei”. Quer dizer, o Codex é bem bom. Alguns harnesses são bem bons em chamar consistentemente a skill certa. Mas, como agora ele vem agrupado como uma única skill, muitas vezes os harnesses

30:16 se esquecem de simplesmente chamar o Impeccable quando você não o menciona explicitamente. Então, você está criando algum código de frontend e talvez ele não siga seu sistema de design ou algo assim. Isso pode ser resolvido com hooks. Quem já usou hooks no Claude Code ou no Codex? Algumas pessoas. Legal. A skill que criei aqui, o Impeccable, vem com hooks de design. Então, basicamente, criei um linter de design que é executado

30:46 em segundo plano e vem junto com a skill. Quando você instala o Impeccable, esses hooks são instalados no Claude Code, no Cursor, no Codex e no GitHub Copilot, e mantêm o modelo exatamente onde ele precisa estar. Então, os hooks chegam até você. É uma proteção que é acionada a cada edição. E há algumas diferenças entre os vários provedores. A sintaxe dos hooks para Codex e Claude Code não é a mesma.

31:20 E o comportamento também não é o mesmo. Por exemplo, descobrimos que, com modelos mais fracos, um pouco mais fracos, como o Composer e o Cursor, é melhor usar um hook pre-tool use, que impede a escrita do código, em vez de um hook post-tool use. O post-tool use acontece logo depois que o agent, por exemplo, escreveu um arquivo. Então, ele avisa: “Ei, a propósito, o contraste dessas cores está ruim” ou “há um gradiente roxo aqui”. Aí, idealmente, o modelo é inteligente o bastante para corrigir isso. Alguns

31:54 modelos não seguem muito bem essas instruções. Então, se você usar um hook pre-tool use, estará impedindo ativamente que o arquivo seja escrito desde o início. É uma abordagem bem mais incisiva, mas precisamos fazer isso para certos modelos e certos harnesses. Isso é bom, e melhor ainda é que você pode personalizá-lo para seu sistema de design e seu caso de uso, ou, digamos, se o usar para code reviews. Você pode personalizá-lo com suas próprias regras do ESLint, suas próprias diretrizes de sintaxe sintéticas etc.

32:26 e expandi-lo a partir daí. Proteções passivas são melhores do que um comando que ninguém se lembra de executar. Essas são proteções passivas que sempre mantêm você no caminho certo, na direção certa. Mais uma vez, isso funciona para linting e formatação. É claro que, se você usa o Claude Code ou o Codex, eles já usam alguns linters para coisas como formatação de sintaxe, mas linting de design é um jogo completamente diferente.

32:57 Mas eu realmente recomendo que você experimente hooks em combinação com uma skill e pense: “Certo, minha skill faz isto; como posso criar um ciclo de feedback, um ciclo de validação que use hooks para realmente me manter no caminho certo?” É difícil mostrar hooks em ação, mas, se você conseguir ver isto, é mais ou menos assim que aconteceria em um agent. Por exemplo,

33:27 neste caso, eu usaria, digamos, o Gemini. O Gemini faz isso o tempo todo. O Gemini cria animações em imagens sem parar. Ele anima qualquer imagem e geralmente aplica um efeito de zoom ao passar o cursor. Adora fazer isso. E o Impeccable sinaliza esse comportamento. Neste caso, o hook seria acionado silenciosamente; normalmente é por isso que criei esta demonstração falsa, porque geralmente você não consegue vê-lo. Então, ele diria ao modelo: “Ei, a propósito, houve uma violação.”

33:58 A experiência é que muitas vezes você não precisa fazer nada. O modelo simplesmente corrige o rumo e se ajusta. Uma coisa importante: se você fizer isso e disponibilizar para usuários, é muito importante incluir um jeito de criar regras de exceção ou algo assim, porque esses hooks muitas vezes também geram falsos positivos, e você precisa de um jeito de configurá-los. Caso contrário, ficam irritantes muito rapidamente. O Impeccable vem com esses hooks de design, que permitem criar regras de exceção por arquivo dentro de um

34:30 Regra de CSS. Então, há muitos níveis granulares para excluir determinados arquivos, por exemplo. Certo, nível sete. Agora, não dá para ajustar pixels de verdade por uma caixa de chat. Isso talvez não seja relevante se você não estiver criando uma skill de design, mas acho que a ideia geral é relevante. Então, se você pensar em uma skill como engenharia de harness em vez de prompting, deve pensar no harness como um todo, certo? Você está usando o Claude Code, por exemplo, ou está usando o Codex

35:02 ou está usando o GitHub Copilot. Quais recursos desse harness você pode aproveitar para criar a melhor experiência de usuário para o seu caso de uso? Essa é a pergunta que você deve se fazer. Por exemplo, o Codex para desktop agora tem um navegador dentro do próprio aplicativo. Você consegue usar esse navegador de maneiras interessantes? Consegue usar a ferramenta de captura de tela do navegador de maneiras interessantes? No meu caso, eu

35:33 consegui. Percebi que provavelmente havia uma maneira de conectar o navegador do aplicativo, iniciar o servidor de desenvolvimento e simplesmente carregar a página nele, e então conectá-lo de algum modo à thread principal. Assim, posso permitir que o usuário faça iterações visuais nessa página, em vez de no chat. E, no Impeccable, isso não usa MCP. É

36:03 simplesmente iniciar um pequeno servidor poller ao vivo, que aguarda uma entrada e insere um trecho no seu servidor de desenvolvimento. Depois, quando você faz algo na página, ela envia um evento de volta para aquele poller usando eventos enviados pelo servidor. E esta é, acho, a parte engenhosa, talvez, ou a parte que faz tudo funcionar: o poller então para. O poller encerra a si mesmo. Há uma mensagem na saída padrão. Já falamos sobre a saída padrão, certo? O valor de saída dessa coisa. E o modelo lê essa mensagem e percebe: “Ah, aconteceu algo, preciso fazer alguma coisa.” Então, nesse caso, na própria skill, dou instruções sobre como lidar com esse evento. Digo algo como: “Bem, se esse evento chegar, você provavelmente deve criar um design para esta seção específica da página e depois enviá-lo de volta para este poller, para que apareça do lado do usuário.” E assim há uma conexão direta entre um recurso do harness e outro recurso do harness

36:36 do harness. Então, a thread do chat e o navegador do aplicativo. E é assim que isso fica em um diagrama. Mas acho que a melhor maneira de experimentar é ver. Então, vou mostrar. Certo, Cursor. Acho que já estou no modo ao vivo. Certo. Então,

37:10 já iniciei o modo ao vivo. Agora estou no modo de seleção. Vejo esta barrinha aqui embaixo. Como vocês podem ver, posso selecionar qualquer coisa nesta página. Agora aparece esta pequena barra sobreposta, e posso selecionar vários subcomandos dentro da skill. Basicamente, eles correspondem a arquivos MD dentro da skill. Posso selecionar a quantidade de variações que quero. Depois, posso clicar em “Ir”. E agora, aqui na thread, vocês podem ver que ele

37:42 captou o sinal na thread principal porque o poller parou, e agora sabe, espero, exatamente o que precisa fazer: primeiro, envolver este elemento em uma tag especial. Depois, sabe como criar variações marcadas de uma maneira especial com CSS. E agora fez isso. Como podem ver, a coisa foi atualizada imediatamente. Agora tenho estas três variações e posso passar por elas

38:14 e, se eu gostar de uma, posso clicar em “Aceitar” e aceitá-la. Se eu não gostar de uma delas, aperto Escape e volto ao modo normal. Isso mostra como aproveitar um recurso do harness de maneira eficaz para um espaço de problema — neste caso, design. Também dá para inserir elementos com isso e clicar em qualquer coisa aqui. Dá para desenhar por cima e deixar comentários. Se quiser, pode adicionar anotações. Pode ditar e orientar a página inteira simplesmente escrevendo aqui; depois, isso volta para o agent principal e se torna um sinal de orientação para a página inteira.

38:46 E também dá para visualizar muitas coisas dessa maneira. Talvez vocês tenham lido a publicação no blog do Tariq sobre como HTML é uma maneira muito legal de se comunicar, em vez de Markdown. Concordo, e também acho que design MD fica muito melhor visualizado como HTML. Neste caso, vocês veem o design MD deste site, que não é lá essas coisas e serve apenas para demonstração. Mas também podem usar isso a seu favor se assumirem o controle do navegador do aplicativo e o usarem a seu favor. É assim que faço uso dele. Certo, número oito: “Funcionou na minha máquina”.

39:22 Bem, todo desenvolvedor aqui conhece esse problema. Isso pega muito quando você distribui uma skill. Muitas vezes vi esse argumento no X: “Cara, é só criar um link simbólico, sabe, um link simbólico para a nuvem, e todos os seus problemas vão desaparecer.” Bem, isso é ótimo se você estiver criando uma skill simples para uso próprio. Nesse caso, pode fazer isso à vontade, certo? Crie um link simbólico de CLAUDE.md para AGENTS.md. Incrível. Crie links simbólicos para tudo. Mas não é uma boa ideia se você está tentando distribuir uma skill para muitos usuários, porque, como acabamos de falar, esses harnesses têm muitas diferenças. Vou falar de mais diferenças. Sei que é irritante, porque seria ótimo simular essas coisas, mas, infelizmente, não vivemos nesse mundo. E, infelizmente, a Anthropic ainda não adotou AGENTS.md. Então, quais são as diferenças concretas? Por exemplo, já falamos de subagents. Falamos de como, por um lado positivo, eles têm amplo suporte. Mas quem pode iniciar um é muito diferente. No Claude, você pode fazer isso de forma programática com muita facilidade. O Codex precisa do usuário. No Cursor, na maioria das vezes, o agent escolhe. Então, há diferenças claras

39:57 também quando você quer predefinir esses agents: o Codex tem uma sintaxe diferente para isso da usada pelo Claude e pelo Cursor, entre outros. Outra coisa é a ferramenta para perguntar ao usuário. Uma das ferramentas mais legais do harness do Claude Code é a ferramenta de perguntas ao usuário. É uma ferramenta muito boa para fazer uma pergunta ao usuário, certo? Ela abre um menu e diz algo como: “Ei, o que você gostaria de fazer?”, e então você escolhe uma opção. Acontece que o Codex tem uma ferramenta

40:28 assim. Essa é a boa notícia. A má notícia é que essa ferramenta só está disponível no modo de planejamento. Então, de novo, há grandes diferenças na maneira como essas coisas funcionam. E o que isso significa? Significa que, se você não estiver executando o Codex no modo de planejamento, mas sua skill quiser fazer perguntas, na maioria das vezes ela simplesmente não faz. Ela simplesmente infere a partir do contexto atual e não faz nenhuma pergunta ao usuário. Isso não é muito bom. Então, há muitas frases na skill Impeccable que dizem especificamente: se você estiver no Codex, precisa parar

40:59 e fazer perguntas. Não, você não é inteligente o suficiente para inferir o contexto. Então, se você vir frases assim, é por isso. Outra coisa são as tarefas em segundo plano. E há algo que você só aprende do jeito difícil fazendo isso. Por exemplo, esse modo ao vivo que acabei de mostrar inicia uma tarefa em segundo plano. Ou seja, executa um shell em uma tarefa em segundo plano. Isso é legal porque você pode continuar usando a sessão e, quando a tarefa em segundo plano termina, o modelo é ativado automaticamente e recebe a mensagem de volta

41:33 Também há diferenças se você quiser predefinir esses agents: o Codex tem uma sintaxe diferente para isso, em comparação com o Claude, o Cursor etc. Outra ferramenta é a de perguntar ao usuário. Uma das ferramentas mais legais do harness do Claude Code é a ferramenta de fazer perguntas ao usuário. É uma ferramenta muito útil que você pode usar para fazer uma pergunta ao usuário, certo? Ela abre um menu, dizendo algo como: “O que você gostaria de fazer?”, e então você escolhe uma opção. Bem, acontece que o Codex tem uma

42:04 ferramenta assim. Essa é a boa notícia. A má notícia é que essa ferramenta só está disponível no modo de planejamento. Então, mais uma vez, há grandes diferenças entre como essas coisas funcionam. E o que isso significa? Significa que, se você não estiver usando o Codex no modo de planejamento, mas sua skill quiser fazer perguntas, na maioria das vezes ela simplesmente não vai fazer isso. Ela vai simplesmente inferir a partir do contexto atual e não fará perguntas ao usuário. O que não é muito bom. Por isso, há várias frases na skill Impeccable que dizem especificamente que, se você estiver usando o Codex, precisa parar

42:38 e fazer perguntas. Não, você não é inteligente o bastante para inferir o contexto. Então, se você vir frases como essa, é por isso. Outra coisa são as tarefas em segundo plano. E isso também é algo que você aprende na marra ao fazer isso. Por exemplo, esse modo ao vivo que acabei de mostrar inicia uma tarefa em segundo plano. Ou seja, executa um shell em uma tarefa em segundo plano. Isso é legal porque você pode continuar usando a sessão e, quando a tarefa em segundo plano termina, o modelo é reativado automaticamente e recebe a mensagem de volta.

43:11 e então consegue fazer alguma coisa e reagir a ela. O Codex e outros harnesses não reagem quando uma tarefa em segundo plano termina. Você precisa dizer manualmente: “Ah, a propósito, pode dar uma olhada no que essa tarefa em segundo plano fez?”. E isso não é muito bom, certo, se você está fazendo uma automação como essa. Então há diferenças na forma como essas tarefas são iniciadas e em como funcionam. Por isso, se você estiver usando o modo ao vivo no Cursor ou no Codex, ele cria uma tarefa em primeiro plano e mantém a conversa atual bloqueada. Não é

43:43 o ideal, mas faz a coisa funcionar de verdade. Então há diferenças sutis na forma como essas tarefas são iniciadas. Os watchers são outro exemplo. O Tail Watch existe agora. Isso é muito legal. A maioria dos harnesses tem uma forma de observar, por exemplo, um arquivo de log. Mas eles são limitados com muito mais rigor do que simplesmente iniciar uma tarefa em segundo plano. Já falamos dos hooks de edição. Eles são diferentes, então há muitas, muitas diferenças de comportamento, mas também há diferenças entre os modelos. Por exemplo, no meu caso,

44:14 todos têm tendências diferentes na maneira como são superajustados. Por exemplo, o Gemini — já mencionei isso — adora animar imagens. Simplesmente adora. Você precisa dizer para ele não animar as imagens se não quiser um efeito de hover em cada imagem. Não importa onde ela esteja. Ele adora. O Codex adora espaçamento ruim entre as letras. Não sei por quê, mas adora. O Codex também adora bordas extremamente arredondadas. Ele vai arredondar qualquer coisa que você imaginar. Ele

44:44 adora isso. Não importa se é o site de um hospital ou de uma escola infantil. Ele também adora bordas finíssimas. E há tendências específicas que são únicas para cada modelo. E isso não vale só para design. Vale para arquitetura. Vale para arquitetura de código. Vale para os pacotes npm preferidos. Cada modelo é superajustado de maneiras diferentes. Descobrir como superajustá-lo geralmente acontece por acidente. No meu caso, tenho um harness de evals bastante abrangente que executo nos bastidores. Na verdade, cada linha do Impeccable passa por testes de ablação.

45:16 Então testo cada linha e vejo o que ela faz em todos os modelos. Não espero que vocês façam isso, mas é muito bom saber que os modelos são diferentes e seguem as instruções de maneiras diferentes, e que o comportamento do harness também é diferente. Então, o que o Impeccable faz é criar versões específicas para cada harness e cada modelo. Talvez vocês não precisem ir tão longe para os próprios fins, mas eu só queria mostrar

45:48 até onde é possível chegar com isso. Por exemplo, ele tem uma variável de substituição que escolhe a ferramenta certa para a pergunta do usuário, dependendo do harness, ou tem esses blocos XML para o Gemini, para o Codex etc. Eles inserem regras específicas para evitar o superajuste para os modelos em questão. Porque, como se vê, se você disser ao Claude para não exagerar no espaçamento entre letras, ele vai espaçar as letras exatamente na direção oposta. Então, não dá para simplesmente incluir tudo na

46:19 mesma skill. E é por isso que, se você instrumentar o suficiente dessa maneira, consegue chegar a uma skill que funciona em todos eles, pronta para ser distribuída de uma só vez. Dá bastante trabalho, mas compensa e permite criar imagens bonitas como esta. Agora, o único outro problema é que os métodos de instalação típicos, como o npx skills, por exemplo, se você estiver usando o npx skills, não respeitam

46:50 diretórios diferentes para harnesses diferentes. Eles simplesmente pegam o primeiro diretório e depois o copiam ou criam um link simbólico para ele em todo tipo de pasta. Por isso, se você acessar o site do Impeccable, verá que criei minha própria CLI para resolver esse problema. É por isso que ele não usa o npx skills. Acho que o comitê ainda não chegou ao ponto de aceitar essa ideia, e isso é irritante. Eu entendo. É irritante compilar para harnesses diferentes, mas achei que valia a pena. Por fim, de novo: desenvolva para o menor denominador comum. Um modelo mais fraco pode ter opiniões, tudo bem, mas o que lhe falta é disciplina para seguir as suas.

47:24 Então, por exemplo, o Codex — e especificamente o GPT — adora a palavra “gate”. Se você já criou uma skill no Codex, sabe que ele adora gates. Sempre que você diz: “Ei, por que não seguiu estas instruções?”, ele responde: “Bem, acho que precisamos de um gate”. Então dei a ele o que mais gosta: gates. Mas só faço isso para o Codex. Há um arquivo Codex.md que é carregado na hora

47:57 para o Codex e para o GPT, e aí ele segue algo como: “Certo, aqui estão seus oito gates. Você precisa passar por todos eles e não pode comprimi-los”. Isso é muito importante, porque ele também adora comprimir essas instruções. Dá só uma olhada rápida e diz: “Bem, acho que faço o um, o dois e o cinco, e pronto”. Então, a solução é fazer com que ele registre o resultado de cada gate e diga: “Acabei de passar pelo gate um. Ótimo, sucesso”.

48:31 E a lição mais importante disso é: se for possível pular um gate, ele será pulado. Já mencionei isso antes, certo? Se o modelo puder escapar de uma situação difícil, com certeza vai fazer isso. Ele não vai fazer tudo o que precisa para concluir o resultado final. Então, tome cuidado e torne isso impossível de pular. Acabamos de criar uma extensão de harness. Fomos de escrever prompts a construir um monstro. Mas acho

49:03 que, no meu caso, acabou sendo bastante poderoso, e eu queria compartilhar o que aprendi no caminho. Não espero que vocês usem todas essas técnicas. Algumas delas são bem exóticas e talvez não se apliquem a todos os casos de uso. Mas espero que encontrem valor em alguns dos conselhos que dei hoje. Então, fizemos várias coisas hoje. Nove coisas que um prompt não consegue fazer. Tornamos tudo muito mais determinístico e, por isso, melhoramos o Impeccable. Se quiserem experimentar por conta própria,

49:37 mais uma vez, vocês podem clonar o repositório desta palestra. Podem clonar o impeccable-talks. Mas, claro, também é útil dar uma olhada na skill em si e ver como ela foi construída. O projeto é totalmente open source, sob a licença Apache 2. Vocês podem instalar com npx impeccable skills install. E conferir o código-fonte no GitHub. Com isso, cheguei ao fim. Obrigado. >> [aplausos]

50:12 >> E agora acho que temos cerca de 10 minutos para as perguntas que vocês tiverem. >> Alguém tem alguma pergunta? >> Sim. >> Ah, desculpe. O que foi? >> Um link >> para o repositório. Sim. É difícil de ver, mas [música] deixa eu colocar aqui. Este é o repositório

50:44 das palestras. Sim. >> Ótimo. Minha pergunta era: você mencionou que… >> Sim, a pergunta é: mencionei que isso quebra o cache de prompt. O truque, a técnica para obter algo de volta de um script dentro de uma skill. E o motivo é que o resultado é dinâmico, certo?

51:19 Pode ser qualquer coisa. Então, a menos que o resultado seja sempre o mesmo, é uma execução dinâmica de shell. Ele é inserido na conversa. Agora, para ser justo, a skill ainda fica em cache. A skill continua em cache, mas acho que estou diferenciando a skill com conteúdo estático embutido da skill com uma instrução dinâmica para chamar algo. Então, essa parte não fica em cache. Sim, esse era o meu ponto principal. >> Sim.

51:52 >> Sim. >> Sim. Qual é o processo para avaliar e iterar nessa skill? O processo é bem trabalhoso. Deixa eu ver se consigo mostrar isso na tela. Certo, aqui está. Então, aqui vai uma amostra. Ah, não. Certo, fechei a…

52:28 servidor. Tudo bem. Certo. Vou só narrar por cima. Então, sim, mencionei que criei um harness de evals e, por isso, criei um harness para mim que recria de perto as condições e as ferramentas de todos os harnesses com que me importo. Por exemplo, ele usa o SDK do Claude Code. Sim. Desculpem, pessoal, vocês podem abaixar um pouco o volume? É que as pessoas ainda estão tentando ouvir as perguntas. Obrigado.

53:00 Então, como eu testo isso? Como eu construo isso? É uma combinação. Primeiro, o Impeccable tem muitos testes de ponta a ponta no repo. São testes conduzidos por LLM, assim como testes de ponta a ponta com Playwright. Essa é uma parte, útil para coisas como testar os scripts do modo ao vivo, por exemplo. Mas, além disso, como testo se realmente funciona? Bem, criei um harness de evals. Ele ainda não é open source.

53:32 Mas criei um harness de evals que replica de perto todos os harnesses de modelos com que me importo no momento. Especificamente, Claude Code e Gemini, e estou tentando expandir para mais. Ele também recria as ferramentas, como, por exemplo, ferramentas de captura de tela do navegador, ou algo nessa linha. E também recria o fato de que algumas partes do Impeccable são interativas. Durante a inicialização do Impeccable, muitas vezes…

54:03 …o usuário é perguntado: “Como você gostaria que sua página não parecesse?” E aí há essas interações de ida e volta. Então, criei um LLM que atua como usuário diante do outro LLM. Assim, ele faz uma troca interativa, de ida e volta. Criei esse harness e, depois, criei uma combinação de especialistas em design que atuam como avaliadores. Basicamente, dou olhos para ele avaliar cada resultado. Aí posso executar testes em 20 nichos diferentes, como, por exemplo, restaurantes italianos.

54:38 Executo testes com todos os modelos com que me importo, GPT-5.5, Opus, Sonnet, e faço de cinco a dez testes com cada um deles, para cada versão da skill, para ver como as coisas mudaram. Também testo contra concorrentes. Por exemplo, testo contra a skill de design de frontend para ver se faz diferença e se melhora ou piora as coisas. Além disso, faço testes de ablação, que são mais difíceis e mais caros, eu diria.

55:09 Então, não recomendo isso para todo mundo, mas, nos testes de ablação, como vocês vão ver no código-fonte do Impeccable, cada regra tem uma tag XML com um identificador único daquela linha específica. O harness usa isso para fazer um teste em que remove a linha, executa as evals com todos os modelos, depois adiciona a linha de volta e usa o mecanismo de detecção determinístico do Impeccable para ver se houve alguma mudança. Certo? Então, se houver uma…

55:42 …linha que diga: “Ei, não use cinza sobre fundos coloridos, por questão de contraste”, há um teste de ablação e, depois, uma verificação determinística ou um ciclo de feedback que a testa. Resumindo, é bem elaborado, mas, no começo, era baseado em feeling e agora é realmente bem testado. Sim. >> Isso mesmo. Pode continuar.

56:15 Desculpe. >> Você configurou isso para avaliar o gosto? >> Sim. >> Sim. Tenho evals para avaliar o gosto, mas não acho que funcionem particularmente bem. Acabei de conversar sobre isso com Ben, da Contra. Não acho — sei que alguns dos meus colegas talvez discordem —, mas não acho que seja possível resolver o gosto no nível do modelo. Na verdade, acho que é…

56:45 …algo fundamentalmente humano, porque o gosto é escasso e único. Quando todo mundo usa o mesmo gosto, ele se torna onipresente e, então, deixamos de considerá-lo refinado. Acho que é algo difícil. Também acho que os modelos são particularmente ruins em avaliar o gosto. Por exemplo, há certas coisas que os modelos conseguem avaliar bem, como: “O elemento correto está na primeira tela?” Coisas funcionais, que funcionam. Mas o que não funciona? Aqui vai um exemplo: de novo, criei…

57:20 …essa combinação de avaliadores, e um deles dá uma nota para dizer se a primeira tela está ótima e se é eficaz. Um dos sinais é que, por exemplo, o Gemini dá uma nota mais alta quanto mais coisas houver na primeira tela. Isso é uma regra geral. Se você simplesmente encher a tela de coisas, ele dá uma nota mais alta. É um exemplo interessante de como os modelos costumam ser maximalistas, certo? Eles acham que mais…

57:52 …é mais, eu acho. Então, muitas vezes crio avaliadores que, na verdade, invertem a resposta do modelo. É muito estranho, mas funciona. O modelo dá uma nota muito alta para algo, e eu penso: “Certo, isso definitivamente não é um bom design.” Enfim, não acho que isso esteja resolvido nem que possa ser resolvido, mas tenho uma ferramenta que, eu diria, dá a você os olhos de um diretor de design e funciona um pouco melhor do que o acaso. Para mim, isso já basta como primeira avaliação. Depois, uso meus próprios olhos humanos…

58:24 …para avaliar os resultados e anotá-los. Mais alguma pergunta? Sim, ali. >> O que você acha que o futuro reserva para as skills? >> O futuro das skills. Essa é uma pergunta ampla. Sim. >> Sim. Vou responder primeiro sobre o Impeccable e sobre mim. Então, no caso do…

58:57 Impeccable, acho que estamos definitivamente ultrapassando os limites da plataforma de skills, em termos do que é possível fazer com skills. O modo ao vivo é um bom exemplo disso. O modo ao vivo foi meio que um experimento de Jurassic Park para ver se eu conseguia fazer isso. E a resposta é sim. Acho que está funcionando melhor do que eu esperava, mas ainda tem muitos problemas. Seria muito melhor fazer isso numa integração de primeira parte com um harness, ou como uma ferramenta de primeira parte. Então, acho que há limites…

59:30 …que estou alcançando, nos quais as skills talvez já não sejam eficazes. De modo geral, acho que a maioria das skills provavelmente deveria ser escrita pelos próprios usuários. Acho que quem se dá ao trabalho de empacotar uma skill e compartilhá-la com outras pessoas precisa investir mais tempo do que investe atualmente. Esse é, então, meu ponto de vista controverso. Tenho visto muitas skills distribuídas que não funcionam bem num modelo que o autor não usou, por exemplo. Então, acho que…

1:00:04 …precisamos elevar o padrão do que é aceitável lançar para as pessoas. Isso é aquela história do “funciona na minha máquina”. Eu preferiria ver menos skills no ecossistema, mas que fossem realmente testadas em condições reais e comprovadas. Espero que estejamos caminhando nessa direção, porque, no momento, é meio que uma terra sem lei. >> Sim. Pode continuar. Não há um jeito de testar tudo.

1:00:37 >> Não há um jeito comum de testar as skills. >> Sim. E isso pode ser uma oportunidade. É um bom ponto. Acho que tenho uma ferramenta para isso, na verdade. É verdade. [risos] Sim, eu poderia fazer algo com ela. No momento, foi criada exclusivamente para os meus próprios fins, mas o mesmo vale, por exemplo, para o instalador e o compilador do Impeccable. Acho que a maioria das pessoas não sabe que eles existem, que podem compilar para qualquer harness e que usam essas técnicas de substituição e coisas do tipo. Eu provavelmente também poderia lançá-los como ferramentas independentes. Sim, é um bom ponto.

1:01:07 >> Sim, pode continuar. O MCP tendo skills no servidor. Como isso funcionaria? >> Ah, entendi. Sim. Para ser sincero, ainda não experimentei isso. Também não cheguei a ler muito sobre o assunto. Acho que, de modo geral, o MCP…

1:01:37 Sabe, eu me preocupo muito com a poluição do contexto, e faço isso também com skills. Acho que não uso muito MCP por esse motivo: ele poluiu meu contexto muitas vezes. Como as skills funcionam no MCP? Ah, você pode baixar uma skill de um servidor MCP. Sim. Certo.

1:02:20 >> Sim. >> Sim. Sim. Sim. >> Então, qual é a forma recomendada de empacotá-las e distribuí-las? Sim. É um assunto muito, muito bom. Bem, claro, os harnesses e os laboratórios de ponta têm suas próprias formas de fazer isso. Quer dizer, o Codex tem um marketplace que você pode usar para distribuir: um marketplace de plugins. O Claude Code também tem um marketplace. Acho que começaram com a abordagem de marketplace. Esses marketplaces não funcionam muito bem. Quer dizer, o do Claude Code com certeza não funciona muito bem.

1:02:53 Sei disso por experiência própria, porque o mecanismo de atualização muitas vezes não funciona, e as pessoas dizem: “Bem, minha skill não atualiza”. Muitas vezes, o problema é de cache. Então, minha experiência com os métodos nativos de distribuição tem sido irregular e, claro, eles só funcionam com aquele provedor específico. É por isso que existem projetos como o skills.sh. Mas, de novo, o problema com as skills do MPX agora é que elas não permitem casos de uso de skills mais avançados, como, sabe, compilar para cada

1:03:25 harness diferente. Tenho um pull request no repositório. Já chamei a atenção de Andrew algumas vezes para isso, mas ele ainda precisa fazer o merge ou concordar comigo, eu acho. Acho que ainda estamos discutindo. Mas, sim, acho que o MPX skills é um ótimo projeto no geral. Seria ótimo se pudéssemos, de certa forma, adotar isso como padrão. Também há um projeto da Microsoft tentando fazer isso. Um projeto da

1:03:56 Microsoft. Esqueci o nome. Mas com certeza ainda não existe um padrão da indústria para distribuição. Sim, não gosto muito de ter que manter meu próprio instalador de CLI. Preferia não ter que fazer isso. É irritante. Mas isso garante que funcione com segurança em todos os harnesses instalados, com os hooks na parte certa do sistema, etc. Então… Sim. Sim. Certo. Acho que já passei muito do meu tempo, mas venham falar comigo se quiserem.

1:04:27 Sim, eu diria que vou encerrar por aqui, mas venham falar comigo se quiserem. Deixe-me só… Obrigado. [aplausos] >> [música]

Transcrição original

[00:13] Hello everybody. How’s it going? Okay, I think we still have some people trickling in, but I’m super excited to be here. Okay, first off, let me reload these slides because my claw code was still building something on it. Um, okay. So, the contrast is a little bit low. Um, so please bear with me. I’m

[00:44] going to try to cover uh what you cannot read as much as possible. Uh, I also have heard that the Wi-Fi is not the strongest. So um while it is a workshop uh hopefully you just do take away a lot of the lessons um and then can apply it whenever you want to. Um but I do have a sample repo if you want to follow along. Um okay first of all hi my name is Paul. Um I’m really glad you found your way into this room. Um I’m the author of Impeccable. Who here has used Impeccable

[01:16] by any chance? Can I see some hands? Okay, a few people. Nice. Um, so for those of you who have not used Impeccable, Impeccable is a skill that I’ve built for myself mainly. Um, I’ve built this large enterprise app uh over the last year and it has like lots of different views, states, whatever. Um, and I wanted to design really quickly with my agents with codecs with claw. But I noticed that uh even though it gets me quickly to something that I can look at, normalizing it back to the design system was really really

[01:50] challenging. So the first skill that I’ve built for myself was called normalize and it kind of like brought it brought whatever claw designed back to the design system. That’s how I started and I also used Anthropics funed design skill like maybe many of you um when I first got going and from there on it kind of expanded into more and more design skills that allowed me to turn clawed code and then codecs and other harnesses more into a design harness. Um at some point I decided maybe other people might find uh um might find this

[02:22] useful as well. So I open sourced it as open source skill uh released it and it turns out a lot of you liked it. Um so if you haven’t checked it out yet um uh yeah give it a go. Uh it’s on impeccable.style. Um but today won’t be a talk about impeccable per se. It will be about what I learned from making these skills because it kind of escalated. It started with like a simple prompt and then uh went all the way to what it is today. Um, a lot of people have looked at the code of Impeccable and they see like a

[02:54] whole bunch of scripts in the scripts folder and they’re like, “What is all this stuff?” And so, um, I wanted to share some of my knowledge that I’ve gained with you. So, let’s get into it. Uh, let’s talk about the dark arts of skill engineering. [panting] Okay. Um yeah, the production value of this talk is out of this roof. Um okay, so first of all, you’ve all seen this kind of design. Um this is actually a real

[03:28] design uh built with uh the front end design skill uh and clawed code. Um and you probably all have seen a design like this. This is for like a fake kids reader, iPad reader app. Um you have italic serif. Uh you have like some capitalized uh hero. Um, and you have like a eyebrow text, like a kicker, whatever you want to call it. The top of it, like a weird label. Um, you have beige, I call it claw beige, claw beige, uh, backgrounds.

[03:58] Um, and now it’s not necessarily a bad design, right? But I think you all can point this out and say like, well, this is clearly AI generated. It’s clearly slop. Um, and it turns out slop is a moving target. Um you’ve all seen you might have thinking might have been thinking of slop as purple gradients but uh we’ve kind of moved on since that uh into cloud beige. Um okay so this is where I started. I started with a system prompt and a prayer basically. Um, so I I started using the front end design skill uh like

[04:32] many of you and it’s like 55 lines of named bands. Uh, no scripts, no routing, pure pros, right? Uh, and you just hope for the best. Um, that sometimes worked and sometime and most of the time it didn’t. So, um, for example, I’m just going to read some of this. So, um, if I mean maybe it’s really readable, I don’t know. Um but for example in the font and design skill you have sentences like never use generic AI aesthetics overused fonts like inter robboto arial system fonts um or cliched color schemes particularly purple gradients and white

[05:07] backgrounds uh never converge on common choices like space grotesque for example um now there are two problems with this approach the first one it over applies and then a ban just relocates the model to the next cluster and I’ll show you why this is a problem a a little bit further down the road. But really, you tell it not to use in, it just uses the next best font it finds in its latent space. And so it doesn’t actually make it more creative. It just, again, this is why I said slop is a moving target. It kind of picks the next best thing.

[05:37] Um, I have uh learned my lesson here um the hard way because uh I don’t know if you noticed, but the reason why we got purple gradients in the first place is because of Tailwind. Taywin’s default sample pages theme whatever was purple. Um well it turns out I’ve turned the web orange before many years before that. I created a framework called jQuery UI and the first default theme of jQuery UI was orange. So overnight I call it the web orange. I thought people would modify the theme but now they didn’t. Um so I learned my lesson. Um okay the median is

[06:13] the model’s gravity. Even 250 lines of like artisal, crafted, beautiful skill pros cannot change this. It’s just not enough. It doesn’t help enough, right? It’s nowhere near enough. Um, and I learned this the hard way and hopefully you don’t have to. Um, my overall thesis for this talk is that prompting is sort of like the starter level, but harness engineering is where you should end up. Like you should reframe when you’re building skills. You should think about

[06:45] okay skills the same way as MCP is an extension to the coding harness or whatever harness you’re in. Uh it’s not just a prompt that you package it’s something more than that or you should at least conceptually think about it more than that. It is extending the harness of whoever is using that thing. Uh and it also has more capabilities as just prompting. Uh and when I thought about that way it sort of like clicked for me. uh prompting is a spell harnessing the magic and we’ll talk about nine different dark arts today

[07:16] that I learned uh in the process of building impeccable um we’ll make uh sub agents argue with each other uh we’ll talk about how to force divergence as opposed to convergence routing like a model um and basic you’ve seen this probably um most modern models are mixture of expert architectures and impeccable is built like a mixture of expert skill. Um, we we give them memory. We’ll create scripts that talk back and I I promise

[07:48] this will make sense. Uh, hooks that fight back live wire the browser and use more of the harness. Compile to every harness and design for the weakest model. Let’s get into it. Number one, made it make it argue. So if you’re building something like a critique skill or code review skill, um here’s one huge issue. Uh if you are I mean you probably noticed this when you’re working with claw code or codeex doesn’t matter, but if you ask codeex or claw code to review its own work, it will usually rate it as very high. It’s like I mean like I’ve

[08:24] built this, I’ve done a great job, right? Like it’s like grading your own homework. Doesn’t make any sense, right? um it anchors on what it already created. Um now that’s not great. Um what can you do in order to solve this? Well, you can make a model argue with another model, right? Adversarial prompting is also called. So you have two sub agents and they never see each other’s work. And here’s why this matters. So in Impeccable, there’s a critique command that actually critiques your design. And

[08:57] you can point it to your landing page. You can point it to anything. And there are two particular failure scenarios. The first one, and this is almost impossible to read, so I’ll explain it. The first one is um a strong page, right? So, it’s a really good-look page, but there’s a whole bunch of maybe like uh deterministic errors. And impeccable actually has a deterministic engine like a design llin llin llin llin llin llin llin llin llin llinter that can detect things like bad contrast can detect things like you know too many fonts um

[09:30] you know maybe things that are too close to the edge of an element so it detects some of I would say polish issues um but you could have this really beautiful website and then the detector runs and it’s doing that as part of the same skill and the same model thread and then the model uh just sees the detector output and say like well I guess there’s 500 issues therefore this design must be bad. Now that’s one. The other one is the opposite. The other one is it’s actually a really terrible page or maybe like an empty page but there are no

[10:03] detected issues by the by the deterministic detector. So the model is like we didn’t find any issues so this must be great design. So both of those are not amazing. Uh what you want is and this is what uh impeccable critique skill does it uh it kind of combines two things. It spawns two sub agents and they are blind to each other. Um and that’s how you get to a balance critique. So the first sub agent um does um

[10:33] um act like a design director. So it’s an L&M um that acts like a design director. And so um it looks for hierarchy, it looks for slop, it looks for uristics. And so it does a critique the way a human would with the browser tools that are you that are available to it. The second sub agent runs determinist deterministic detector and also collects browser evidence. And then once both of those results come in, the main thread synthesizes both into one into one critique and that produces a much more balanced result. And before

[11:06] I go on, um, I realized I actually have not, uh, have not shown you where the sample repo of this lives. So, let me bring this up real quick. Um, if you want to clone this and you have a decent enough internet connection, go ahead if you like. Um, so this is, um, uh, PBA Aus/impeccable miners talks. Um the talk lives here but also in the dark arts folder there is a

[11:37] starter folder uh and a demos folder. Demos uh has a pretty average median page that you can manipulate. Um and then uh in the starter kit you have enough to build sort of a a mini impeccable if you want to if you want to follow along or or try it out yourself. And so as part of this um there’s a troy here too. Uh you’ll you’ll follow along sort of the checkpoints the dark arts and build something yourself. I would suggest you

[12:08] know if you like to multitask great. Um you can apply this by the way to anything. You can do like a code review thing. You can do um it doesn’t have to be the design skill. Um but I wanted to have something for you to play. Uh back to the deck. So two blind opinions beat one confident guess. Um you can use this again I already said code review design review but also security audits once is a good example. Uh or a plan creating a really good plan RFC critique where you have multiple LLM judges argue with each

[12:42] other before it gets good or ranking outputs is a good good example. Now, here’s the problem, though. Codeex, why why you don’t let me do this? It’s bad. Uh, it turns out a Codeex never created these sub agents when I first tried this. Um, and I bang my head against the wall. I’m like, why is this? It turns out Codex has a different permission model than claude code and other harnesses. In codeex, you have to explicitly as a user request

[13:14] the use of sub aents for anything in the harness to use sub aents. So if you’re distributing a skill, you’re out of luck. The only way to make this work as far as I know today is to actually tell the model, okay, if you have sub agents capabilities, but you do not have permission, please stop right here and ask the user. And so that’s pretty much the only way you can get codecs to comply. So in impeccable um if you see something that you know makes you go huh

[13:47] um it’s probably because of that like you know through um lots and lots of issues that people filed and um a lot of testing on on my end also um a lot of this obscure knowledge got into the skills so that it works truly across harnesses. Um for instance here you see kind of pseudo code of how this would work. And then also I uh this is another really important thing. Uh very often if codeex realizes it can get away with something it will do it. So um if there is no punishment for not spawning sub agents

[14:22] it will simply not spawn them. It’s like well this is the easier route. I will take this easier route. So what you have to say is actually if you cannot use sub agents you must say that you are giving the user a degraded experience and codeex hates that so use that to your advantage. Um so um you can watch them argue. Um now I did not pre-record an actual example here because I’m like let’s do it live. Um, so we’re going to go into

[14:56] cursor and um I’m going to do like critique and let’s hopefully it’ll work. I don’t know if composer sponsor sub agents uh well enough but let’s see uh composer by the way if you haven’t used it is a really fast well balanced

[15:27] model so it’s kind of uh kind of neat for for work that you want to show on stage in particular um okay so now it’s doing something here Um, okay. This this repository I think has an old version of packable doesn’t sponsor agents. I see this is the unfortunate. Well, maybe it does.

[16:01] I’m not sure if it did or not, but I at least want to show you what the type of critique looks like. Uh, all right. Now it’s asking me a bunch of questions of what I actually want to create. I’m going to skip this. Uh, and now I get a design critique um on what’s working, what the priorities issues are, persona red flags. Now the

[16:35] actual thing that I wanted to show you unfortunately couldn’t be seen in this particular thread but we can come back to it. Um if you run this in in cloud code or codeex on the most recent version you should very clearly see I mean in cloud code it’s very easy to see the sub aents running and doing its work. So it will spin up two sub agents and you see it at the bottom of the cloud code thread uh doing its thing. Okay level number two uh our Ben just moves the problem. We talked about this already. Um, you ban enter into the

[17:06] model graphs graph space grotesque. How do you solve that? How do you force divergence? Well, a ban only moves the model around inside its own cluster. And what I’ve built for impeccable and for a bunch of other skills that I’ve released is what I call an anti-attractor. Uh, and the anti-attractor works by creating a random seed of sorts. And that can come from user input or it can come from a script that it can run that produces something that is completely unexpected to the model because that’s what you want. And so in this case for

[17:40] instance it would be font selection and instead of selecting this save next step prediction font it went into a completely different space through a different seat. Uh there are three techniques that you know are easy to hard and work differently. The first one um is is something you can do right right now. It’s the most simple one and it’s to shave the save pics. So basically tell the model, okay, name your top three fonts and then the model

[18:11] is like okay I got the top three fonts and then you’re like now throw them away. And like but why? Um but then you basically shave shaved off the uh the next token uh that is predicted. Um and you do that three times and then now you get to a different space of the uh like a further away in the latent space right um now that’s doable but now at some point you still get convergence so this is just you know a limited technique the second technique is to generate a lot of different things and then have a sub

[18:45] agent rank I’ve done this for a shader library that I’ve created called radiant shaders and um the goal here was to create around a hundred different shaders And the problem is every time I I would say you know create a new shader or create ideas for 10 new shaders I would get the same repeating ideas. I solved this with two in two different ways. The first one is I created something unexpected a random seed a creative seed. In this case I used celebrities. I said like well what would Ryana look like as a shader um or what would Beyonce look like as a shader? And

[19:20] um and then the model was like let me think about that. So that’s the first thing and then I said well generate a hundred of these ideas and then spawn a sub agent that ranks all of those ideas uh and that’s important. It has to be a sub agent because the sub agent doesn’t know anything uh from the prior context of the session um and uh and can then completely change the order. The third one is to create a random seat from a script. So in impeccable for example when you first start a project it calls a script called color.js JS and color.js

[19:55] has um over a 100 hand selected uh they’re not complete color pallets but they are primary colors and they’re kind of like a starting point of a palette and it reads that and then the model uses that as a creative spark to build a pallet around it for you. You can still say you I don’t like this. I mean I don’t like what it proposed but it it turns it into a different direction. So those are all ways to create divergence

[20:25] and when you design something with impeccable the same brief depending on the users’s input and you know color script that runs etc can produce vastly different results because of that because I didn’t want to have the whole internet look like uh everything else. Number three um here’s the problem. If you cram every everything into one skill, it kind of blurs them. The instruction following becomes not very good enough anymore. So if you’re building some general purpose skill and you expand it and expand it

[20:56] and expand it, at some point uh it becomes really really blurry to the model. Um here’s a concrete example of this. the anthopic front end design skill. Uh the former version of it, they just shipped a new version three weeks ago, but the former version had a line that I read earlier that says avoid system fonts. That’s okay for landing page design. But for product UI, oftent times you want it to feel as native as possible. So system fonts are actually the thing that you want. So how do you solve this? Um you can say I mean you

[21:31] have like this giant if else block in a skill. say like, well, if the user wants a landing page, do this. If the user wants a product, do this. But that becomes really convoluted, wastes a lot of tokens, and uh honestly doesn’t work very well. So, impeccable started as a lot of different subs skills and now has this um mixture of experts model that routes internally um both in terms of uh capabilities. So you can call impeccable critique or impeccable polish and you get a different MD file loaded behind the scenes for that particular job. So

[22:04] it’s not just one giant skill MD. Um, but also, and this is something not a lot of people know, behind the scenes, Impeccable decides based on your brief and what you input whether you’re trying to design something brandandy, so like a landing page or something that wants to attract attention or whether it’s the actual product that you’re designing. So, it switches registers and then loads completely different rules for those two registers because product design and brand design are very very different. Um, so that’s also something that I

[22:37] would recommend you doing if you’re building a larger scope. This works for bu big multi-tool skills, works for context on demand type of skills, uh, per audience behavior, agent toolkits, that kind of thing. Number four, everyone starts from zero. Skills by default don’t have long-term memory. Uh, they don’t really compound over time, but you can make it so. So um you have a skill folder and you can save things in that skill folder. In fact in claude you even have an environment variable that

[23:09] uh resolves to the actual directory uh that you can save things in which is nice. No other harness supports this right now I believe. Um but you can you can hack around that. Impeccable uses a impeccable folder in the current repository route. Um, but you can also save things directly in the skill folder. Um, and maybe ask the user to ignore them. Uh, how could this work? So, for example, if you’re running a critique in impeccable, that critique is saved as a file in that folder and by default it’s get ignored. But then if

[23:45] you then later on say, well, okay, I just ran a critique. I’d like to polish my page. Even if you do it in another session, it actually uses that prior critique as a signal to understand what have we found out about this page and it can look at all prior critiques and see sort of the progression of the page. Uh for example, you could have said in one of the critiques, you know, I don’t agree with this critique. I don’t think you’re right and I think I really like my instrument fonts. Um and then the model would be like, okay, no problem. I’m gonna mark this for later. And the skill is now smart enough. the skill has

[24:20] uh built context to realize okay well that’s the user preference so I’m going to respect it going forward um so compound engineering um really uh is an interesting theme for skills as well you can make skills aware of prior sessions with that technique um so make the runs compound this works really well for resumable gradients uh resumable agents progress tracking u multi session refactors migrations that kind of thing Um uh for instance, one of

[24:50] the things that I do all the time is refactor my code. And um how do I do that? By having a sort of like a skill that spawns itself across multiple sessions and tackles one file at a time. So I basically tell it, okay, here’s your TSX file or whatever um for today’s session. um and now refactor everything around this file and linking into that file and and then it sort of builds up context over time until it’s completely finished with the whole codebase.

[25:22] Okay, number five. Uh buried rules get skimmed. We talked a bit about this before, but this is a little bit of a different point I’m trying to make. Um now especially with weaker models and now if you’re building a skill for yourself and you’re only running opus or you’re only running codecs u this isn’t that that big of an issue right you you know which model you run uh you know if it works with GPD55 for example uh I’m good because that’s the only model I use now if you want to distribute your skill

[25:56] to lots of users uh this is where things get kind of hairy because some of those users might be running on it. Some of them might be running Haiku. Some of them might be running Grock. I don’t know. Um uh some of them might be running Gemini. You know, you never know. Uh sometimes I meet somebody who does. Um but um uh really that’s where it gets complicated, right? Um because you need to build for the lowest common denominator and ideally for the for the one model that is the weakest as at

[26:30] instruction following. For example, GPD5 mini is not a very good rule follower. Uh there are things even in impeccable that don’t work with GPD5 mini. Um it consistently doesn’t load certain MD files that I thought it uh it consistently doesn’t spin up the life mode. So there are uh boundaries to instruction following across these models and it gets especially bad with longer skills that have lots of rules. So how do you work around this? Well, in impeccable, impeccable really is kind of bionic of sorts. It’s really

[27:04] not just pros. It is a combination of scripts that run in line within the skill at certain times. Uh, and then pros around it. For example, every time you call impeccable, it runs a file called context. MJS. And the context MJS does a couple of things. The first thing is uh if there is a product MD which is impeccables uh it’s almost like design MD but it is for product strategy. So wants to understand who’s the target audience or what do you want to achieve with this thing which is oftentimes more important

[27:38] in a in a design interview than you know how how round do you want your borders to be. Um but it supports both. It supports product MD and design MD and by default context M.JS JS brings these files together and then spits them into the session. Now that’s not exciting. But when those files are not available, it will actually give the uh the skill structured JSON and say like by the way there is no product MD and here’s exactly what you should do about it. Or

[28:10] here’s another thing that context MJS does. It actually makes impeccable self update if there’s a new version of impeccable now with your permission. So we will it will ask you but it will say hey by the way there’s an update available for the impeccable skill uh and here’s what you should do now to ask the user whether whether they want to update impeccable. So it’s it’s overloaded in many ways um and it will always tell the model the exact instructions on what to do next. And the really interesting thing about this is that I found that that works significantly better than some random

[28:43] rule in the pros of the main scope. when you put something out uh from the exit value uh from the standard out of a script uh somehow the model will follow it a lot uh more than before. Uh so that could be environment uh aware setup dynamic onboarding repo state gating adaptive flows anything really. Um actually before I end this session one of the shortcomings of this technique and this is something to be aware of is prompt caching. So this works super

[29:16] super well to keep a skill uh sort of like you know flowing in the right direction instruction following but it does so at the expense of prompt caching. Um, if you need prompt caching, if you run the skill many many times, uh, and you want the whole thing to be cached, this is not a good technique to use, but I found it to be very useful in really interactive scenarios. All right, number six, hooks that fight back. It’s

[29:46] something I shipped quite recently and um, and I really like it. I want to show you what I mean by that. Um, so a lot of people have impeccable their systems, but sometimes they forget to run it. Sometimes they’re like, you know, I don’t know. I mean, I mean, I wish Codex is actually pretty good. Some of the harnesses are pretty good consistently looping in the right skill. Um, but because it now bundles as one skill, oftent times, uh, the harnesses

[30:16] forget to simply call impeccable when you don’t explicitly mention it. So, now you’re building some front-end code and maybe it doesn’t follow your design system or whatever. Um now that can be solved with hooks. Who who has used hooks before in cloud code or codeex? A few people. Okay, nice. Um so this skill that I’ve built here, Impeccable ships design hooks. So I’ve basically built a design lint that runs

[30:46] under the hood and ships with the skill. When you install impeccable uh these hooks install into cloud code, cursor um codeex and github copilot uh and they will keep the model uh exactly where it needs to be. So the hooks come to you. It’s a guardrail that fires on every edit. Um and um there are some there are some differences between the different providers here. So the hook syntax for codex and clot code is not the same. Um

[31:20] and also the behavior is not the same. So for instance we found out that with weaker models slightly weaker models like composer and cursor. Uh you kind of want to use a um pre-tool use hook that prevents writing of code as opposed to a post tool use hook. Post tool use basically happens right after the agent has written a file for example and then it it tells you hey by the way like the contrast of these colors is bad or um you know you have a purple gradient in here and then ideally the model is smart enough to actually fix it. Um some

[31:54] models don’t follow those instructions very well and so if you do a pre-tool who use hook you are actively preventing the writing of this file in the first place. So, it’s a much more heavy-handed approach, but we needed to do that for certain models and certain hardnesses. Um, but this is nice and what’s even nicer about it is that you can personalize it to your design system and your use case or whether let’s say you use it for code reviews. You can personalize it with your own ESLint rules uh with your own uh synthetic

[32:26] syntax guidelines etc. uh and then expand it from there. Um, so passive guardrails beat a command no one remembers to run. Um, so these are passive guardrails that always keep you in the right lane uh on track. Again, that works for linting for formatting. Um, of course, if you’re using cloud code or codeex, it already uses uh some of the llinters for things like syntax formatting, but design linting is a whole different uh game.

[32:57] But I would really encourage you to uh try out hooks in combination with a skill and think about okay well my skill does this how can I create a feedback loop a validation loop that uses hooks uh to actually keep me on the right lane. Um okay so here’s it’s hard to show loop uh hooks in action but um you know if you can see this this is roughly how it would happen in an agent. Um so uh for

[33:27] instance in this case I would use let’s say Gemini does this all the time. Gemini uh creates animations on images like crazy. Um it will animate any image and it will usually do a hover zoom in effect. Um it loves that. Um and that’s something that impeccable flags. And in this case it the hook would fire silently usually that’s why I built this fake demo because you can’t usually see it. Um, and then it will tell the model, hey, by the way, here was a violation.

[33:58] The experience of this is that oftentimes you don’t have to do anything. The model just course corrects and fixes itself. Um, now one important thing if you do this and you ship it to users, very important to add a way to create ignore rules or something like that because oftent times these hooks have false positives as well and you want a way to configure those hooks. Um, otherwise gets really annoying very quickly. Um, impeccable ships with these design hooks that uh allow you to create ignore rules at a file basis within a

[34:30] CSS rule. So like many granular levels uh to exclude certain files for example. Okay, level seven. Now you can’t really tune pixels through a chat box. Uh now this might not be relevant if you’re not building a design skill, but I think the general point is relevant. So if you think about a skill as harness engineering versus prompting then you think about the harness as a whole right you’re living in cloud code for example or you’re living in codeex

[35:02] or you’re living in github copilot now what capabilities of that harness that you can exploit to make the best user experience for your use case that’s the question you should ask yourself for example uh uh codeex on desktop now has an inapp browser built into the the actual um uh app. Can you use this inapp browser in some interesting ways? Can you use the browser screenshot tool in some interesting ways? Uh and in my case, I

[35:33] could. I realized, hey, there’s probably a way to connect the inapp browser uh and spin up the development server and just load the page there and then kind of connect it to the main thread in some ways. So I can allow the user to visually iterate on that page um instead of in the chat. Um and so in Impeccable what this looks like is uh it’s not using MCP. Um it’s

[36:03] simply spinning up a live polar a little server that uh looks for input and in inserts a snippet into your development server. Um it then on the page when you do something on the page it sends an event back to that actual polar uh using uh serverside events and then uh and this is I think the the the clever bit maybe or the the bit that makes it all work. Um the polar then stops. So the polar uh ends itself. There’s a standard out message. We talked about standard

[36:36] out before, right? the exit value of this thing and uh the model reads that message and realizes oh something happened I better do something. So in this case in the skill itself I give it instructions on how to handle this event. I say like well if this event comes in you should probably build some design for this particular section of the page and then you should send it back to this polar so that it arrives on the user side. And so this is a direct connection between one harness capability and another harness

[37:10] capability. So the chat thread and the inapp browser. Um and uh yeah this is kind of how how it looks like on a diagram. But I think the best way to experience with it is to is to see it. So let me bring this up. Okay, cursor. Uh, I think I’m already in live mode here. Um, okay. So,

[37:42] I I booted up live mode already. I’m now in picker mode. I get this little bar here at the bottom. Uh, and as you can see, I can pick anything on this page. Um, I get now I get this little overlay bar and um I can select all sorts of subcomands within the skill. So these are basically translating to MD files that live within the skill. Uh I can select the amount of variance I want. And then um I can hit go. And now um here in the thread you can see that it

[38:14] picked up the actual signal in the main thread uh because the polar stopped h and it now knows hopefully exactly what it needs to do to first wrap this element in some special tag. then it knows how to create uh variants and uh that are marked up in a special way with CSS. Uh and now it did that. So now as you can see the uh the thing updated immediately. I now get these three variants and I can click through

[38:46] and then if I like one of them I can click accept and accept it. If I don’t like like one of them I hit uh escape and I’m back in this normal mode. Um so this shows sort of like uh how to exploit an a harness capability uh in an effective way for one problem space in this case design. Um you can also uh insert elements with this thing um and sort of click into anything here. You can um you can draw on top of this and leave comments. You can leave annotations if you want. Um you can dictate uh you can uh steer the whole

[39:22] page by simply writing into this and then uh again this goes back to the main agent and uh it becomes a steering signal for the whole page. Um and you can also visualize lots of things this way. I mean you might have read uh Tariq’s uh blog post about this about how HTML is a is a really cool way to communicate as opposed to markdown. Um I agree and I think also like uh design MD is much better visualized as HTML. In this case you see the M design MD of this you know not great website for demonstration purposes but uh um you can

[39:57] use this to your advantage as well if you hijack the inapp browser and use it to your advantage. Um so this is how I make use of it. Okay number eight. It worked on my machine. Um well I mean everybody who who’s a developer here knows this problem. Um this is this hits really hard when you ship a scale. Uh there are so many times uh I kind of saw this argument on X was

[40:28] like hey bro just sim link just you know sim link.cloud and all your problems will be gone. Um, well, that’s great. If you’re building a simple skill and if you’re doing it for yourself, by all means, go for it, right? Sim link your claw MD to agents.m MD. Amazing. Like, sim link the out of everything. But it’s not great if you’re trying to ship a skill to lots of users because again, we just talked about a whole lot of differences these hardes have. I’m going to talk about more differences. And I know it’s annoying because it

[40:59] would be great to simulate those things, but unfortunately, we don’t live in that world. And unfortunately, Anthropica has still not adopted agents. MD. So, uh, what are the actual differences? For example, we talked about sub agents already. We talked about how, well, on the bright side, they’re widely supported. Now, um, but who can spawn one is very very different. So, with claude, you can programmatically do it very easily. Codeex needs the user. Okay. Um, in cursor, it’s agent chosen most of the time. Um so there are clear

[41:33] differences also if you want to predefine these agents codeex has a different syntax for that uh than claude and and uh and cursor etc. Another one is the ask user tool. So one of the coolest tools in and the um cla code harness is the ask user question tool. Uh it’s a really nice tool that you can use to ask the user a question right? It brings up this menu say like hey what would you like to do and then you pick some option. Well, turns out Codex has a

[42:04] tool like this. That’s the good news. The bad news is that tool is only available in plan mode. So, again, big differences between how these things work. Uh, and um, what does that mean? That means that if you’re not running codecs in plan mode, but your skill wants to ask questions, most of the time it simply doesn’t. It will simply infer from the current context and not ask any questions to the user. Uh, which is not great. So there’s a lot of sentences in the impeccable skill that specifically say if you’re codeex you have to stop

[42:38] and ask questions. No, you’re not smart enough to infer the context. Um so if you see lines like this, that’s why. Another one is background jobs. And there’s also something you learn through the hard way by doing this. For example, this live mode that I just showed you, it’s spawning a background task. So it’s running a shell in a background task. Uh and that that’s cool because you can keep using the session um and then when the background task finishes the model is automatically waken up gets a gets the message back

[43:11] and then can do something and re react to it. Uh where codeex cannot codeex and other harnesses do not react when a background task finishes. You actually have to manually say hey by the way this background task can you take a look at what it did and that’s not great right if you’re doing an automation like this. So there are differences in how these tasks are spawned and uh and how they work. So that’s why if you’re using the live mode in cursor or in codeex, it creates a foreground task and it keeps the actual chat thread blocked. Uh not

[43:43] ideal, but it makes it actually work. So there are subtle differences on how these tasks are spawned. Watchers is another example. Tail watch exists now. That’s really cool. I mean most of the harnesses have a way to watch for instance a log file. Um but those are throttled way harder than uh simply spawning a background task. Edit hooks, we talked about this already. Um they are different and so lots and lots of behavioral differences, but there’s also model differences. So for example, in my case,

[44:14] um they all have different tails in the ways they’re overfitted. Uh for example, Gemini, again, I mentioned this loves to animate pictures. It just loves it. Um, you have to tell it not to animate pictures if you don’t want a hover effect on every picture. Doesn’t matter where it is. It loves it. Um, Codeex loves bad letter spacing. I don’t know why, but it does. Um, Codex also loves extremely rounded borders. Uh, it will round anything you thought it. Uh, it

[44:44] loves it. Doesn’t matter if it’s hospital website or a kids website. Uh, it also loves hairline borders. And so there are specific tails that are unique to every model. And that’s not just for design. It’s for architecture. It’s for code architecture. It’s for, you know, preferred npm packages. Now, every model is overfitted in different ways. Uh finding out how to overfit it usually happens by accident. In my case, I have a pretty extensive EVA harness that I run behind the scenes. In fact, every line of impeccable is ablation tested.

[45:16] So I test every single line and see what it does across all models. I don’t expect you to do that but it is very good to know that uh that the models are different and are following instructions differently and and the behav behavior the harness behavior is different as well. Um and so what impeccable does it creates harness specific and model specific builds for every single uh model. Um, you might not have to go all this way for your own purposes, but I just wanted to show you

[45:48] how far you can go with this. Uh, for example, it actually has a um substitute variable that picks the right user question tool depending on the hardness or it has these XML blocks for Gemini, for codeex, etc. Uh, that will actually insert specific overfitting avoidance rules for the given models. Because it turns out if you if you tell Claude not to let her space too much, it will let space in the exact opposite direction. So you can’t just include it all in the

[46:19] same skill. Um and that’s why you know you can you know if you if you instrument this way enough you can actually get to this right once ship to all of them uh skill that actually works everywhere. It’s a lot of work but it does pay off and allows you to create beautiful pictures like this. Um now the only other problem is that uh typical install methods like for um uh MPX skills for instance if you’ve been using MPX skills do not honor

[46:50] um different directories for different harnesses. So they actually just take the first directory and then copy it or sim link it into all sorts of folders. Um that’s why if you go to the impeccable website uh I’ve built my own CLI to solve this problem. Uh that’s why it doesn’t use impact skills. So, I think the committee hasn’t quite yet gotten to the point where uh this is a this is an accepted idea and it’s annoying. I get it. It’s annoying to compile for different harnesses, but uh I found it worthwhile. Finally, um again, build for the lowest common denominator. Um a weaker model has

[47:24] opinions just fine, but what it loses is the discipline to follow yours. Um so uh codeex for example uh and GPT specifically loves the word gate. If you’ve built a skill in codeex before, it loves gates. Um whenever you say, “Hey, why didn’t you follow these instructions?” You’re like, “Well, I think we need a gate.” Um so I gave it what it loves the most, gates. Um but I only do that for codeex. So there’s a codeex MD that gets loaded on the fly

[47:57] for codeex. um and GPT uh and then uh it actually follows like you know okay here are your eight gates you have to pass every single gate and you are not allowed to compress those gates. Um that’s really important because it loves compressing these instructions as well. I’ll just skim over it and say like well I guess I do one and two and five and good. Um and so um the way you solve this is by actually having it lock every single result of every gate and say like well I just passed gate one great success. Um

[48:31] and the most important lesson from this is if the gate can be skipped it will be I mentioned this before right if the model can wiggle itself out out of a difficult situation it will absolutely do that. uh it will not do all the all the things it needs to do to uh to complete the end result. Um so be careful, make it unskippable. Um so we just built a harness extension. We went from prompting all the way to building a monster. Um but uh I think it

[49:03] turned out to be pretty powerful in my case and I wanted to share what I’ve learned on the way. Uh I don’t expect you to use all of those techniques. I think some of them are pretty exotic and maybe not applicable to every use case. Um, but I hope that you find value in uh some of the advice that I’ve given today. Uh, so we’ve done a whole bunch of things today. Nine things a prompt can’t do. We made it much more deterministic um and uh and made impactable better for that reason. Uh if you like to try it out yourself um

[49:37] again you can clone the repository for this talk. you can clone uh impeccable minus talks. Um but of course it also is useful to just take a look at the actual skill and see how it’s built. Um the project is completely open source license under Apache 2. Um you can install impeccable MPX impeccable skills install. Um and check out the source code on GitHub. Um with that um I’m at the end of it. Thank you. >> [applause]

[50:12] >> And uh now I think we have uh about 10 minutes for any questions that you have. >> Does anybody have questions? >> Yes. >> Oh, sorry. What was that? >> A link >> to the repository. Yeah. Um so the the this is hard to see but [music] uh let me let me put it up here. Um this is the repository

[50:44] uh for the talks. Yeah. >> Awesome. My question was you mentioned that. >> Yeah, I the question is I mentioned that it breaks prompt caching um the the actual sort of trick the technique to actually get uh something back from a script um within a skill. And the reason is because the result is dynamic, right?

[51:19] It could be anything. Um, so unless the result is always the same, it’s a dynamic shell execution. Um, so it gets inserted into the into the thread. Now the now to be fair, the skill will still be cached. So the skill will still be cached but uh but I guess I’m differentiating between the skill with inline uh you know static content versus the skill with sort of like a dynamic instruction to call out. So this part will not get cached yeah that was that was my main point. >> Yeah.

[51:52] >> Yeah. >> Yeah. what is the process on how I evaluate and iterate on this skill? Um, so I the process is pretty involved. Um, let me see. Uh, see if I can bring this up on screen. Uh, uh, okay. Here we go. So, here’s a glimpse. Oh, no. Okay, I shut down the

[52:28] server. That’s fine. Um, okay. I’ll just voice over. So, um, yeah, I mentioned I built an uh Evals harness and, um, and so I’ve created myself a harness that, uh, re closely recreates the conditions and the tools of every harness that I care about. So, for instance, it uses the clawed code SDK. Yes. Uh sorry guys, can you uh can you lower your volume a little bit? Um

[53:00] because uh people are still trying to hear the questions. Um thank you. So how do I how do I test this? How do I build it? So this it’s a combination. So first of all, Impeccable has a ton of end to-end tests in the repository. Um uh that’s both L&M driven tests as well as um endto-end playright tests. So that’s one uh and that’s useful for things like testing the live mode scripts for example. Um, but then beyond that, how do I test that it actually works? Uh, well, I’ve built a EVA harness. That one is not open source

[53:32] yet, but I built a EVAL harness that closely replicates every um every model harness that I care about right now. Specifically, right now uh uh cloud codecs in Gemini and um and I’m trying to expand to more and it also recreates the tools like for instance browser screenshot tools uh or something along those lines. And um and then it also recreates um the because some parts of impeccable are interactive. In the initialization of impeccable oftent

[54:03] times the user gets asked so you know what would you what would you like your page not to feel like? And so you get these interactive like back and forth and so I’ve built this LLM that acts as the user against the other LLM. And so it does like an interactive you know back and forth turn. Um so I’ve built that harness and then I’ve built a um mixture of expert design judge that runs on top of it. So basically give it eyes uh to evaluate each result. Uh and then I can run uh across 20 different niches like for instance Italian restaurant. Um

[54:38] I run across all models that I care about GPD55, Opus, Sonnet um and do like five to 10 tests um for each of those uh for each skill release to see you know how it changed. I also run against competitors for instance I run against the front end design skill to see does it make a difference um um and and and how does it make it worse or better um and then beyond that I’m doing ablation testing that’s harder and more expensive I would say um

[55:09] so I don’t recommend it for everyone but this the ablation testing so every you’ll see this in the source code of impeccable every rule has sort of an XML tag that says like you know a unique identifier of that particular line. Um, and that that will be used by the harness to then do a test where it removes that line um runs the evolves against all models and then adds the line back in and then uh uh uses the detection engine of impeccable the deterministic one to see did it actually change. Right? Right. So if there’s a

[55:42] line that says, “Hey, don’t don’t do like gray on colorful backgrounds for for contrast purposes.” Um there’s a there’s an ablation test and then a deterministic check or feedback loop that tests against it. So uh in short quite involved um but uh but I really it started you know vibes based uh and now it’s really uh truly um well tested. Yeah. >> Yep. Go ahead.

[56:15] Sorry, >> you set up for evaluating taste. >> Yes. >> Yes. Um I do have I do have um evals for evaluating taste, but I don’t think they work particularly well. Um I just talked to uh Ben from Contra about this. Um I don’t think I I mean I know I know um some of my colleagues might disagree um but I don’t think taste can be solved at a model level. Um I actually think it’s

[56:45] a it’s a fundamentally human thing um because taste is scars and unique and once everybody uses the same taste uh it becomes ubiquitous and then we don’t think it’s tasteful anymore. So it’s it I think it’s uh um I think it’s hard. Um and I also think the models are particularly bad at evaluating taste. So for example um there are certain things that the models can evaluate well like hey is this is is the correct thing in the first viewport right? So functional stuff that works but what doesn’t work and here’s one example I’ve built again

[57:20] this mixture of judges and one judge rates whether the first viewport looks great right and is effective. Um, and one of the tells is that uh, Gemini, for example, the more stuff there is in the first viewport, the higher it rates it, right? This is just a general rule. Like if you just cram the viewport full, it gives it a higher ranking. And so there’s a interesting example of like, you know, the models are often maximalist, right? They like, well, more

[57:52] is more, I guess. Um, and so oftent times I build judges that actually invert the response of the model. Uh, which is really strange, but it works. Um, where it sort of judges something very high. I’m like, okay, that’s definitely not a good design. Um, so anyway, I don’t think it’s solved and I don’t think it’s solvable, but um, I do have, I would say, a tool that gives you the design director eyes that works marginally better than random. And that’s good enough for me for like a first pass and then I use my own human

[58:24] eyes to evaluate results and annotate them. Any other questions? Yeah, over here. >> What do you say is the future for skills? >> The future for skills. So I would say that’s a that’s a broad question. Um yeah. >> Yeah. So I’ll first answer for impeccable and for me. So in the in the

[58:57] case of impeccable I think we’re we’re definitely outgrowing uh the skill platform kind of what’s possible with skills. I think the the live mode is a good example of that. the live mode um was sort of like a Jurassic Park experiment to see like can I do this? And the answer is yes is um I think it’s it’s it’s working better than I expected but um it still has a lot of problems. I mean it would be way better to do this in a first party harness integration or like a like a first party tool. Um so I think there are limits

[59:30] that I’m hitting where um where skills might not be effective anymore. I think in general I would say most skills should probably be written by the individual users. I think those that actually go go through the effort of packaging a skill and sharing it with others need to invest more time than they currently do. So I guess that’s my hot take. I think right now I’ve I’ve seen plenty of skills that are distributed that uh do not work well in a model that the author didn’t use for example, right? And so I think I

[1:00:04] think we just have to raise the bar of what’s acceptable to ship uh to to to people. I mean again this is like the works on my machine thing. Um I would rather see less skills in the ecosystem that are really battle tested and proven. Um and I I hope we’re shifting towards that because right now it’s sort of like a wide west. >> Yeah. Go ahead. There’s no like way to test it all.

[1:00:37] >> There’s no common way to test the skills. Yeah. And that could be a opportunity. That’s a good point. Yeah. I guess I could I do have the tool for that. That’s true. [laughter] Yes, I could do something with it. Yeah. uh right now it’s purely built for my own purposes but uh but yeah the same is true for for instance like the the impeccable installer and compiler um I don’t think most people know that it exists uh that it can compile to every harness and that it has these substitution techniques and stuff like this like I could probably release that standalone as well. Yeah, it’s a good

[1:01:07] point. >> Yeah, go ahead. MCP having skills on the server. How would that work? >> Oh, I see. Yeah. Um, to be honest, I haven’t tried it out yet. Um, or I haven’t really read too much into it. I think MCP in general um

[1:01:37] you know I worry greatly about context pollution and um I do that with skills too and I think um I’m not using MCP a lot for that reason um because it polluted my context many times. Um how do skills work in MCP? Oh, you can download a skill from MCP server. Yeah. Okay.

[1:02:20] >> Yeah. >> Yeah. Yeah. Yeah. >> So, what’s the recommended way of packaging them and distributing them? Yeah. It’s a good good topic. Um so of course like the harnesses and the and the frontier labs have their own ways. I mean um Codex has a marketplace that you can use for distribution plug-in marketplace. Um uh Claude Code has a marketplace as well. I think they started with the marketplace technique. Those marketplaces don’t work particularly well. I mean the Claude code one for sure doesn’t work

[1:02:53] particularly well. I know this for a fact because I mean the update me mechanism often doesn’t work and people are like well my skill doesn’t update and oftentimes there’s a caching issue. So it my experience has been hit or miss with the native methods of distributing and then of course it only for that particular provider. That’s why projects like uh skills.sh exist. But again, the problem with MPX skills right now, it does it it does it it doesn’t allow for like, you know, more advanced skill use cases like, you know, compiled for every

[1:03:25] different harness. I have a pull request um in the in the repository. Um and I’ve uh I’ve bugged Andrew a couple times about it, but um he uh he still has to get it merged or agree to agree with me on that, I guess. Um I think uh we’re still discussing. Um but yeah, MPX skills I think is a great project in general. I think it’d be great if we could sort of like standardize around it. Um there’s also one from Microsoft trying to do that. Um a project from

[1:03:56] Microsoft. I forgot the name of it. Um but there’s definitely no no industry standard for distribution yet. Um yeah, I’m not I don’t love having to maintain my own CLI installer. I would rather not. Uh it’s annoying. Um but uh it does make it so it plays safe with all harnesses installed, the hooks in the right part of the system, etc. So it’s um Yeah. Yeah. Okay. I think I’m way out of time, but come up and speak with me if you like.

[1:04:27] Yeah, I would say I’ll end it here, but yeah, come come up if you like. Um let me just uh Thank you. [applause] >> [music]