Open Source Friday: Spec Kit, parte 2

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: Open Source Friday: Spec Kit part 2 · Canal: GitHub · 1:01:31 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Engenharia de software com IA, Ferramentas de desenvolvimento com IA, Open source e ecossistemas de software

Resumo

Manfred e Nicole Hougen apresentam as novidades do Spec Kit desde o episódio anterior, incluindo o lançamento da versão 1.0, extensões, presets, bundles e novos workflows. Eles explicam como o projeto mantém seu núcleo agnóstico em relação a coding agents e mostram a integração específica com GitHub Copilot, que oferece comandos em linguagem natural e canvas apps para visualizar e executar processos. A demonstração percorre workflows de desenvolvimento orientado a especificações, avaliação de ideias e correção de bugs, além de um wizard para montar pipelines personalizados. Ao final, conversam sobre eficiência no uso de tokens, personalização para diferentes processos e contribuições da comunidade open source.

Pontos-chave

O Spec Kit chegou à versão 1.0 e, na gravação, já estava na versão 1.2.
Bundles permitem reunir conjuntos avaliados de presets, extensões e workflows para compartilhar e usar em equipe.
O núcleo do Spec Kit é agnóstico em relação a coding agents; a integração com Copilot fica em um repositório separado.
O plugin do Copilot permite conduzir o Spec Kit usando linguagem natural, sem precisar lembrar os comandos.
Canvas apps oferecem interfaces visuais para acompanhar e executar workflows de desenvolvimento, avaliação de ideias e correção de bugs.
O wizard permite selecionar extensões e presets, montar pipelines e experimentar as etapas do processo.
O preset Lean reduz a quantidade de artefatos gerados, criando apenas especificação, plano e tarefas.
A etapa de convergência verifica se a implementação corresponde à especificação e pode acrescentar tarefas para corrigir diferenças.
A comunidade pode criar extensões, presets, bundles, workflows e etapas próprias, adaptando o Spec Kit a diferentes necessidades.

Capítulos

Início	Capítulo	Resumo
01:17	Abertura e apresentação dos convidados	Sara Kaiser apresenta o programa e recebe Manfred e Nicole Hougen para conversar sobre as novidades do Spec Kit.
04:32	Lançamento e evolução do Spec Kit	Manfred comenta o lançamento da versão 1.0 e o crescimento da comunidade, além da chegada de bundles e suporte a etapas de workflow.
07:07	Novos processos e convergência	A conversa apresenta workflows para avaliar ideias e corrigir bugs, além da etapa de convergência, que verifica se a implementação segue a especificação.
10:44	Suporte experimental a MCP	Manfred explica a possibilidade experimental de interagir com o Spec Kit CLI por meio de um servidor MCP.
13:18	Integração do Spec Kit com Copilot	Manfred descreve o repositório separado que adiciona plugins para conduzir o Spec Kit em linguagem natural no GitHub Copilot.
17:25	Plugin e inicialização com linguagem natural	Nicole demonstra como inicializar um projeto e criar uma constituição com o plugin do Copilot, além de explicar como os comandos são disponibilizados como skills.
24:39	Núcleo agnóstico e suporte a diferentes agents	Manfred explica como o Spec Kit gera instruções para diferentes coding agents, mantendo o núcleo do projeto independente de uma plataforma específica.
26:44	Canvas apps para workflows	Nicole apresenta interfaces visuais para desenvolvimento orientado a especificações, avaliação de ideias e triagem de bugs.
33:26	Wizard para personalizar pipelines	A demonstração mostra como explorar presets e extensões, montar pipelines e personalizar os artefatos, inclusive com um preset de linguagem de pirata.
39:08	Geração experimental de canvas apps	Nicole mostra uma funcionalidade em desenvolvimento que gera um canvas app a partir dos metadados e das etapas configuradas no wizard.
47:24	Eficiência de tokens e preset Lean	Os participantes discutem o custo de tokens e apresentam o preset Lean, que gera menos artefatos para workflows mais enxutos.
50:32	Python e funcionamento dos comandos	Manfred comenta a escolha de Python para a implementação e esclarece que, durante a execução dos comandos, quem interpreta os prompts é o agent.
53:40	Avaliação de ideias e processos de equipe	A conversa aborda perguntas de esclarecimento, avaliação de propostas e a possibilidade de adaptar o processo a diferentes funções e setores.
58:21	Comunidade e encerramento	Os participantes destacam a natureza open source do projeto, convidam o público a contribuir e encerram o episódio.

Citações

Se você não gostar, faça do seu jeito. — 10:13

Quando alguém cria uma extensão, ela é entregue de forma agnóstica. — 25:40

Se você precisa de algo pequeno, use o preset Lean. — 49:29

Começamos como Spec Kit; agora ele realmente se tornou um kit de processos. — 56:15

Você também pode adicionar coisas novas e ver como elas funcionam. — 58:21

Conceitos e entidades

Spec Kit (repo): Projeto open source que oferece componentes e workflows personalizáveis para desenvolvimento orientado a especificações e outros processos.
GitHub (empresa): Empresa responsável pelo programa Open Source Friday e empregadora dos participantes da conversa.
GitHub Copilot (ferramenta): Ferramenta de desenvolvimento com recursos de agent e suporte a canvas apps, integrada ao Spec Kit por um projeto separado.
Spec Kit Copilot (repo): Repositório separado que reúne plugins e recursos específicos para usar o Spec Kit com GitHub Copilot.
Spec-driven development (conceito): Processo de desenvolvimento em que especificações orientam etapas como planejamento, criação de tarefas e implementação.
Canvas apps (ferramenta): Aplicativos visuais no GitHub Copilot que orientam a execução de workflows do Spec Kit.
MCP (conceito): Protocolo mencionado como uma forma experimental de interagir com o Spec Kit CLI por meio de um servidor.
Manfred (pessoa): Principal software engineer no GitHub e participante que apresenta as mudanças e os recursos do Spec Kit.
Nicole Hougen (pessoa): Principal software engineer no GitHub que demonstra os plugins e canvas apps do Spec Kit para Copilot.
Sara Kaiser (pessoa): Apresentadora do Open Source Friday que conduz a conversa e as demonstrações.

Tradução completa (pt-BR)

01:17 [música]

01:59 >> Uhu! >> Bom, sejam todos muito bem-vindos ao Open Source Friday. Estou muito animada. Hoje temos um projeto muito legal e convidados incríveis com quem estou realmente empolgada para conversar. E também é sexta-feira, então feliz sexta! Mas, sim, só um aviso rápido: o GitHub Universe está chegando. Meu nome é Sara Kaiser. Trabalho no GitHub.

02:30 E vocês podem conferir nossa grande conferência, onde vamos anunciar todo tipo de novidade, desde a plataforma github.com até o Copilot. Todas as nossas ferramentas vão estar lá, vai ser muito divertido, e vocês podem se inscrever gratuitamente pela internet. Então, é uma ótima maneira de ficar por dentro do que está acontecendo no GitHub. Certo. Vou chamar agora

03:01 nossos amigos de hoje. Vamos conversar sobre… Oi, pessoal! Falamos sobre o Spec Kit no episódio anterior, com Manfred. E hoje temos Manfred, que é engenheiro de software principal no GitHub, e Nicole Hougen, que também é engenheira de software principal no GitHub, para falar não só sobre o lançamento da versão 1.0 do Spec Kit, mas também sobre

03:32 o que mudou desde a última vez que conversamos. Então, se quiser contar mais alguma coisa interessante sobre você, Manfred… >> Bom, eu gosto de gatos. Tenho muitas camisetas de gatos. Deixa eu mostrar esta aqui. Então, enfim, continuo adorando o Spec Kit. Sim, versão 1.0, mas vou deixar a Nicole se apresentar. >> Claro. Claro. Claro. Claro. Meu nome é Nicole. Trabalho

04:02 remotamente, em Minnesota. Fico a umas 3 horas do Mall of America. Então, esse é um fato curioso sobre mim. E, como o Manfred, estou no setor há bastante tempo e tenho ajudado recentemente com o Spec Kit, o que tem sido muito divertido e interessante. Estou muito feliz de poder falar mais sobre isso hoje. >> Que legal! Eu não sabia. Também sou de Minnesota. >> É? Certo. [risos] Que ótimo. >> Sou originalmente do sul de Minnesota e depois morei nas Twin Cities. Então, definitivamente já comemorei alguns aniversários no Mall of America. >> Sim. >> [risos]

04:32 >> É um rito de passagem. >> Com certeza. [limpa a garganta] Com certeza. Então, vou abrir o repo para conversarmos sobre isso. Manfred, passo a palavra para você. O que há de mais recente e interessante no Spec Kit? >> Bom, como você já disse, a versão 1.0 foi lançada. Na verdade, já estamos na 1.2, mas lancei a 1.0 no dia do aniversário, porque achei que seria divertido.

05:04 Todos nós fazemos aniversário. Bom, o Spec Kit também fez aniversário. Então, pronto. Tem sido uma jornada bem intensa. Desde maio, quase dobramos o número de stars. Também dobramos com certeza o número de extensões que a comunidade está criando. O mesmo vale para as predefinições. O número de stars continua subindo. >> Vi que você tinha colocado o gráfico lá embaixo no README. >> Dá para ver isso acontecendo. Mas também aconteceram outras coisas importantes. Uma delas é que temos tentado entender do que a comunidade realmente precisa e o que ela quer. O principal é que, se você usa isso em equipe, introduzimos o conceito de predefinições para que você possa adicionar suas próprias coisas. Mas aí as pessoas perguntaram: “Certo, como eu empacoto isso agora?” Então,

05:34 criamos os pacotes. Essa é uma das adições mais recentes, para que você possa empacotar coisas. O empacotamento permite criar um conjunto validado de coisas, um conjunto validado de itens X, um conjunto validado de predefinições ou até mesmo de workflows. Sim, quero destacar que… >> Ah, certo. >> As pessoas… tínhamos trabalhado nisso. Agora temos cinco, então finalmente está começando a decolar também. E, anteriormente, durante esse

06:05 período entre maio e agora, não conseguíamos hospedar etapas de workflow, isto é, as etapas que fazem parte de um workflow. Agora, temos a mesma plataforma de hospedagem que as outras primitivas também têm. Isso significa que você pode, obviamente, criar suas próprias etapas, porque, embora haja 13 etapas principais, não sei de que outras etapas as pessoas precisariam. Então, você pode fazer isso. Agora, como a Sara está mostrando, a outra coisa que aconteceu foi

06:35 basicamente dizer: “Sabe de uma coisa? Há coisas que acontecem antes do SDD e coisas que acontecem depois do SDD.” O SDD ainda é uma parte muito importante do Spec Kit, mas também queríamos atender à etapa anterior: como avaliar uma ideia? Há uma extensão principal que permite dizer: “Ei, quero avaliar esta ideia com base em quanto ela se encaixa no projeto”, e assim por diante. Então, agora você tem a

07:07 possibilidade de fazer isso usando o mesmo tipo de guia. A ideia é boa — ou seja, vamos em frente? É uma ideia ruim — ou seja, vamos descartá-la? Ou preciso de mais esclarecimentos? Esse é basicamente o resultado final desse processo. O motivo para isso existir é que, antes, você teria que fazer muito mais preparativos e trabalho por conta própria. Um LLM geralmente consegue reunir todo tipo de informação, desde que você dê acesso a ela.

07:37 Então, na outra ponta… >> [risos] >> Sim, na outra ponta, temos a correção de bugs. Corrigir bugs normalmente não envolve um fluxo completo de SDD. Nesse caso, você quer avaliar o bug, corrigi-lo e depois testá-lo — testar para ver se a correção realmente resolveu o bug. É basicamente isso. E, como podem ver, o número quatro é criar seu próprio processo. É aí que entra a lista de recursos. Se a Sara rolar a página para baixo, vocês vão ver agora

08:09 isso. Tem muita coisa que dá para fazer. Mas tudo isso gira em torno do que estou tentando realizar, porque esse é realmente o ponto principal do Spec Kit agora: ele é mais kit do que spec, porque escolhemos deixar tudo aberto e queríamos ver o que vocês fariam com ele. Dito isso… >> Um segundo, vi pessoas no chat pedindo o primeiro episódio para poderem se atualizar. Então, aqui está um link curto

08:41 para vocês, caso queiram abrir e voltar ao começo. >> [risos] >> Hoje, vamos falar sobre o que mudou desde então. Mas, sim, vocês podem conferir o vídeo anterior ali. Certo, desculpe. Pode continuar. >> [risos] >> A outra coisa não é uma primitiva nova, mas sim um acréscimo ao workflow principal: a convergência. Ao analisar todas as extensões disponíveis, concluímos que faltava algo depois da implementação. Era basicamente perguntar: “A implementação foi feita, mas ela realmente seguiu a spec?” Se não, a convergência cria novas tarefas que a implementação precisa executar para se ajustar à spec, permitindo garantir que aquilo que foi especificado seja de fato seguido pela implementação. Isso surgiu, é claro, das extensões da comunidade que também tratavam disso. E isso não significa necessariamente que algumas das

09:11 Deixo o link aqui para você, se quiser abrir isto, voltar e começar do início. >> [risos] >> Mas hoje estamos falando do que mudou desde então. Mas, sim, você pode conferir o vídeo anterior ali. Certo, desculpe. Pode continuar. >> [risos] >> A outra coisa que não é uma primitiva nova, mas sim uma adição ao workflow principal, foi a convergência. Olhando para todas as extensões disponíveis, concluímos que faltava algo…

09:43 …depois da implementação: basicamente, dizer: “Tudo bem, a implementação foi feita, mas ela realmente seguiu a especificação?” Se não, a convergência vai criar novas tarefas que a implementação precisa executar para convergir com a especificação, o que permite garantir que tudo o que foi especificado seja realmente seguido pela sua implementação. Isso surgiu, obviamente, das extensões da comunidade que também abordavam essa questão. E isso não significa necessariamente que algumas das

10:13 As extensões da comunidade agora estão obsoletas nesse sentido. É apenas uma maneira diferente de encarar o processo. Sabe, o Converge faz isso de uma maneira específica. Algumas extensões da comunidade fazem isso de maneira um pouco diferente. E essa é realmente a força do Spec Kit também. É como: se você não gosta, faça do seu jeito. >> Acho que esse é um bom framework. >> Tem mais uma coisa, e ela é bastante experimental no momento. E também não está listada nos recursos, por isso.

10:44 E isso é o suporte a servidores. Então, a CLI do Spec Kit pode ser colocada no modo MCP. Aos poucos, ela vai ganhar a mesma [bufa] funcionalidade, para que você possa interagir com ela como parte de algo como um servidor MCP. Isso não é o foco do que pretendemos fazer aqui, mas é uma maneira de interagir com a CLI do Spec Kit usando MCP. Então, minha expectativa não é executar os comandos por meio desse servidor MCP, porque você…

11:15 sabe, obviamente os comandos ainda são os prompts que o agent precisa executar. Então, tenha isso em mente. >> Quero fazer uma pergunta sobre essa coisa de convergência. Basicamente, isso tenta garantir que quaisquer processos novos gerados estejam de acordo com os anteriores, com a spec em si. É isso? >> Sim. >> Qual é a diferença em relação a algo como…

11:45 ter prompts ou instruções para o agent em um repo? >> Bem, o comando de conversão é, por si só, um prompt, mas ele sabe como funciona a estrutura do Spec Kit. Então, o prompt de conversão diz: vou consultar o Spec Kit. Vou consultar o plano, as tarefas e a base de código e determinar se fui longe demais, se entreguei menos do que deveria, se quebrei alguma coisa. Esse tipo de coisa, nesse sentido específico. Então, o motivo de ele ser…

12:16 acrescentado apenas à tarefa é que precisa converter, sabe, é quase como um ciclo [bufa] em que você vai ajustando e refinando cada vez mais, e então… ou como um funil, ou como… sim, é mais ou menos isso. >> [risos] >> É por aí, certo? Então, essa é a abordagem. >> Sim. >> É… >> Hum… >> Legal. >> Então, tudo o que eu disse até agora obviamente faz parte do Spec Kit principal. E vocês talvez…

12:47 se perguntem por que não estou mostrando isso aqui. Bem, >> [limpa a garganta] >> uma das coisas que pensei ao olhar para o Spec Kit — e, sabe, estamos no GitHub. Então, temos acesso ao nosso Copilot e ao app do Copilot, certo? Eu queria pensar: “Como posso usar linguagem natural para controlar o próprio Spec Kit?” Essa foi a primeira coisa que eu queria experimentar, porque assim, “Ei, não preciso me lembrar dos comandos. Posso simplesmente conversar ou digitar…”

13:18 no… no meu app do Copilot e, sabe, ele vai simplesmente executar alguma coisa. Então, o que fizemos foi criar um repo separado, paralelo, chamado Spec Kit Copilot. O motivo é que o núcleo do Copilot — desculpe, o núcleo do Spec Kit — continua agnóstico em relação ao agent, como prometemos. Se você está usando o Copilot, sabe, esse repo específico vai ajudar a adicionar plugins específicos, presets específicos que…

13:50 vão melhorar sua experiência no Copilot. Um deles é justamente o plugin do Copilot, que permite controlar todo o Spec Kit usando linguagem natural. Assim, você não precisa se lembrar do que cada comando faz. Agora, basta pedir em linguagem natural para adicionar determinado preset e, por trás dos panos, a skill vai chamar a CLI do Spec Kit e executar tudo para você. Essa foi minha primeira tentativa de pensar: “Como posso melhorar a experiência com o Copilot?” Mas depois, sabe…

14:20 começamos a conversar e, sabe, Nicole e eu nos divertimos bastante falando sobre essas coisas. Então, começamos a pensar em como tornar tudo visual. E é aí que vou passar a palavra para Nicole, porque ela fez um trabalho incrível. >> Só uma pergunta rápida: quando vocês abordam esse tipo de discussão de design, quanto tempo isso leva? Vocês ficam numa sala e escrevem um monte de coisas num quadro branco? Usam o Spec Kit para trabalhar no Spec Kit?

14:51 >> [risos] >> Como é isso? >> No núcleo do Spec Kit, fiz isso com alguns recursos, mas lembrem-se de que é um projeto open source, então recebo muitos PRs e, obviamente, nem sempre sei se usaram o Spec Kit para desenvolvê-los, porque o PR não necessariamente inclui essa informação. E, se incluir, eu diria: por favor, removam, porque quero garantir que o repo continue limpo nesse aspecto, já que…

15:22 eu uso specs como algo, sabe, principalmente transitório, nesse sentido. Gosto de como o repo do Spec Kit descreve isso como um fluxo que segue adiante. Você entregou algo; cria uma nova spec para o novo trabalho, se ele for grande o suficiente. Se não for, então, sim, você não quer criar specs quando, sabe, a mudança é: “Ei, preciso…” Se, por exemplo, você estiver fazendo um app web e disser: “Ei, preciso mudar a cor do botão de alternância”, isso não é realmente uma spec, certo? Então…

15:53 mas, sim, geralmente conversamos pelo Teams, porque trabalhamos remotamente, e simplesmente discutimos as coisas. E, obviamente, depois experimentamos. Sabe, agora é muito mais fácil simplesmente dizer: “Quer saber? Vou dedicar um dia a isso”, e usar o LLM, orientá-lo e guiá-lo para ver onde chegamos. >> Mas, com certeza, tenho colocado… Sinto que, quando tenho vários projetos que vão parar na sua…

16:23 lista de coisas para ler, ou melhor, na lista de projetos para fazer, sim, ter o Copilot ou algum outro tipo de LLM trabalhando nisso em segundo plano enquanto faço outras coisas é definitivamente muito útil. Legal. Então, vamos passar para a Nicole, porque estou muito curiosa para ver como isso… Só para deixar claro: uso o Spec Kit praticamente desde que foi lançado. Lembro quando foi lançado; fiquei muito empolgada. Conversávamos sobre isso, eu falava sobre ele em conferências. Mas não o uso há alguns meses. Então, estou muito animada com esses novos… Quer dizer, preciso me sentar e ler todos os recursos e funcionalidades legais, mas, especialmente porque estou trabalhando mais com o Copilot, o que significa trabalhar com o Spec Kit e o Copilot? Então, vamos…

16:55 compartilhar sua tela, Nicole. >> Sim, claro. Você está me ouvindo bem? >> [limpa a garganta] >> Sim, estamos ouvindo. >> Ótimo. Então, primeiro eu queria mostrar o repo Spec Kit Copilot de que o Mom for falou. Se quiser saber mais, recomendo que venham conferir e leiam o README. O principal que quero destacar aqui é que ele apresenta os cinco plugins que adicionamos para o Copilot. O primeiro é aquele de que o Mom for falou bastante, chamado…

17:25 Spec Kit Copilot, que permite usar linguagem natural para controlar o Spec Kit. Vou mostrar isso agora mesmo. Os outros quatro têm mais foco no que se chama canvas app. Canvas apps são um recurso muito legal do app GitHub Copilot, que permite criar facilmente apps web para praticamente qualquer tipo de interface que você quiser. Então, usamos esse recurso para oferecer experiências visuais guiadas muito boas com o Spec Kit. Estamos muito animados para compartilhar isso…

17:57 com vocês.

18:27 hoje. Então, com isso, vou começar. >> Ah, desculpe. Continue. >> Uma pergunta do chat: isso é só para o Copilot? Então, como as pessoas podem trabalhar com o Spec Kit, considerando todas as opções? >> O núcleo do Spec Kit é obviamente agnóstico. As telas não são. Essas telas exigem o aplicativo Copilot. E o plugin do Copilot também, porque obviamente diz Copilot.

18:59 >> Faz sentido. Só queria ajudar a responder às perguntas do pessoal. >> Sim, sem problema. Então, mudei para a minha máquina. Espero que vocês consigam ver tudo direitinho. Este é o aplicativo GitHub Copilot. Se você não conhece, ele foi lançado, acho que por volta de junho ou julho. Ele é realmente voltado para o desenvolvimento com agentes em primeiro lugar usando o Copilot. E uma coisa ótima que vocês podem ver aqui no lado esquerdo é que dá para abrir vários repositórios ou projetos diferentes, o que permite alternar facilmente entre eles e ter várias sessões do Copilot

19:30 em execução, para que você possa se movimentar com bastante fluidez entre os diferentes projetos em que está trabalhando. Como podem ver, no painel à esquerda tenho alguns repos abertos agora. Tenho o repo do Spec Kit, e vou mostrar isso daqui a pouco com os aplicativos Canvas, mas a ideia por trás disso, certo, é que você pode usar o Spec Kit para manter o próprio Spec Kit, e fazemos isso em certa medida. Então, esses exemplos vão ajudar a demonstrar isso. E também tenho um projeto de rascunho, por onde vou começar, para dar uma ideia das skills subjacentes de que falamos, que você pode usar em linguagem natural

20:01 para conduzir o Spec Kit. Então, já tenho esses plugins instalados aqui, e é isso que habilita todas essas capacidades hoje. Mas vou usar a barra, e dar uma olhada em algumas das skills habilitadas pelo plugin de que falamos. Há várias skills ou, na verdade, comandos diferentes disponíveis, mas vou começar pelo Spec Kit init. Isso me permite inicializar o Spec Kit, certo? Então, eu poderia usar o comando com barra,

20:32 mas, de novo, para mostrar o uso de linguagem natural, vou simplesmente dizer: “inicialize meu projeto”. E, aliás, digitar e fazer uma demonstração ao mesmo tempo é sempre difícil, mas: “inicialize meu projeto com…” >> Nunca dá para digitar e falar ao mesmo tempo. >> É difícil, eu sei. Então, vou enviar isso. Vamos esperar um segundo, e devemos ver a skill ser carregada em segundo plano. Como podem ver, está carregando. O que está acontecendo é que ele está configurando meu projeto com o Spec Kit,

21:02 e, para deixá-lo pronto, o Spec Kit cria alguns arquivos de estrutura inicial. Enquanto ele começa a fazer essas alterações, também vamos colocar alguns desses arquivos no disco, para que vocês entendam melhor o que está sendo criado aqui. Isso deve levar só alguns segundos, e vocês podem ver que as alterações estão começando a acontecer. Mais uma vez, o aplicativo GitHub Copilot é muito útil porque permite ver exatamente o que está acontecendo. Vou expandir isso e depois vamos dar uma olhada nos arquivos no disco. Mas, antes disso, quero mencionar que a inicialização está

21:33 concluída e ele nos diz o que fazer em seguida. Basicamente, isso indica que ele está criando mais skills para me ajudar a conduzir o Copilot. Por isso, está dizendo que preciso recarregar as skills. Vou fazer isso. Outra coisa que ele está me dizendo é que preciso configurar uma constituição, que normalmente é uma das primeiras etapas do processo de desenvolvimento com o Spec Kit, para definir os princípios que vão orientar o trabalho. Vou seguir as instruções. Mas, como acabei de recarregar minhas skills, vou ver algumas

22:04 skills novas disponíveis. Tenho uma específica para criar uma constituição. De novo, para usar apenas linguagem natural, vou remover a barra e… vou copiar e colar algumas coisas, porque conheço minhas limitações para digitar durante uma demonstração. Vou copiar isso de um bloco de notas que tenho, mas, basicamente, estou configurando minha constituição e vou dar a ela um princípio orientador bem simples: para cada alteração, quero que sejam adicionados documentos e testes. Certo? E, no

22:34 mundo real, você teria mais princípios do que isso, mas, para a demonstração de hoje, vamos ficar com esse. Vou pressionar Enter e deixar o processo continuar. Vocês podem ver que ele está inferindo a skill subjacente. Enquanto isso acontece, quero dar uma olhada nos arquivos que foram criados. Falei sobre a criação da estrutura inicial que acontece com o Spec Kit. Ao criar essa estrutura, ele também cria skills adicionais para ajudar a conduzir o workflow padrão de desenvolvimento orientado por especificações do Spec Kit. E aqui vocês podem ver aquela

23:05 skill de constituição que acabamos de usar. Ela também inclui skills para cada uma das fases do processo de desenvolvimento orientado por especificações, começando pela especificação e indo até a implementação. É assim que essas skills são criadas. Também quero destacar que, na pasta specify, são criados todos os artefatos das diferentes fases do pipeline em que você está. Por exemplo, agora a nossa constituição está sendo criada, então vou dar uma olhada nela.

23:36 Vou abrir este painel; espero que vocês consigam ver. Esta é a constituição que ele acabou de criar, e vocês podem ver, nos princípios fundamentais, que ele adicionou o que especifiquei na janela do chat, certo? Ou seja, é preciso ter documentação para cada alteração e também é preciso ter testes. Então, é isso que o plugin Spec Kit para Copilot permite fazer: usar linguagem natural para conduzir esse processo. Se você quisesse continuar, certo, seguiria então para a fase de especificação

24:07 que permitiria avançar pelo restante do pipeline. Mas era isso que eu queria mostrar com o plugin do Copilot. A próxima coisa são os aplicativos Canvas. Não sei se há alguma pergunta; se não, vou mudar de assunto. Certo, vou fazer uma pausa. >> [risos] >> Sim, tivemos uma ótima pergunta da Amy aqui. Que desafios vocês encontraram quando… Então, esta é obviamente a parte específica do Copilot, mas como vocês

24:39 fizeram para separar quais partes deveriam ser agnósticas em relação ao agente de programação? E, ao criar skills e essas constituições, como isso se relaciona com o panorama mais amplo da IA? >> O núcleo do Spec Kit sempre foi agnóstico. Isso significa que, ao executar o Spec Kit para inicializar seu projeto, você indica qual agente de programação

25:10 quer usar. Se você tiver o Copilot, especifica o Copilot. Se tiver o Claude ou o Codex, especifica um deles. E ele gera as skills apropriadas para aquele conjunto específico de agentes. Agora, você pode usar vários agentes no projeto. Mas precisa especificar quais vai usar e alternar entre eles. O principal é que o diretório que a Nicole mostrou, o .specify, contém os comandos, porque é lá que fica o Spec Kit

25:40 a terminologia de uma skill; os comandos estão lá. Quando você diz que quer criá-las a partir de um modelo, elas são criadas no diretório do seu agent de programação. Assim, tudo continua completamente independente de agent, porque, quando alguém entrega uma extensão, ela é entregue de forma independente. Quando é instalada, ela cria um arquivo de skill para aquele agent de programação. >> Isso é muito legal, porque, se você tem pessoas na equipe usando diferentes agents de programação, ainda mantém o mesmo conjunto de instruções principais,

26:13 mas elas são adaptadas para cada agent de programação, certo? >> Certo, certo. E esse plugin específico do Copilot se baseia nisso. Então, é uma estrutura em camadas bem legal, que vai subindo. O plugin do Copilot é a próxima camada e, obviamente, os canvases que Nicole vai mostrar agora são a camada acima dessa. >> Certo. Legal. Boa pergunta, Amy. Sim, vamos falar dos canvases. Eu

26:44 adoro canvases. Tenho feito vários; tenho quase certeza de que faço de dois a cinco por dia. Eu sou >> [risos] >> super… Só para explicar para quem talvez ainda não tenha experimentado o aplicativo para desktop, compartilhei links nos comentários para mostrar como obtê-lo. Vou colocá-los aqui mais uma vez também. Basicamente, os canvases são uma forma de… Bem, em certo sentido, são um navegador incorporado, mas muitos aplicativos agora têm esse conceito. Eu

27:16 sei que o Slack tem canvases; diferentes ferramentas de comunicação também têm. É como uma tela em branco agradável, uma forma de compartilhar algo além de apenas texto de um chat ou algo assim. Eu costumo usá-los para criar dashboards o tempo todo, porque trabalho com ciência de dados. Então, adoro um bom dashboard. Mas estou especialmente curiosa para ver como isso funciona com o Spec Kit. >> Sim, então decidimos criar três

27:48 canvases para workflows predefinidos. Como eu disse, este é um exemplo de usar o Spec Kit para gerenciar o Spec Kit, porque fazemos isso. E esses workflows são bastante úteis para gerenciar o Spec Kit. Por isso, vou mostrar esses canvases no contexto do repo do Spec Kit. O primeiro que quero mostrar é o canvas de desenvolvimento orientado por especificações. Novamente, ele corresponde ao workflow padrão que o Spec Kit oferece. No entanto, como Mumford disse, você pode personalizar completamente o Spec Kit e ter flexibilidade para criar o pipeline que quiser. E os canvases adicionais vão mostrar isso daqui a pouco. Mas, para o desenvolvimento orientado por especificações, é assim que fica uma interface de usuário sobre essas skills. Ela oferece uma experiência guiada agradável entre as diferentes etapas, para que você não precise necessariamente saber qual skill usar em seguida. A linguagem natural ajuda, claro, mas isso ajuda ainda mais, certo? Para quem prefere uma abordagem visual. Vou mostrar o aplicativo rapidamente. Tenho alguns indicadores aqui em cima que mostram

28:19 os diferentes estados em que estão as várias instâncias de workflow que executei. Tenho apenas um workflow, que é o que está no meio, de um recurso que comecei a desenvolver. É isso que esses números mostram: em que etapa estou. No início, você também pode ver que é possível consultar sua constituição. Eu já criei a minha. Você pode acessar e ver esse artefato, se quiser. Também pode criá-la ou atualizá-la, se precisar. Vou iniciar o specify, porque sei que vai demorar um pouco e espero que termine,

28:50 mas vou copiar e colar um ID de recurso que veio da nossa comunidade. Escolhi uma issue meio aleatória que vi hoje. Mais uma vez, usando o Spec Kit no Spec Kit. Vou clicar no botão para executar o specify. E você pode ver na janela de chat o que está acontecendo. Vou prosseguir. Acho que talvez já tenha executado isso antes, então espero que não cause problemas, mas o que devemos ver é que ele vai então

29:21 invocar a skill specify que existe por baixo para executar esta etapa, usando o prompt adicional que forneci com a descrição do recurso. Depois disso, ele executa a etapa specify e me guia pelas próximas etapas do pipeline, conforme necessário. Aqui, você pode ver que, nesta instância que já existia, executei o specify e depois passei para as etapas de planejamento e tarefas. Acho que parei na checklist. Mas, para dar uma ideia, vamos abrir uma delas. Posso acessar uma dessas etapas que já foi executada

29:51 e ver o artefato. Este é o meu plano de implementação que foi criado. Vou passar por ele rapidamente. E também… Desculpe, voltando ao plano: você também pode acessar aqui e executar novamente uma etapa. Se quiser fornecer contexto adicional, pode fazer isso. Mas, sim, você seguiria as etapas como faria normalmente, só que usando uma interface de usuário. É assim que funciona. Os outros dois canvases que queria apresentar rapidamente

30:22 são… Há o canvas de avaliação de ideias. Manfredi falou sobre as duas extensões que adicionamos recentemente, e esta é uma delas. Ela oferece um pipeline totalmente diferente do processo integrado que vai da especificação à implementação. Este começa com uma ideia, depois pesquisa e define a ideia, dá forma a ela e, por fim, chega a um parecer: avançar ou não avançar. No meu caso, criei algumas instâncias de workflow

30:53 em que comecei a percorrer essas etapas. Por exemplo, nesta, você pode ver que passei por todas as etapas e, no fim, recebi uma decisão. Se olharmos o artefato, ele diz que preciso de esclarecimentos. Portanto, ainda não me deu uma decisão de avançar ou não avançar. Se eu rolar mais para baixo, vocês verão que ele precisa de mais contexto. Outra funcionalidade muito legal do Copilot é uma ferramenta integrada que permite solicitar informações adicionais, e o Copilot pode fazer isso. É isso que está sendo usado aqui. Então, há

31:23 perguntas que preciso responder aqui. Depois que enviar as respostas, posso executar novamente essa etapa. Então, é assim que funciona o pipeline de avaliação. O terceiro… Ah, sim, você queria dizer alguma coisa? >> Sim, quero garantir que as pessoas entendam que isto é uma visualização. Os comandos são executados pelo Spec Kit. Portanto, se você não tem o aplicativo do Copilot, pode gerar os mesmos artefatos usando o Spec Kit, da forma que sempre usou. >> Sim, bem lembrado. O terceiro canvas que queria mostrar é o de correção de bugs. Mais uma vez, esta é outra extensão de que Momford falou. Ela faz a triagem de um bug, começando pela etapa de avaliação e, supondo que seja um bug válido — que é basicamente o parecer a que ela chega —, você pode seguir para a correção e testá-la neste repo. Mais uma vez, escolhi um bug real do nosso

31:55 …perguntas que preciso vir aqui e responder. Depois que envio essas respostas, posso executar novamente essa etapa. Então, é assim que funciona, mais ou menos, o pipeline de avaliação. A terceira… Ah, sim, você queria dizer alguma coisa? >> Sim, quero garantir que as pessoas entendam que esta é a visualização. Os comandos de fato são executados pelo Spec it. Então, se você não tiver o aplicativo Co-pilot, pode gerar os mesmos artefatos usando o Spec it, sabe, da maneira de sempre.

32:25 >> Isso mesmo, é um bom ponto. E o terceiro aplicativo canvas que eu queria mostrar é o de correção de bugs. Mais uma vez, esta é outra extensão sobre a qual Momford falou, que basicamente faz a triagem de um bug, começando pela fase de avaliação e, supondo que seja um bug válido — porque esse é, basicamente, o veredito a que ela chega —, você pode prosseguir para a correção e testá-la de fato neste repo. Mais uma vez, escolhi um bug real do nosso…

32:55 repositório e começou a passar pelo fluxo de avaliação. Então é isso que vemos aqui no meio. Se olharmos de novo para a fase de avaliação, você pode visualizar este artefato e, aqui no topo, ver o veredito, certo? Que, de fato, é um bug válido no repositório. Então poderíamos continuar com a correção e a fase de testes. Espero que isso dê uma ideia de como você pode criar uma experiência mais guiada usando canvases. Há um quarto canvas

33:26 que quero mostrar, mas ele é diferente dos três primeiros. Nós o chamamos de canvas de assistente. A ideia por trás dele é que seja mais genérico e voltado à exploração. Ele permite que você examine todas as diferentes predefinições disponíveis nos vários catálogos. Temos um catálogo integrado, um específico do Copilot e também predefinições contribuídas pela comunidade. Você pode percorrer todas elas e escolher quais instalar.

33:57 Da mesma forma, você pode fazer o mesmo com as extensões. Como podem ver, instalei algumas — na verdade, uma extensão aqui. Instalei a extensão do fluxo de avaliação de ideias, que é a mesma que acabei de mostrar no canvas e também a mesma extensão de que Momford falou. Vamos mostrar como ela aparece no assistente. A ideia é que você possa instalar as personalizações que quiser para adaptar o fluxo ao seu cenário e ao seu processo, certo?

34:28 Dito isso, vou passar para a aba de fases. Essa aba permite que você monte seu fluxo e depois o execute e experimente. Se lembram, eu disse que usei a extensão de avaliação de entrada. Essa extensão tem os comandos mostrados aqui embaixo, certo? Começa com entrada, passa para pesquisa, depois definição… Acho que é enquadramento e, então, definição e decisão. Você pode modificar esse fluxo aqui em cima. Você

34:59 pode remover comandos diferentes. Também pode adicionar outros. O que fiz aqui foi incluir os comandos que me interessam especificamente para o fluxo de entrada. No final, adicionei a fase de especificação, porque esse é mesmo o próximo passo depois de chegar a um veredito sobre sua ideia. Então, mais uma vez, a intenção é que esta seja uma ferramenta para você montar seu fluxo, visualizá-lo e, depois, executá-lo aqui para experimentar as etapas. Eu já o executei,

35:31 mas, se olharem, queria mostrar a especificação, porque eu a executei. Se visualizarmos o artefato aqui, estas são as especificações criadas com base na ideia original que inseri no início do fluxo. Outra coisa que vou mencionar é que tenho uma predefinição divertida instalada. Manfred criou essa predefinição, e ela se chama fala de pirata. Isso mostra como as predefinições podem modificar seu fluxo da maneira que você quiser. Essa predefinição específica, chamada fala de pirata, basicamente gera todos os seus artefatos como se fossem escritos por um pirata,

36:02 certo? Como se estivesse escrevendo. Se olharem algumas das palavras usadas aqui, verão que tudo segue o espírito de um pirata. >> [risos] >> Então, mais uma vez, isso só mostra as personalizações que vocês podem fazer com o Spec Kit. Alguma pergunta sobre isso? Caso contrário, tenho mais uma última coisa para mostrar, se tivermos tempo suficiente. >> [limpa a garganta] >> Eu só queria esclarecer algo para o pessoal também. Quando a Nicole falou sobre o fluxo aqui,

36:33 vocês podem, obviamente, adicionar coisas e removê-las. Mas o principal é que aquelas predefinições da parte de configuração anterior são onde vocês podem adicionar suas próprias funcionalidades, porque foi ali que ela selecionou a predefinição de fala de pirata. Se vocês têm maneiras padronizadas de trabalhar, é ali que podem fazer isso: criam sua própria predefinição e, então, podem dizer: “Ei, agora quero montar meu fluxo. Ah, preciso de uma etapa específica que o núcleo do Spec It não

37:04 faz. Tudo bem, posso criar uma extensão e adicioná-la ao meu fluxo.” >> Isso. >> [fungada] >> Há várias pessoas perguntando no chat. Sim, o Spec It é um projeto open source, e muito do que estamos mostrando aqui nos canvases — acho que praticamente tudo — depende do Spec It, que executa esses processos e comandos por trás, certo? >> Isso mesmo. >> Sim.

37:34 >> E o projeto específico do Copilot também é open source. Então vocês podem ver como ele foi desenvolvido. >> Sim, mesmo que não usem o Copilot, tudo bem. Ainda podem aproveitar tudo o que há de legal no Copilot. Talvez existam maneiras legais de criar canvases ou algo parecido no seu IDE de IA favorito. O que adoro nisso é uma boa comunidade que dá suporte a modelos ou maneiras de as pessoas compartilharem como usam uma

38:05 ferramenta. Vocês têm uma página da comunidade ou algum lugar onde as pessoas possam encontrar — talvez eu possa encontrar — todas essas configurações legais? >> Na verdade, fica no site do Spec It Core, no site da documentação. Lá haverá uma aba da comunidade em que as pessoas podem clicar. O conteúdo é categorizado por área: extensões, predefinições, workflows e

38:36 assim por diante. Também temos uma página de amigos. É lá que as pessoas podem listar projetos que usam o Spec It, porque esse é o requisito, mas que são amigos dele. Por exemplo, quem criou uma interface de terminal em torno do Spec It é nosso amigo. >> Entendi. Certo, legal. Vou compartilhar alguns links no chat para vocês. Já deixei aberto o link do repo principal. Acho que isso responde à maioria dos comentários em aberto por enquanto.

39:08 >> [risos] >> Obrigado, Cole. Sim, só queria mostrar mais uma última coisa. Eu diria que, neste momento, ela ainda é bastante experimental. Todas as funcionalidades que mostrei até agora já foram incluídas no repo do GitHub Copilot, então vocês podem acessá-las hoje mesmo. O que vou mostrar agora ainda não está disponível. Ainda estamos trabalhando nisso e, se tudo der certo, esperamos incluí-lo no repo do Copilot mais adiante. Mas, por enquanto, queria pelo menos mostrar para onde estamos caminhando.

39:38 Mais uma vez, estou com o assistente aberto, e ele é praticamente idêntico ao que mostrei antes. No entanto, a principal diferença é este novo botão na página de fases, chamado “gerar canvas”. A ideia é que vocês possam montar o fluxo que quiserem, de acordo com o processo de vocês e com as predefinições e extensões necessárias instaladas. Depois de montar o fluxo, podem clicar em “gerar canvas” aqui, e ele vai gerar o app de canvas para vocês, sem que precisem criá-lo manualmente, como fizemos.

40:10 E então, é um ótimo exemplo de como você pode pegar todos esses metadados ricos que estamos acumulando no wizard e depois passá-los para o Copilot criar este app. Para fazer isso, o botão «Generate canvas» permite abrir o que chamamos de designer de canvas, e vou abri-lo agora. Isso vai levar alguns segundos, porque na verdade vai criar uma sessão aninhada, que veremos aqui no painel à esquerda, abaixo do wizard. Então, leva um tempinho. Depois, ele passa todos aqueles metadados do wizard de que falei

40:41 para que possa gerar o canvas ou deixá-lo pronto para geração. Para ganhar tempo, eu já tinha aberto esse designer de canvas antes. Daqui a pouco, provavelmente veremos uma segunda instância aparecer enquanto isso está sendo processado. Sim, dá para ver aqui: há uma sessão aninhada sendo criada. Mas é assim que o designer de canvas ficaria. O objetivo dele é permitir que você configure alguns campos obrigatórios. Por exemplo, o ID do canvas, que é o nome do arquivo do seu app de canvas. Você também precisa fornecer um título. Mas incluí alguns campos básicos que você pode usar para personalizar um pouco mais o app de canvas gerado. Por exemplo, você pode fornecer uma descrição. Também pode definir o cabeçalho. Como mostramos os badges antes, há diferentes regras de badges que você pode especificar para que eles apareçam. Para a aparência, há algumas configurações gerais aqui, mas uma das mais interessantes é poder adicionar seu próprio logo, por exemplo. Por fim, quando terminar de configurar esses ajustes básicos,

41:13 você pode vir aqui e escolher gerar um app de canvas. Mais uma vez, ele se baseia nos metadados que você já configurou no wizard e os passa para cá, aplica apenas essas personalizações básicas e, então, gera um app de canvas para você. Para mostrar um exemplo que gerei, mais uma vez, ele segue o pipeline de avaliação de correção de bugs de que já falamos bastante hoje. Este é o aspecto do app gerado. Eu não estava muito satisfeita com os badges enquanto fazia os testes, mas dá para ver os

41:44 diferentes badges que adicionei no designer. Dá para ver meu logo e a descrição personalizada que incluí no nome do cabeçalho do workflow. Fora isso, o comportamento é o mesmo. Por baixo, ele usa o Speckit para chamar as skills de que falamos e fazer a triagem do bug, passando pelas etapas de avaliação, correção do bug e teste. Enfim, achamos muito legal poder usar o Copilot para gerar um app de canvas com todos aqueles metadados do wizard. E só mais uma coisa: nós

42:14 também decidimos deixar isso ainda mais personalizável. Se você quiser avançar e adaptar ainda mais seus canvases às suas necessidades — porque talvez aquelas configurações básicas que disponibilizei no designer não sejam suficientes —, você pode usar presets e extensions do Speckit para personalizar ainda mais o app gerado. Para mostrar um exemplo, criei um preset que pega a exibição horizontal deste controle e a exibe na vertical. E também

42:46 usa o modo autopilot. É assim que o app fica. Os metadados são exatamente os mesmos. Tudo é igual, exceto pelo preset que apliquei, que muda o layout do controle. Aqui, dá para ver que as etapas são as mesmas, mas estão na vertical, e o app é executado no modo autopilot. Então, é só inserir seu bug e deixar o processo rodar. Enfim, são algumas coisas legais que estamos experimentando e queríamos compartilhar. >> Ah, sim, estou muito animado para testar

43:17 isso, porque sou uma pessoa muito visual e gosto muito de dashboards. Acho incrível termos um jeito de… Não me entenda mal, a CLI é ótima. Era assim que eu usava o Speckit antes. Isso é totalmente incrível. Também estou curioso para conhecer aquele projeto da comunidade que dá isso… Você disse que é meio que uma GUI para a CLI. Eu também gosto dessas coisas. Mas acho que, principalmente com o quanto dá para personalizar, você realmente consegue fazer

43:47 com que pareça ser o seu projeto. São os seus workflows. E, quando novas pessoas chegam para trabalhar com você, não sei, tudo parece mais bem-acabado. É como personalizar de verdade um template de site para que ele pareça o site do seu projeto, em vez de ficar igual a todos os outros, sabe, um daqueles três templates básicos de um gerador. Isso é muito legal. Estou animado com isso. Vou dar uma olhada. Se você tiver

44:18 alguma pergunta, pessoal, deixem no chat. Estou acompanhando. >> [limpa a garganta] >> Sim, acho que um dos principais assuntos no chat é o pessoal tentando entender quais partes aqui são específicas do Copilot e quais não são. Acho que… >> É relativamente fácil saber: se está na especificação do repo do Copilot, é específico do Copilot. Se não está no

44:49 núcleo, porque não transferimos nada para o núcleo. O núcleo continuou sendo o núcleo, e a parte do Copilot está literalmente naquele repositório. Quero destacar para quem estiver interessado em algum desses novos fluxos que, sim, dá para fazer na linha de comando exatamente o mesmo que a Nicole mostrou na interface. A única diferença é que você não tem aquela interface bonita. E, sim, o designer e os wizards não estão disponíveis para você, porque são específicos do uso do Copilot, já que exigem o canvas e a capacidade de gerá-lo e depois exibi-lo enquanto se usa o Copilot.

45:20 Tenho que dizer que foi muito interessante conversar sobre como projetamos isso. A parte final, em especial, ainda não foi incluída no repo. Essa foi a maior questão: como pensamos nisso? Você pode gerar o app, mas depois ele fica estático.

45:52 Então, como podemos incorporar conceitos semelhantes para que as pessoas possam gerar o app no próprio estilo, com os requisitos necessários? Perguntei à Nicole se era possível usar presets, porque essa foi literalmente uma pergunta que fiz a ela. E pensamos: vamos descobrir. >> Sim. O preset que criei é esse. Quando você abre o designer, pode aplicar esse preset, e o designer o instala enquanto gera o

46:23 canvas. Legal. >> Ah, certo. Na verdade, quando expliquei isso, o designer executa um workflow do Spec-it para fazer isso, porque, caso contrário… >> Sim. >> não funcionaria. >> Isso mesmo. Toda essa funcionalidade vem empacotada na própria extension, como você pode ver aqui. Ela precisa ser instalada, porque é onde tudo isso fica. Depois, como eu disse, você pode substituir o comportamento usando presets e mais extensions, se quiser. Alguém levantou uma questão interessante. Eu…

46:54 …canvas. Legal. >> Ah, certo, na verdade, provavelmente, quando eu explicar isso, o designer executa um workflow do Spec-it para fazer aquilo, porque, caso contrário… >> Sim. >> Não funcionaria. >> Isso mesmo, toda essa funcionalidade vem empacotada na própria extensão, e você pode ver isso aqui. Ela precisa ser instalada, porque é lá que tudo isso fica; depois, você pode substituir o comportamento com presets e mais extensões, se quiser. Então, alguém levantou uma questão interessante, eu…

47:24 Não sei se isso vai ser exibido direitinho, porque é uma pergunta mais longa, mas acho que a ideia geral é o uso de tokens e trabalhar com o Spec Kit. Houve alguma consideração sobre como ser mais eficiente nisso? Acho que uma coisa interessante de usar alguns desses workflows é que >> [limpa a garganta] >> não preciso fazer como quando crio muitos canvas.

47:55 Para mim, são muitos tokens para ficar indo e voltando e mudar cores, mudar alinhamentos das coisas. E poder ter predefinições que, acho, economizem um bom número desses tokens. Mas, sim, como vocês pensaram nisso ao projetar o Spec kit? >> Bem, o design do Spec kit obviamente começou com um workflow SDD decorativo. É… >> O que é SDD, para quem não sabe? >> Ah… >> Desenvolvimento orientado por especificações.

48:26 >> [risos] >> Desenvolvimento orientado por especificações. >> Sim. >> Sim. Então, o workflow principal obviamente gera muitos arquivos, porque você está tentando definir contratos de API. Você faz pesquisas. Depois, obviamente, cria a especificação com base nisso tudo, precisa planejar e criar o plano de implementação, e então cria a lista de tarefas que realmente precisam ser feitas. Agora, sim, uma das coisas que fizemos quando introduzimos as predefinições foi pensar: certo, para um recurso pequeno…

48:57 …que parece bastante grande. Então, existe uma predefinição chamada lean preset, que cria apenas três arquivos: a especificação, o plano e as tarefas. Sim, essa opção consome bem menos tokens, mas também é menos especificada, porque você não tem os contratos de API. Você não vê a pesquisa; obviamente, o LLM fez alguma coisa, mas não a formalizou em um arquivo. Certo, então tudo depende do quanto você precisa e do quanto sua organização exige que você especifique certas…

49:29 …coisas. Agora, se você está falando de uma coisa pequena, um recurso pequeno, então, sim, use a lean preset, certo? Porque ela é bem mais enxuta — na verdade, é consideravelmente mais enxuta. Agora, há certas coisas que você precisa saber? Sim. Ela não faz certas coisas que o núcleo original faz, e isso é intencional. Mas também é uma demonstração de que, se você quiser influenciar como o processo funciona, pode criar sua própria predefinição…

49:59 …e dizer: “Sabe de uma coisa? Não quero contratos de API, mas quero todas as outras coisas que acontecem.” Certo? Substitua e decore com uma predefinição. E você pode fazer isso. Agora, qual era a segunda pergunta? Desculpe, acabei me perdendo um pouco… >> Acho que era mais ou menos isso: se você se preocupa com o uso de tokens enquanto usa o SpecKit, acho que você respondeu muito bem ao que queríamos saber. Hum…

50:32 Houve outra pergunta interessante: acho que os componentes internos do SpecKit são escritos em Python. Sou Pythonista. Não tenho problema com isso, mas qual foi parte da decisão de design em relação a esse tipo de escolha de arquitetura? >> Não consigo responder a essa pergunta, porque saí quando Dan deixou nossa empresa. Então, por que ele escolheu Python? Provavelmente porque se sentia à vontade com a linguagem. [risos]

51:03 Sabe, e obviamente você não vai arrancar os alicerces debaixo das pessoas. Então, sim, Python tem que ficar. >> [fungada] >> Quer dizer, algo que sempre digo às pessoas, já que uso Python como minha linguagem principal há uns 15 anos, é que ela é a segunda melhor linguagem para tudo. Provavelmente, para qualquer tarefa, é como um canivete suíço. Então, para uma tarefa específica, talvez exista uma opção melhor e mais [limpa a garganta] ideal em termos de velocidade ou algo assim.

51:36 Mas, quando preciso de uma biblioteca para alguma coisa, ela já existe em Python. >> [risos] [limpa a garganta] >> Do ponto de vista de criar coisas, acho que Python é uma linguagem… e não quero me gabar, mas também tem uma comunidade ótima. Então, [risos] qualquer projeto que possa aproveitar essas comunidades vai se beneficiar bastante. Somos muito acolhedores. >> E vale apontar que, obviamente, quando você executa os comandos de verdade, Python…

52:07 …não está em ação. Aí, quem entra em cena é o agent, que simplesmente raciocina sobre o prompt que recebe e, então, sobre qualquer ferramenta que tenha à disposição. Pode ser uma ferramenta em Python que ele chama. Pode ser um script de bash. Pode ser um script de PowerShell que ele chama. Aí depende do que o comando especifica. >> Sim. Basicamente, eles são totalmente desacoplados. Você usa isso para gerar suas especificações para o desenvolvimento orientado por especificações. E então usa essas especificações, sabe? Eu…

52:38 …com certeza, antes de conhecer o SpecKit, já me sentei e escrevi muitos documentos de especificação. E, a menos que você tenha modelos da empresa ou algo assim, isso pode dar muito trabalho em tempo integral. Então, [risos] é ótimo poder começar com uma estrutura inicial e depois ajustá-la conforme necessário. Então, foi por isso que fiquei tão animado com o SpecKit desde o início, porque pensei: >> [fungada] >> podemos ter algo para conversar…

53:08 …que já está pronto, sabe? Posso ativar e desativar recursos se não precisar dos contratos de API e coisas do tipo. Posso simplesmente desativá-los. Então, sim. Recomendo muito, principalmente se você estiver começando projetos novos. Experimente o SpecKit. Veja como ele ajuda você a pensar nas coisas. Acho que também pode, às vezes, levar as pessoas a pensar em coisas que elas… >> [limpa a garganta]

53:40 >> É de manhã. >> [risos] >> Coisas que talvez as pessoas não estejam considerando por completo ao projetar um projeto. Sei que isso definitivamente me ajudou a pensar: “Ah, existe uma interface aqui, e preciso detalhar melhor quais são as regras em torno dela.” Então… >> Isso se conecta àquela ideia da extensão de avaliação, porque, antes de implementar algo, ela também pergunta se é algo que você deveria mesmo fazer. Mas o legal…

54:10 >> [risos] >> …de todo esse processo é que ele realmente faz perguntas para esclarecer as coisas. Você pode ignorá-las completamente, claro, mas é interessante ver essas perguntas, porque ele pergunta: “Você considerou isto? Considerou aquilo?” E você pensa: “Ah, opa, deixei passar alguma coisa.” E essa é a questão quando falamos de uma ideia: você realmente pensou em tudo que está envolvido no que está pedindo para ser alterado aqui? E isso…

54:40 …é algo que, sabe, se você está trabalhando em vários projetos, nem sempre é fácil. E, sim, se você entrar e puder simplesmente dizer: “Sabe de uma coisa? Este é um issue que foi aberto. Vamos ver: ele realmente se encaixa na base de código ou é algo que devo contestar?” >> Uhum. Sinto que é como ter um gerente de projetos de bolso. >> [risos] >> Ajuda você… Já fiz um pouco de trabalho de gerente de projetos…

55:12 …não é meu forte, mas entendo muito bem o valor de ter um ótimo gerente de projetos quando se trabalha num projeto. Muitas vezes, essa pessoa é quem faz perguntas como: “Precisamos mesmo fazer isso agora? Pensamos nisso?” Então, sim, acho que é uma estrutura muito legal para aproveitar LLMs e ajudar você a desenvolver seus projetos. >> É engraçado você chamar de Pocket o LLM… Desculpe, Pocket PM, foi mal.

55:43 >> [risos] >> Sim, quer dizer, sinceramente, eu realmente recomendaria usar, se você é PM. Sabe, você pode personalizar, assim como a parte de SDD. Também pode personalizar com seus próprios presets para isso. Então, se você pensa: “Ok, esse processo não segue totalmente a forma como eu gostaria que fosse feito”, na verdade, você pode ajustá-lo. Agora, obviamente, os que estão atualmente no fluxo de avaliação estão lá. Você precisa executar

56:15 todos eles? Não, mas isso obviamente depende de como você vê o seu próprio processo. Ou seja, sim, começamos como Spec Kit. Sabe, agora ele realmente se tornou um kit de processos. >> [risos] >> Uma pessoa aleatória — sinto que talvez eu tenha que contribuir com isso como algo da comunidade —, mas eu costumava trabalhar com dispositivos médicos e com os processos de software e requisitos. Lá, era como um fichário com todas as coisas que você tinha que verificar sempre que alguém fazia uma alteração no código, para garantir que todas aquelas regras

56:47 fossem seguidas. Parece algo perfeito para isso. Tipo, eu entregaria esse manual ao Spec Kit e diria: “Me ajude a criar um preset que, quando fizermos alterações no código, garanta que estamos seguindo todas essas etapas”. Então, >> Engraçado você mencionar isso. Bem no começo da minha carreira, trabalhei com um setor mais regulado. Por acaso, era o VA. Eles têm o que chamam de modelo NEEM

57:19 para intercâmbio de informações. Então, sim, eu simplesmente criei os presets para isso, porque pensei: “Sabe de uma coisa? Vamos ver se consigo fazer isso”, e depois ver o que ele faz. É muito interessante ver. Não vou tentar convencer todo mundo a usar isso nem nada, mas, se você tiver interesse, dê uma olhada nos meus repositórios pessoais, porque isso também é algo que sempre quero destacar. Sou apenas mais um membro da comunidade, como todo mundo, quando se trata de

57:50 extensões e presets. Sabe, estamos experimentando e, obviamente, graças à comunidade, que adoramos, podemos ver o que dá certo e o que não dá, porque, quanto mais extensões, presets, bundles, workflows, etapas de workflow e canvases forem surgindo, mais poderemos ajudar uns aos outros. >> Sim. Essa é uma das minhas coisas favoritas na comunidade open source:

58:21 sim, podemos falar sobre todas as coisas legais que isso faz, mas você também pode personalizar e adicionar coisas novas por conta própria. Pode ver como elas funcionam. Sabe, não é uma espécie de caixa-preta mágica. Então, quando algo acontece — no meu caso, geralmente sou eu que quebro alguma coisa —, isso me dá a oportunidade de, antes de incomodar um monte de gente, ir ver o que fiz de errado. >> [risos] >> Então, sim, com certeza, se você tiver algum interesse nesse projeto, dê uma olhada no repo de qualquer um dos dois.

58:53 Temos o Spec Kit. Esse é o repo principal para as partes que não dependem de um coding agent específico. E, basicamente, o backend computacional propriamente dito da integração do Spec Kit com o Co-pilot, que oferece várias opções legais no aplicativo Co-pilot e em outras ferramentas do Co-pilot para aproveitar os recursos agnósticos. Então, não há exatamente recursos especiais ou coisas adicionais. São apenas maneiras de fazer o Spec Kit funcionar bem no

59:24 Co-pilot. Espero que essa seja uma descrição precisa. Então, vou encerrar com uma pergunta divertida. >> [limpa a garganta] >> Qual é o seu sabor de sorvete favorito? >> Pistache. >> Pistache. Certo. É uma ótima escolha. >> O meu seria massa de cookie. >> Massa de cookie. Sim. >> E o seu? >> O meu, bem,

59:58 normalmente seria algo como sal marinho ou caramelo com sal marinho. Mas, sem querer fazer propaganda >> [risos] >> da Salt & Straw, que é uma rede nos EUA, eles têm um sabor de Halloween agora chamado graveyard cookie crumble, que é realmente o melhor sabor de sorvete que já provei. Estou fazendo de tudo para não ir lá literalmente todos os dias deste mês, porque ele sai do cardápio no fim do mês. >> [risos] >> Estou pensando seriamente em comprar muitos

1:00:28 potes e encher meu freezer com eles. >> [risos] >> Mas é um chocolate amargo bem intenso com cookies, porque eu adoro quando tem aquela crocância de cookie. E tem espirais de chocolate branco vermelho-vivo, porque é um cemitério. Enfim. >> [risos] >> Bem, muito obrigado por se juntarem a mim, Manfred e Nicole. >> Sim, obrigado. >> Você. >> E obrigado a todos por estarem conosco online e por assistirem à gravação depois. Vocês sempre podem acompanhar mais

1:01:00 Open Source Fridays. Estamos aqui praticamente toda sexta-feira. Acho que é literalmente opensourcefridays.com. >> [risos] >> E vocês podem conferir todo o nosso catálogo. Estou ansioso para experimentar todo tipo de novidade do Spec Kit nesta semana e também ver o que vem a seguir para o projeto. E espero que algumas das pessoas que acompanharam a conversa no chat se tornem contribuidoras das próximas iterações. Seria muito legal. Fica a ideia. >> Uhum. >> [risos] >> Enfim, tenham todos um bom dia e nos vemos na próxima.

1:01:31 >> Obrigado. >> Tchau.

Transcrição original

[01:17] [music]

[01:59] >> Woo! >> Well, welcome, welcome everybody to Open Source Friday. Uh really excited. We have some really cool a really cool project today and some really awesome guests that I’m really I am definitely excited to talk about talk with. Um it’s also Friday, so happy Friday. Um but yeah, so quick uh point of note, GitHub Universe is coming up. Uh My name is Sara Kaiser. I work at GitHub.

[02:30] Uh and yeah, you can check out um the our our kind of big conference where we’re announcing all kinds of new stuff um from everything from the github.com platform to Copilot, all of our tooling is going to be super fun and you can register for free online. So, um it’s a great way to kind of stay on top of what’s going on at GitHub. All righty. So, I am going to bring on

[03:01] our friends for today. Um we will be talking so we uh Hey friends. Uh we talked about SpecKit on our previous episode with Manfred. Um and so today we’ve got uh Manfred who is a principal software engineer at GitHub as well as Nicole Hougen who’s also a principal software engineer [laughter] at GitHub uh to talk about uh not only the 1.0 release of SpecKit, but kind of

[03:32] what’s changed since the last time we talked. So, um yeah, if you want to if there’s anything else fun you want to tell folks about yourself, Manfred. >> Well, uh you know, I like cats. I have a lot of cat shirts. Let me actually show you this one. So, uh so uh you know, anyway, um yeah, still loving SpecKit. Uh you know, yes, uh 1.0, but uh me let give Nicole introduce herself. >> Sure. Sure. Sure. Sure. Uh yeah, my name is Nicole. Um I work

[04:02] remotely from Minnesota. Um so, I’m about 3 hours from Mall of America. So, just a little fun fact about myself. Um and like Manfred, I’ve been in the industry for a long time, and I’ve been helping out with Spek-It recently, which has been really fun and interesting. So, so happy to talk more about that today. >> That’s awesome. I didn’t know that. I am also from Minnesota. >> Are you? Okay. [laughter] Great. >> Originally from southern Minnesota, and then from the Twin Cities. So. Uh I definitely have been had had a couple birthdays at the Mall of America. >> Yeah. >> [laughter]

[04:32] >> It’s a rite of passage. >> Indeed. [clears throat] Indeed. So, uh yeah, let’s um I’m going to pull up the repo so we can chat about this. But, Manfred, I’ll I’ll throw it to you. Um what uh what’s the what’s the latest and greatest on Spek-It? >> Well, as you already uh said, you know, um version 1.0 is out. Uh you know, we’re actually already at 1.2, but uh you know, at on the birthday date, I actually uh released 1.0 because I thought that would be fun, you know. Uh

[05:04] we all we all turn an age. Well, Spek-It turned an age, too, you know. So, there we go. Um yeah, it’s been actually quite a wild ride. I mean, since May, uh you know, we have doubled our numbers in stars almost. Uh you know, we doubled definitely the number exte- of extensions that our community is delivering. Presets are in the same way. Um you know, yeah, the star count is going up. >> I saw that you had the plot at the bottom of the read me earlier. >> See that happening. Um

[05:34] but, you know, there’s other things that obviously have happened that are of note. And one of the things that uh you know, we we’ve been trying with Spek-It uh is to see what the community actually needs and wants. Uh the biggest thing there is, you know, if you’re using it in a team, you know, the you know, we introduced the concept of presets for that so that you can actually layering your own stuff. But, you know, come you know, folks were like, “Okay, well, how do I bundle this now?” So, there you go. We

[06:05] created bundles, you know, so that’s the one of the later editions so that you can actually bundle stuff and bundling allows you to, you know, create you know, uh a vetted set of things, vetted set of X-things, vetted set of presets or even workflows. Yeah, I do want to call out that >> Ah, okay. >> folk. We had done work for it. Now, we have five, so that one is finally getting off the ground as well. And then, previously, you know, during that

[06:35] era that between, you know, May and now, we we’re not able to actually host workflow steps, which is the steps within a workflow. Now, we actually have that same hosting platform that all the other primitives has have as well. That makes it so that, you know, obviously can introduce your own steps cuz even though there are 13 core steps, you know, I don’t know what kind of other steps folks would need. So, you do have the ability to do that. Now, as Sarah’s right now showing, the other thing that happened is

[07:07] basically saying, “You know what? There are things that happened before SDD and there are things that happen after SDD.” Um SDD is still the big still a very big part of Spec-it, but you know, we also wanted to say cater to the stage before and that is, you know, how do you assess an idea? So, there is a core extension that allows you to just say, “Hey, I want to assess this idea on the merit of how does it fit the project?” And so forth and so on. So, you have the

[07:37] ability now to do that in same kind of guide. You know, is the is this idea good, and meaning go, is this an idea bad, meaning kill, or is does do I need more clarification? And that’s basically the end result of that process. But, you know, the the reason why it is there is obviously, you know, uh previously you would have to do a lot more machinery and a lot of work yourself. An LLM is typically capable of pulling all kinds of information together if you just give it access to it.

[08:09] So, on the far end >> [laughter] >> Yeah. On the far end we obviously have bug fixing, you know, so bug fixing is not normally a whole SDD flow, uh you know, so there you want, you know, hey, uh assess the bug, fix the bug, and then test the bug, you know, test as in did the fix actually fix the bug. So, that’s basically that one. And then as you can see, number four is uh well, create your own process, you know, and that is where the capability list comes in that we, you know, so if uh Sarah scrolls down there you now you can see

[08:41] that. There’s a lot of stuff in there that you can do. Uh you know, uh but that’s all geared towards what am I trying to accomplish, you know, cuz that’s the key thing really with Spec It Now, it’s more kit than spec, uh you know, because [laughter] we went the route of opening it up and we wanted to see what y’all would be doing with it. And so, having that said, >> One second, I saw people in chat asking uh for the first episode uh to to catch up. So, I’ve got a short

[09:11] link for you here uh if you want to open this and go back and start from the beginning. >> [laughter] >> But, cuz today we’re we’re talking about what’s changed since then. But, uh yeah, you can check out the previous uh video there. All right, sorry. Go ahead. >> [laughter] >> The other thing that uh uh it’s not a new primitive, it’s uh actually a addition to the core workflow, and that was convergence. Uh looking at all the extensions out there, uh and you know, we concluded that there is there was something

[09:43] missing after implement and that was basically saying, “Hey, implement implemented, but did it actually adhere to the spec?” If it didn’t, it convergent will actually create new tasks that implement needs to go do to converge onto the spec, which allows you then to, you know, make sure that whatever was specified is actually adhered to by your implementation. So, that was, you know, came out of obviously all the community extensions that were around that as well. And that doesn’t necessarily mean that some of the

[10:13] community extensions are now obsolete in that sense. It’s just a different way of looking at the process. You know, converge does it a particular way. Some of the extensions in the community does it do it slightly different. And which is that’s really the strength of Spec it as well. It’s like, if you don’t like it, make it your own. >> I think that’s a good framework. >> There There is one other thing and that one is highly experimental at the moment. Um And it’s also not listed in the capabilities, that’s why.

[10:44] And that is server support. So, the Spec it CLI can be turned into MCP mode. It will slowly actually gain the same [snorts] functionality so that you can then interact with it as part of an MCP server kind of thing. It’s not the core of what we intend to do here, but it is, you know, a way of being able to interact with the Spec it CLI using MCP. So, my anticipation there is not actually running the commands through that MCP server because, you

[11:15] know, obviously the commands are still the prompts that the agent needs to execute. So, be aware of that. >> So, I want to ask a question about the convergence thing. So, that’s basically trying to help make sure any new processes are that are generated adhere to the previous adhere to the actual spec. Is that correct? >> Yeah. >> How does that differ from something like

[11:45] having prompts or agent instructions in a repo? >> Uh well, the the conversion command is is is a prompt in a in in and of itself, but it’s it it it actually would knows about the Spec It machinery. So, the conversion prompt I’m going to go look at Spec. I’m going to go look at the plan, and I’m going to look at the task and the code base and determine did I overreach? Did I under deliver? Uh did I break something? That kind of thing in that in that particular sense. So, the reason why it’s

[12:16] append only to the task is because it needs to convert like, you know, it’s almost like the you know, a loop [snorts] where you go slide make that tighter and tighter and then you’re actually or a funnel or how how yeah, that’s that’s kind of >> [laughter] >> that way, right? So, that’s the >> approach. >> Yes. >> Uh >> Um >> Cool. >> So, now everything that I’ve said obviously is core Spec It. Uh and you all might

[12:47] wonder why I’m not calling this here. Well, >> [clears throat] >> one of the things that I looked at Spec It and you know, we’re at GitHub. So, we have access to our co-pilot and co-pilot app, right? Um so, I wanted to think about, “Hey, how can I actually drive Spec It itself in natural language?” So, that’s the first uh thing that I wanted to see because that would actually, “Hey, I don’t have to remember the commands. I can just, you know, either chat or type

[13:18] in the in in my in my co-pilot app and then, you know, it will just execute something. So, what we did there is, you know, create a separate sibling repository that is Spec It Co-pilot. The reason being is is that, you know, the core of Co-pilot I’m sorry, the core of Spec It stays agent agnostic, as we promised. If you’re on the Co-pilot side of things, you know, that particular repository will help you actually layer in, you know, specific plugins, specific specific presets that

[13:50] will make your experience in Co-pilot better. One of them being indeed the Co-pilot plugin that allows you to just drive Spec It completely in natural language. You know, so that you don’t have to remember what does this command do. Now, you can just say add this particular preset in natural language and underneath the covers the skill will actually call call Spec It CLI and then just execute it for you. That was my first foray in like, hey, how can I make the Co-pilot experience better? But then, you know,

[14:20] we started talking and you know, Nicole and I uh uh had a lot of fun talking about stuff and we were thinking about now, well, how can you actually make things visual? And that’s where I will hand it off to Nicole cuz she did some amazing work there. >> Quick question though, when you approach these sort of design sort of discussions, like how how long does that take? Do you sit in a room and just like write a bunch of stuff on a whiteboard? Do you use Spec It to work on Spec It?

[14:51] >> [laughter] >> What what does that look like? >> For the core of Spec It, there are some features I’ve done that, but remember it’s an open source project, so I get a lot of PRs in, you know, and obviously I don’t know necessarily when they’re whether or not they used Spec It Spec It to deliver it because the PR doesn’t necessarily contain that. You know, and if it does contain it, I would say please scrub it because I want to make sure that the repository stays, you know, clean in that regard cuz

[15:22] I used specs as uh, you know, uh, mostly transient in that sense. I I like what the in the spec it uh, the repository is described as flow forward. So, you’ve delivered something, you create a new spec for the new work if it’s that large. If it’s not that large, then yeah, I mean, you don’t want to create specs if, you know, the change is hey, I need to if you say for instance doing a web app, hey, I need to create a different color for a toggle button. Button, that’s not really a spec, right? So, um,

[15:53] but yeah, uh, mostly over Teams cuz we’re both remote and uh, you know, we would just talk things through and, you know, uh, obviously then try things out, you know, uh, it’s a it’s a lot easier now to just say, you know, what? I’m just going to give it an a day and you know, help help throw the LLM at it uh, and steer and guide it and see where we’re at. >> But, uh, I have definitely been throwing like I feel like when I have had a bunch of projects that go on the like your

[16:23] to-be-read list, but like to-be to-be-done projects, uh, yeah, having having Copilot or some other sort of LLM to just kind of cook on that in the background while I work on other things is uh, definitely pretty helpful. Uh, cool. So, I’m going to we’re going to swap over to Nicole then cuz I’m really curious how this um, like so, I full disclaimer, I have used spec it uh, for basically since it launched. I remember when it launched, I

[16:55] was I was super excited. We were talking about it. I was telling folks that about it at conferences. Um, but I haven’t used it in the last couple months. So, like I’m really excited about these kind of new I mean, I I need to sit down and read through all of the cool new features and capabilities, but especially since I am working more with Copilot, what does it mean for for what does it mean to work with Spec it and Copilot? So, I’m going to we’re

[17:25] going to share your screen, Nicole. >> Yeah, sounds good. You can hear me okay? >> [clears throat] >> Yep, we got you. >> Okay, perfect. Okay. Yeah, so I wanted to first just show the the Spec it Copilot repo that Mom for talked about. So, if you want to learn more, I definitely encourage you to come come check this out and look through the read me. The key points that I want to call out here is is this talks about the five plugins that we’ve added for Copilot. The first one is the one that Mom for talked about quite a bit with this

[17:57] called Spec it Copilot and so this is what enables you to use natural language to drive Spec it. I’m going to show that right away today. And then the other four are more are more focused on what’s called a canvas app. And so canvas apps are really cool feature in the GitHub Copilot app that allow you to easily create web apps for really any type of UI that you want. And so we’ve used that capability to provide really nice visual guided experiences over Spec it. So, we’re really excited to to share that

[18:27] today. So, with that I’m going to go ahead. >> Oh, sorry. Keep going. >> I’m question from chat. Is this only for Copilot then? So, kind of how how can people work with Spec it then? With all the options. >> The core of Spec it is obviously agnostic. The canvases are not. This canvases require the Copilot app. And so does the the Copilot plugin because obviously it says Copilot.

[18:59] >> Makes sense. Just wanted to help answer folks’ questions. >> Yeah, no worries. So, yeah, I switched to my machine. Hopefully you can see this okay. This is a GitHub Copilot app. In In you’re not familiar with it, um, was released, I want to say in the June-July timeframe. Really, it’s geared towards agent first development with Copilot, and so, um, the great thing that you see over here on the left-hand side is you can open up multiple different repositories or projects, which allows you to easily switch, you know, in between them and have multiple different uh Copilot

[19:30] sessions running, um, so that you can just, you know, move very fluidly between different projects that you’re working on. And so, you can see in my left-hand pane, um, I have a couple of repos open right now. I have the Spec It repo, um, and I I’ll show that in just a moment with the canvas apps, but the spirit behind that, right, is is that you can use Spec It to actually, um, maintain Spec It, and we do that, um, to some degree. So, those examples will kind of help, uh, show that. Um, and then I just have the scratch one that I’m going to start out with and just kind of give you a feel for what the, um, underlying skills are that we talked about that you can use natural language

[20:01] with, uh, to drive Spec It. Um, so, yeah, I already have those plugins installed here, so that’s what’s enabling all the all these capabilities today. Um, but I’m going to go ahead and use the forward slash, um, and just take a look at some of the, uh, skills that are being enabled through this plugin that we talked about. Um, so, there’s quite a few different, uh, you know, skills or commands, really, uh, that you have available to you, but I’m going to just start with the Spec It init one. Um, so, this this allows me to initialize Spec It, right? And so, I could use the forward slash command, uh,

[20:32] but again, just to show off the natural language, I’m just going to say, you know, initialize my project. And I typing in a demoing is always hard, by the way, but initialize my project with >> You never type and talk at the same time. >> tough. I know. So, I’ll I’ll go ahead and, uh, and enter that. And we’ll just give it a a second here, but we should see it, um, load that skill here behind the scenes. And so, yeah, you can see it’s loading. And so, what this is doing, right, is it’s setting up my project with Spec It,

[21:02] and so, there’s certain files that Spec It, uh, scaffolds to basically get that ready. Um, as it starts to make these changes, we’ll go ahead and get some of those files on disk too just so you get a better understanding of really what’s what’s being scaffolded here. This should just take a few seconds to run and you can see changes are starting to happen. So again, the GitHub co-pilot app is really helpful so you can view exactly what’s happening. So I’ll expand this and then we’ll take a look at the the files on disk here. But before we do that, I just want to mention here so the initialization is

[21:33] done and it tells us what to do next. And so it basically alludes to the fact that it actually is scaffolding more skills to help me drive co-pilot. And so that’s why it’s saying you need to reload the skills. So I’m going to go ahead and do that. And then the other thing it’s telling me is that I need to set up a constitution which is typically kind of the first step in in your spectrum and development process so that you have your your governing principles in place. So I’m going to go ahead and follow the instructions there. But again, because I just reloaded my skills, I’ll see some

[22:04] new skills that are available to me. So I have one specifically for creating a constitution here. Again, in the spirit of just using natural language, I’m going to get rid of the forward slash and let’s just uh I’m going to copy and paste some stuff cuz I know I know my limitations with typing and demoing. So I’m going to copy this out of a notepad I have but this is basically setting up my constitution and I’m just going to give it a really really simple governing principle and say that for every single change, I want docs and tests added. Okay? And you know, in the

[22:34] real world you’d have you know, more principles than this but for the demo today, that’s what we’re going to stick with. So I’ll go ahead and press enter here and we’ll just let it go. You can see here again it’s inferring the underlying skill. And while it’s doing that, I want to take a look at the files now that have been created. So I talked about the scaffolding that happens with SpecFlow Kit. And so when it’s doing that scaffolding, it’s actually creating additional skills for you to help drive that default SpecFlow driven development process workflow. And so you can see here, here’s that

[23:05] that constitution skill that we just used. And it also includes skills for each of the phases for the spec driven development process starting with the specification going all the way through implement. So these are these are how those skills get created. And then here I also want to point out in the specify folder, this is where all of the artifacts from the different pipeline phases that you were on, this is where they get created. So for example, right now we’ve got our constitution being created and so I’m going to go ahead and take a look at it.

[23:36] And I’ll open up this pane so hopefully you can see it. But this is the constitution that it just created and you can see under the core principles that it it added what I I specified in the chat window, right? So that you have to have documentation for every change and likewise you have to have tests. So yeah, so this is this is what the spec to code pilot plugin allows you to do is is to use natural language to to drive this process. And so if you were going to keep going, right? You would then continue on with the specify phase

[24:07] which then would allow you to progress through the rest of the pipeline. But yeah, so that’s that’s what I wanted to show with just the the co-pilot plugin. The next thing is the canvas apps. I don’t know if there’s any questions but if not I’ll just kind of switch gears. Okay. I’ll pause. >> [laughter] >> Yes, so we had a great question from Amy here. So what challenges did you run into like when we’re So this is obviously the the co-pilot specific piece but how did you

[24:39] go about trying to kind of separate what fit what parts should be agnostic coding agent agnostic and when you’re building skills and kind of these constitutions, how do you like how does that work with with kind of broader AI landscape? >> Um so the core of Spec it always has been agnostic. So what what it what it means is that when you’re running the Spec of IC to actually initialize your project, you you say I want this particular coding

[25:10] agent. So if you have Copilot, you specify Copilot. If you have Cloud or Codex, you would specify that. And it actually would generate appropriate skills for that particular agent set. Now, you can actually use multiple agents in the project. But then you just have to specify which ones you use and you have to switch between them. So the key thing really is is that the directory that Nicole showed where that the dot specify is, you’ll notice that the commands, cuz that’s the Spec it

[25:40] terminology for a skill, the commands are there. Once you actually say you want to scaffold them, then they get scaffolded into the directory of your coding agent. So that way it stays completely agnostic because when someone delivers an extension, they deliver it agnostically. When it gets installed, it would create a skill file for that coding agent. >> That’s super cool because then if you have folks on your team that are using different coding agents, you still have the same kind of core instructions,

[26:13] uh but they kind of translate to each different coding agent, right? >> Right, right. And and and this particular Copilot plugin actually builds on top of that. So it’s actually the it’s a really nice layering that goes, you know, up. So the Copilot plugin is the is the next layer and then obviously the canvases that Nicole now is going to show is the layer on top of that. >> Okay. Cool. That Great question, Amy. Yes, so let’s uh Canvases. Let’s talk about canvases. I

[26:44] love canvases. I’ve been making them like I’m pretty sure I make two to two to five canvases a day. I am >> [laughter] >> super So just to explain to folks who maybe haven’t tried out the the desktop app I have shared links for how to get that in in the comments. I will also throw it up again one more time. But basically canvases are a way to um I mean in in some sense they’re an embedded web browser, but they basically a lots of apps now have this concept. I

[27:16] know Slack has canvases different kind of communication tools have them, but it’s just like a nice blank canvas as a way to share you know something more than just text from a chat or something like that. So I tend to find myself using them to make dashboards all the time cuz I’m a data science person. So I love a good dashboard, but yeah, I’m especially curious to see what that kind of looks like for Speckle. So >> Yeah, so we we decided to create three

[27:48] canvases for predefined workflows. And so again, like I said this is kind of an example of using Speckle to manage Speckle cuz we we do do that. And these workflows are very applicable to managing Speckle. So that’s why I’m going to show these canvases within the context of the Speckle repo. But yeah, so the first one I just want to start with is the spec-driven development canvas. Again, this is for like that default workflow that that Speckle provides. However, as Mumford said you can fully customize Speckle and have the flexibility really create whatever pipeline you want. And then and so

[28:19] that’s what the additional canvases will show here in just a second. But for the spec-driven development one, this is what a UI on top of those skills looks like. And so it really provides, you know, that nice guided experience between different phases so that you don’t necessarily have to know you know which skill to to use next. You know grant granted natural language helps, but but this even helps even more, right? If you’re kind of that visual person. So just to walk you through the app really quickly, um I’ve got some badges here at the top that basically show you

[28:50] kind of different states of where um different workflow instances I’ve run are at. And so, I only have one workflow, that’s what’s in the middle here, of a feature that I actually started running through. And so, that’s what these counts reflect here is where I’m at. Um at the beginning, too, you can see that you can actually view your constitution. And so, I already created mine. You can come in and view that artifact if you want to. Um and if you needed, you could also create or update it. Um I am going to go ahead and just kick off specify cuz I know it’ll take a little bit and hopefully it’ll it’ll

[29:21] actually finish, but um I’m just going to copy and paste a feature ID that actually comes from our community. I just picked a kind of a random issue that I saw today. Um again, using Speckit on Speckit. Uh and I’ll go ahead and just uh hit this run specify uh button here. And you can see in the chat window um that what’s happening here. And uh let me just go ahead. I think I might have run this before, so hopefully it doesn’t cause a problem, but um but what we should see here, right, is is it’s going to actually then

[29:51] invoke that specify skill um that exists underneath to then uh basically execute this phase with the the additional prompt that I provided there with the the feature description. And so, then once I do that, um it’ll run the specify phase and then it’ll lead me basically through the next steps of the pipeline as needed. And so, you can see here with this existing one, um I ran specify, um I then went to the planning phase tasks, and I I think I stopped at checklist. But, if we just open one of these just to give you a feel, um I can come in

[30:22] here for one of these phases that already ran and I can view the artifact. So, this is my my implementation plan that got created. Just scrolling really quickly. Um and then also uh sorry, going back to the plan. Um you can also come in here and and rerun a phase. So, if there’s additional context that you want to provide, you can certainly do that. Um but yeah, you would just kind of work your way through the phases as you normally would, but um, all using a UI to do that with. Uh, so that that’s what this looks like. Um, the other two canvases that I wanted to provide or an overview of really

[30:53] quickly is uh, there’s this idea assess canvas. And so um, Manfredi talked about there’s these two extensions that we just added recently and this is one of those, right? So um, it gives you an entirely different pipeline than the the uh, built-in spec through implementation process, right? This is uh, taking an idea and then researching it, defining, shaping, and then finally coming up with a verdict of a a go or no-go decision. Um, and so in my case I’ve created a couple um, of workflow instances here

[31:23] where I’ve started to run through um, those steps. Uh, so for example, this one you can see I’ve actually ran through all those different phases um, and ultimately I I did get a decision. Um, and so if we look at that artifact, um, it actually says that I need uh, clarification. So it didn’t even give me a go or no-go decision yet and that’s because if I scroll further down, you’ll see that it actually needs more context. Um, and so this is a really another cool feature of Co-pilot is is there’s a tool underneath that allows you to ask for additional information that Co-pilot can do that with and so that’s what this is leveraging. Um, so there’s there’s

[31:55] questions I need to come in here and answer and then once I submit those answers, I can rerun the stage. Um, So yeah, that’s that’s kind of how the uh, the assessment pipeline works. Um, the third one, oh yep, did you want to say something? >> Yeah, I I want to make sure that people understand that this is the visualization. The actual uh, commands are run by Spec it. So if you do not have the Co-pilot app, you can get the same artifacts generated by using, you know, the

[32:25] Spec it, you know, the way you always have. >> Yep, that’s a good point. Um, and then the third canvas app I wanted to show is the bug fix one. Again, uh, this is another one of the extensions that Momford talked about um that basically triages a bug um starting with the assess phase and then um assuming it’s a valid bug cuz that’s um basically kind of the verdict that it arrives at. Um then you can go on to fix and actually test it within this repo. Um so again, I I picked um an actual bug from from our

[32:55] repository and started to run through the assessment pipeline. So that’s what we see here in the middle. Uh so if we look at the assess phase again, you can view this artifact and um at the top here, you can see here’s that verdict, right? That it’s it is in fact a valid bug in the repo. Um so we could then go on and and and continue with the fix and the the test phase. Um so yeah, so hopefully this gives you an idea of like how you can actually create a more guided experience um using canvases. Uh there is a fourth canvas

[33:26] that I want to show you, but it’s different from the the first three. Um and this is what we call our wizard canvas. Um and the whole spirit behind this is that this is really meant to be more general purpose and for exploration. Um so it allows you to basically peruse all the different presets that we have available across the different catalogs. So we have a built-in catalog, we have a Copilot-specific one, and then we also have community-contributed presets. And so you can come and scroll through all of these and choose to install them. Um

[33:57] likewise, you can do the same thing for extensions. And so you’ll see actually I’ve actually installed a few, so um or actually one one extension here, but I installed the idea assessment pipeline, which is the same extension I just showed in the canvas, and also the same extension that Momford talked about. So we’ll we’ll show how this shows up in the the wizard. Uh but the idea here, right, is is that you can come in and install um whatever customizations that you want to tailor the pipeline to your scenario and your process, right?

[34:28] Um so with that said, I’m going to jump to this phases tab. And this phases tab is what allows you to really build up your pipeline and then actually execute it and try it out. Um so if you remember like I said I did the the intake assessment extension and so um this this extension has the commands that are shown down here, right? It starts with intake, it then goes to research, uh then define I think it’s shape and then define and then decide. Um and so you can actually modify this this pipeline up here. You

[34:59] can remove um different commands. Uh you can come and then add additional ones. And so what I’ve done here is I have added the commands that that I’m interested in specifically for the the intake pipeline. Um and at the end of this I actually then added the specify uh phase because that’s really the next step once you uh reach your verdict for your idea. Um so again this this is just uh meant to be a tool for you to build up your pipeline, visually see it, and then you can come in here and actually execute the pipeline and try out the steps. Um so I’ve I’ve already executed

[35:31] it but like if you look at um I wanted to show you specify cuz I did run this. Uh if we view the artifact here, uh this is the actual specs then that were created based on the original idea that I put in at the beginning of the pipeline. Uh the other thing I’ll just mention too is is I I have a fun preset installed. Manfred actually created this preset but it’s called pirate speak. Um and so this really shows how presets can, you know, modify your pipeline to however you want. And so this this particular preset called pirate speak uh basically outputs all of your artifacts as though it’s a pirate,

[36:02] right? Uh uh writing it. And so like if you look at some of the the verbiage being used here it’s it’s all in the spirit of a pirate. >> [laughter] >> So again it’s just really showing off, you know, the customizations that you can do um with with Spec Kit. Um so yeah so any questions about that because otherwise I have one more final thing I wanted to show if we have enough time. >> [clears throat] >> Um >> I just want to clarify something for folks as well. When when Nicole talked about the pipeline here,

[36:33] you know, you can put things in there and take things out, obviously. But the key thing is is that those presets that were on the previous in the setup side, that is where you can layer in your own functionality because that’s where she actually selected that pirate speak one. So, you know, if you have standardized ways of working, you know, that’s where you would do that and you create your own preset and then you would be able to say, “Hey, I want to now construct my pipeline. Oh, I need a next particular thing that the core of Spec It doesn’t

[37:04] do. Okay, I can create an extension and then layer that into your pipeline.” >> Yep. >> [snorts] >> Um I’m going to there is a number of folks asking in chat. Yes, this is So, Spec It is an open source project and a lot of the stuff that I think pretty much everything we’re showing here in the canvases are tied to basically Spec It is underlying running these processes and commands, right? >> It is. >> Yes.

[37:34] >> And and and the Co-Pilot specific project is also open source. So, you can see how this was built out. >> Yeah, so even if you don’t use Co-Pilot, that’s totally okay. You can still leverage everything cool about Co-Pilot. Maybe there are cool ways to make canvases or something similar in your favorite AI IDE. Um but that’s what’s awesome about I love good community kind of like supported like templates or or ways that basically folks can share how they’re using a

[38:05] tool. Um do you have a community page or like a a place where people can maybe find maybe I can find it uh find all these cool um configurations? >> Um it’s actually on the website of the for the Spec it core you know it’s the documentation website and then there will be a community tab there that folks can click on and they were they’re categorized by area so you would have one for extensions, one for presets, one for workflows and so

[38:36] forth and so on. And we also have a friends page. That’s where folks can list their project that uh does use Spec it cuz that’s kind of the requirements but it’s friend to it. So folks that actually created terminal UI for instance around Spec it you know so that’s a friend of ours then. >> Got it. Okay, cool. Yeah, I I’ll share some links in chat for folks and I’ve got the link to the main repo up right now. But yeah, I think that addresses most of the current open comments so.

[39:08] >> [laughter] >> Thanks to Cole. Yeah, it was just one last thing then that I wanted to show and this is this is what I would say is probably extra experimental at this point. All the functionality that I’ve showed you so far is actually checked in to the GitHub Copilot repo so you can access that functionality today today. What I’m about to show now is not yet. We’re still working on it and if all goes well you know we’re hoping to eventually you know get it into the the Copilot repo. But for now I just at least wanted to show you kind of where we’re headed with things.

[39:38] So again I have the wizard open and it looks pretty much identical to what I showed you to before. However, the key differences is there’s this new button on the phases page called generate canvas. And so our idea is is is that you can build up whatever pipeline you want right according to your process with the presets and extensions that you need installed. And then once you have that pipeline built up you can come in here and click generate canvas and it will actually generate that canvas app for you so that you don’t have to manually create it like we did.

[40:10] And so it’s it’s a you know great example of where you can take all this rich metadata that we’re building up in was the wizard and then hand it off to co-pilot to build this app. And so to do this um the generate canvas button um allows you to launch what’s called the canvas designer and I’ll just go ahead and and launch that. Um this will take a couple of seconds um to do because it’s actually going to create a nested session um that we’ll see here in the left-hand pane underneath the wizard. So that takes a little bit of time to do that. Um and then it hands off all that metadata that I talked

[40:41] about from the wizard so that it can then generate the canvas um or get it ready for generation. And so in the interest of time I did go ahead and uh basically pre-launch this canvas designer. Um we’ll see a second instance probably spin up here in just a second um as this is working. Yeah, you can see that here there’s the nested one that’s creating. Um but yeah, so this is what the canvas designer would look like and really what it’s meant to do is is that there’s a couple of required fields you do need to set. So like the canvas ID which is the name of the file, right for your canvas app. Uh you also do need

[41:13] to provide it a title. Uh but then I just provided a few basic fields um that you can use to kind of customize the generated canvas app just a little bit more. Um so for example, you can provide a description. You can also provide like the header. Um there’s also, you know, we showed badges before. There’s uh different badge rules that you can specify to have those appear. Um and then for the appearance, there’s some um general settings here but one of the more interesting ones, right, is being able to add your own logo for example. And then finally when you’ve just kind of finished setting up those basic

[41:44] settings, you can come in here and choose to generate a canvas app. And again, it’s it’s based on that metadata that you’ve already configured in the wizard and passes it to this, applies just these basic customizations to it, and then outputs a canvas app for you. And so to show you an example of one that I actually generated, um again, this is following the bug fix assessment pipeline that we’ve we’ve already been talking about throughout a lot today. Um but this is what the generated app looks like and I I wasn’t really happy with the badges cuz I was testing it out. But uh but you can see these are the

[42:14] different badges I added to the designer. You can see my logo. You can see my custom description that I put in the workflow the workflow header name. But beyond that, you know, the behavior is just the same. It’s driving Speckit underneath to call those skills that we talked about to do the bug triage where you go through assess, bug fix, and test. And so anyway, so we thought this was really cool that you could, you know, use Co-pilot to basically generate a canvas app from all that metadata from the wizard. And just one more quick thing is is we

[42:46] also decided to make this even more customizable. Like if you really wanted to get advanced and make your canvases even more customized to your needs because, you know, just assume those basic settings I exposed in designer aren’t enough for you. You can actually use Speckit preset presets and extensions to further customize the actual app that gets generated. And so just to show you an example of that is I created a preset that takes this horizontal display of this control and instead displays it vertically. And also

[43:17] use autopilot mode. And so that’s what this app looks like. So it’s the exact same metadata. Um Everything’s the same except I applied this this preset that changes the control layout. And so here you can see it’s it’s the same steps but it’s vertical and then this runs in autopilot mode. So you can just put in your you know, your bug and let it run. So anyway, it’s just just some cool things that we’ve been trying that we wanted to share. So >> Oh yeah, no I am super keen on trying

[43:47] this out because I’m dashboard very visual person and I think it’s really awesome that we have a way to Don’t get me wrong, the CLI is great. That’s how I was using Speckit before. Um That is totally awesome. And I’m actually kind of curious to check out that community project that gives it You said it’s kind of like a GUI for the CLI. So, I do also like those. But, yeah, no, I think especially with how much you can customize this, like you can really make

[44:18] it feel like it is it is your project. These are your workflows. Like, um and so when you have new people come in and join you, like it I don’t know. It feels it feels polished. It’s like when you take and actually customize a website template, and so it looks like your project’s website and not just like every every other, you know, one of three basic templates for a a generator. So, that’s super cool. I’m excited about that. Um I’m going to take a look if you have

[44:49] any questions for folks, uh please make sure to put them in chat. Uh I’ve been watching. Um but yeah. Um >> [clears throat] >> Yeah, I think kind of one of the main main threads from chat is folks trying to understand which which pieces here are Copilot specific and which are not. So, uh I think we’ve >> It’s relatively easy to to know if it’s in the in the spec of Copilot repo, it’s Copilot specific. If it’s not in the

[45:20] core, cuz the core we we didn’t bleed it over. So, the core stayed the core, and the Copilot side is literally in that repository. Now, I do want to call out for for folks that you know, obviously are interested in any of those new flows. Yes, you can just do the same thing that Nicole was showing in the UI completely on the command line. The only difference is is obviously you don’t get that nice UI around it. Uh you know, and yes, the designer and the wizards are not available to you because that’s

[45:52] really specific to Copilot use because it requires the canvas and the ability tend to generate the canvas and then show it, you know, while using Copilot. Um I I do have to say it was really interesting when we had conversations cuz you know, asking about how we designed this, you know, is something that um especially the last part that isn’t checked in yet, that was really the the biggest one is like how do we how how do we think about, you know, you can generate the app, but then it’s static.

[46:23] So, how do how how can we layer in the same kind of concepts so that folks can uh generate their app in their in their style, you know, with the with their requirements that need to be there. And you know, I I asked Nicole, is it possible to use presets? Cuz that it really literally was a question from me to her. And and we were like, let’s go find out. >> Yeah. So, yeah, there’s the actual preset that I created, right? Um so that when you launch the designer, you can apply that preset, and then the designer installs that basically when it’s generating the

[46:54] canvas. Nice. >> oh okay, actually probably when I explain that, the designer then runs obviously a Spec-it workflow to do that because otherwise >> Yes. >> it wouldn’t work. >> Yep, all this functionality’s packaged to in its own extension actually, and it’s you can see that here. That’s that it has to be installed cuz that’s where all of this is at, and then you can override it, like I said, the behavior with presets and and more extensions if you want. Um so someone has raised an interesting I I

[47:24] don’t know if this will render nicely cuz it’s a longer question, but I think the kind of general gist of it is um token usage and working with Spec-it. Are there, you know, has there been kind of any consideration about how to be more efficient about that? Like, you know, I I think something that’s neat about using some of these workflows is >> [clears throat] >> I don’t have to go like I’ve made a lot of canvases.

[47:55] It is quite a few tokens for me to go back and forth to change colors, change alignments of things. And being able to have presets that can I think skip a fair number of those tokens. But yeah, kind of how did you go about thinking about that with the design of Spec kit? >> Well, the design of Spec kit obviously started with a as the decor SDD workflow. It is >> What is What is SDD for folks? >> Uh >> Spec driven development.

[48:26] >> [laughter] >> Spec driven development. >> Yes. >> Yes. So the core workflow obviously delivers a lot of files because you’re trying to do define API contracts. You’re doing research. Then obviously you create your spec based on all of that and you have to plan it the create implementation plan then you’re creating the task list that actually needs to be done. Now, yes, one of the things once we introduced preset it’s like okay, you know, for a small feature

[48:57] that seems rather large. So there is a preset it’s called lean preset that only creates three files. The spec, the plan, and the task you know, yes, that one consumes a whole lot less tokens but also is less specified because of the fact that you don’t have your API contracts. There you don’t see the research, you know, obviously the LM did something but it didn’t actually formalize it in a file. Okay, so it all depends on how much you need and how much your organization requires of you to specify certain

[49:29] things out. Now, if you’re talking about a small small thing, a small feature, then yeah, use the lean preset, right? Because it’s it it it is way leaner and it’s quite a quite a bit leaner actually. Now, does it come with some certain things that you need to be aware of? Yes. It doesn’t do certain things that the original core does and that’s by design. But it’s also an illustration of if you want to influence how the process works, you know, you can create your own preset

[49:59] and say, “Hey, you know what? I don’t want API contracts, but I do want all the other stuff that happens.” Okay? Override and decor with a preset. And you can do that. Now, um what was the secondary question? Sorry, cuz I kind of like >> Um I I think it was kind of just mostly you know, if if you are token conscious while you’re using SpecKit, what I I think you answered pretty well what the gist of what we’re asking about. Um

[50:32] there was an other interesting question uh which was um so, I think the internals of SpecKit are written in Python. I’m a Pythonista. Uh I have no problem with that, but we’re at kind of what was part of the design decision around uh those sorts of just uh architecture choices. >> Um I can really not answer that question cuz I um I left when Dan left our company. So, why he picked Python, probably because he was comfortable [laughter] with it.

[51:03] You know, and obviously you’re not going to rip the you know, the the foundation from under people. So, yeah, Python has to stay. >> [snorts] >> I mean, I think uh something I always tell people since I’ve used Python kind of as my primary language for about 15 years, it’s the second best language at everything. Probably for every task, like it’s a Swiss Army knife. So, like you know, probably for any specific task, there might be a better more [clears throat] optimal choice for speed or something like that.

[51:36] But whenever I need a library for something, there already is one in Python. >> [laughter] [clears throat] >> From the standpoint of building things, I feel like it’s a and not to brag, but it has a great community, too. So, [laughter] any any project that kind of gets to lean into those communities, I think will benefit a lot. We’re very friendly, so. >> And and the the point out, I mean, obviously, when you run the actual commands, Python is

[52:07] not in play. It then it becomes the agent that actually just reasons about the prompt it receives and then, you know, whatever tooling it has, you know, it could be a Python tool that it calls. It could be, you know, a bash script. It could be a PowerShell script it calls. You know, then it depends on what the command actually specifies. So. >> Yeah. I They’re all fully decoupled, basically. You use this to generate your specs for the spec-driven development. And then, you use those, you know. I I

[52:38] have definitely prior to knowing about SpecKit sat down and written many specification documents. And it unless you have like company templates or something like that, it can it’s like a lot of full-time work. So, [laughter] it is a great great thing to be able to kind of start with the scaffold and then tweak as you need to. So, that >> [clears throat] >> that was why I was originally so excited about SpecKit cuz I’m like, >> [snorts] >> we can have something to talk about

[53:08] that, you know, is already, you know, I can turn on and off features if I don’t need the API contracts, stuff like that. I can just turn those off. Um so, yeah. Definitely highly suggest, especially if you are starting new projects. Um Try out SpecKit. See, you know, kind of see what it helps helps you think through. Like, I think it also kind of can sometimes help prompt folks to things that they >> [clears throat]

[53:40] >> It’s morning. >> [laughter] >> Things that folks might not be thinking through Uh kind of completely when they’re designing a project. I know it has definitely helped me think about, oh, there’s actually an interface there and I definitely need to kind of flush out more what what are the rules around this. So. >> Which which actually ties back into that idea assessment extension because, you know, before you implement something, you know, that one actually is also asked the question, is it even something you should be doing? But the nice thing

[54:10] >> [laughter] >> the entire process of that one is is that it actually asks you clarifying questions. Now, you can completely ignore those, obviously, but it is interesting to see those clarifying questions because it will tell you like, did you consider this? Did you consider that? And you’re like, oh, the oops, I missed something. And that’s, you know, that’s the thing when we’re talking about an idea, it’s like, did you really think about everything that that is involved in in in what you’re asking, you know, to be changed here? And that’s

[54:40] something that, you know, if you’re working on multiple projects, it’s not always an easy thing. And, you know, uh yeah, if you go if you if if you onboard and you just have the ability to say, you know what, this is an an issue that was filed. Let’s go see, is it something that actually fits the code base or is it something that I should push back on? >> Mhm. It’s I feel like, and you can correct me if I’m wrong, it’s like having a pocket PM. >> [laughter] >> It helps you like, I’ve done some PM

[55:12] work, that’s not my forte, but I do definitely understand the value of having a great PM when you’re working on a project and they often are the kind of person who asks those questions like, do we really need to be doing this now? Um, you know, have we thought about this? So, yeah, I think it’s a really cool structure to leverage LLMs with to help you work on developing your projects. >> It’s funny that you call Pocket the LLM sorry Pocket PM, my bad.

[55:43] >> [laughter] >> Yes, I mean I honestly I would actually if you are a PM use it. You know, you can make it your own just like the the SDD part. You can make it your own with your own presets for that one as well. So, if you feel like okay, this is this process doesn’t entirely adhere to how I would want it done, you can actually you know, tweak it. Now, obviously themselves that are that you know, are currently in the assessment pipeline are you know, there. Do you need to execute

[56:15] all of them? No, but that obviously that depends on how you actually would look at your own process. Which is you know, yes, we started as Spec It. You know, it really has now become a process kit. >> [laughter] >> A random I feel like I might have to contribute this as a community thing, but I used to work on medical devices and the software processes and requirement like you there it was like a binder of all the things you had to check that every time somebody made a change to code like all of those rules

[56:47] were followed. That feels like something that would be perfect for this. Like I’ll just hand hand Spec It this manual and be like help me make a preset that will when we make changes to the code actually make sure we’re adhering to all of these steps. So, >> It’s funny that you mentioned it. Um way back earlier in my career, I actually did work with a more regulated industry. It happened to be the VA. Um they actually have what they call a NEEM

[57:19] model that is for information interchange. Um so yes, I I I I just created the presets for it because I was like, you know what? Let’s see if I can actually do that cuz you know, it’s and then know then actually see what it does. It’s very interesting to see. Now, I’ll try to plug that everyone should use it or anything, but you know, if you are interested in that, you know, go check out my personal repositories cuz that’s the thing that I always want to call out as well. I’m just as a community member as everyone else when it comes to

[57:50] extensions and presets. You know, we’re trying things out and obviously you know, because of the community and which we really love, we can see what sticks and what doesn’t stick cuz you know, the more extensions, presets, bundles, workflows, and workflow steps that that that and canvases that come around, you know, the more you know, we can all help each other out. >> Yeah. I that’s one of the my favorite things about the open-source community is like

[58:21] yes, we can talk about all the cool things that this does, but you can also make it you can add new things yourself. You can see how they work. You know, it’s not just some sort of magical black box. So, um when something usually in my case I break something, it gives me an opportunity to go before bugging a bunch of people go see um what what did I do wrong? >> [laughter] >> So, yeah, definitely if you are interested in this project at all, please go check out the repo for either

[58:53] we’ve got Spec Kit. This is the main repo for the kind of coding agent agnostic pieces. And basically the actual computational back end for the Co-pilot integration for Spec Kit, which basically gives you lots of nice options in the Co-pilot app and other Co-pilot tooling to leverage the agnostic. So, not there’s not really special features or additional things. It’s just ways to make core Spec Kit work well in

[59:24] Co-pilot. Hopefully that’s an accurate characterization. Um Yeah, so I will close out um >> [clears throat] >> with a fun question. Um What’s your favorite ice cream flavor? >> Pistachio. >> Pistachio. Okay. All right, that’s a solid choice. >> Mine would be cookie dough. >> Cookie dough. Yeah. >> And yours? >> that’s Mine uh well,

[59:58] nominally like a sea salt like or sea salt caramel sort of thing. However, not sponsored plug >> [laughter] >> for Salt & Straw, which is like a a chain in the US. Uh But, they have a Halloween flavor right now called graveyard cookie crumble that is truly the best ice cream flavor I have ever had. I am doing everything I can to not go there literally every day this month cuz it rotates out at the end of the month. >> [laughter] >> I am strongly considering buying so many

[1:00:28] pints and stocking my freezer with them. >> [laughter] >> But, it’s like really really dark chocolate with cookies in it cuz I I do love you got to have like the kind of cookie crunch in there. Uh and like dark like bright red white chocolate swirls cuz it’s a a graveyard. Anyway. >> [laughter] >> Uh well, thank you so much for joining me Manfred and Nicole. >> Yeah, thank you. >> You. >> Um and thanks everybody for joining us uh online and uh watching the recording later. You can always catch up on more

[1:01:00] open source Fridays. We’re here pretty much every Friday. Um I think just literally opensourcefridays.com. >> [laughter] >> Um and you can check out our whole catalog and I look forward to trying out all kinds of new SpecKit stuff this week and also uh what comes next for the project. And hopefully, some of the folks here who have uh caught up in chat might be contributors to the next next iterations. That would be super cool. Just a thought. >> Mhm. >> [laughter] >> Anyway, have a good one everybody and uh we’ll catch you next time.

[1:01:31] >> Thanks. >> Bye.