Esta nova ferramenta open source acabou de resolver seu workflow no Claude Code

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: This New Open Source Tool Just Fixed Your Claude Code Workflow · Canal: AI LABS · 12:18 · Assistir no YouTube

Tópicos: Agentes de IA, Claude Code, Ferramentas de desenvolvimento com IA, Privacidade e proteção de dados

Resumo

O vídeo apresenta Agent Git, uma ferramenta que usa conceitos do Git para salvar, organizar e compartilhar conversas com agentes. Cada sessão fica registrada em um repo, permitindo retomar conversas, voltar a turnos anteriores, reutilizar mensagens e transferir contexto entre ferramentas como Claude Code e Codex. O tutorial mostra como instalar e configurar a ferramenta, além de explicar opções de compartilhamento e os limites de armazenamento. Por fim, aborda a detecção de segredos e uma skill criada para ajudar a proteger senhas nas conversas salvas.

Pontos-chave

Agent Git registra conversas com agentes em repos e branches separados, usando commits para preservar o histórico das sessões.
É possível compartilhar sessões com colaboradores ou por links somente para leitura; repos privados têm limite de 1 GB.
O comando de reversão altera o contexto da conversa que o agente vê, mas não desfaz mudanças no app.
A função de cherry-pick copia mensagens e respostas de uma sessão para outra, sem aplicar as alterações feitas no app.
O comando fork permite continuar uma conversa em outro agente, como transferir uma sessão do Claude Code para Codex.
Agent Git verifica conversas para substituir chaves reconhecidas por placeholders, mas pode não detectar senhas comuns.
Uma skill pode registrar senhas antes de serem salvas no histórico, para que sejam substituídas por placeholders.

Capítulos

Início	Capítulo	Resumo
00:00	O problema de compartilhar contexto entre sessões	O vídeo apresenta Agent Git como uma forma de preservar e compartilhar conversas com agentes, usando conceitos do Git.
02:09	Como funcionam repos e compartilhamento	A explicação mostra como sessões, histórico, perfis, permissões e links de leitura funcionam na ferramenta.
04:52	Instalação e configuração inicial	O tutorial cobre a instalação, o login, a criação de um repo e a escolha dos arquivos de instruções para os agentes.
07:28	Reverter sessões, reutilizar mensagens e transferir conversas	O vídeo demonstra como consultar e reverter turnos, copiar partes de uma conversa e continuar uma sessão em outro agente.
10:42	Proteção de segredos no histórico	A seção final explica a substituição de chaves por placeholders e uma skill para registrar senhas antes de salvá-las.

Citações

O maior problema de trabalhar com várias sessões é compartilhar contexto entre elas. — 00:00

No Agent Git, o repo guarda as conversas com seus agentes em vez de código e arquivos. — 02:09

Isso só muda a conversa. Não leva seu app de volta a uma versão anterior. — 07:28

O Agent Git permite trazer a conversa diretamente para o Codex, sem você precisar escrever essa passagem de contexto. — 09:37

Uma senha formada por palavras comuns pode não ter nenhum desses padrões. — 11:12

Conceitos e entidades

Agent Git (ferramenta): Ferramenta que aplica ideias do Git ao histórico de conversas com agentes, permitindo salvar, organizar e compartilhar sessões.
Git (ferramenta): Sistema de controle de versões usado no vídeo como referência para explicar commits, branches e compartilhamento de histórico.
Claude Code (ferramenta): Ferramenta de programação com agente usada no exemplo de configuração e transferência de conversas.
Codex (ferramenta): Ferramenta de programação com agente que pode continuar uma conversa iniciada em outro agente por meio do comando fork.
Runnable (empresa): Patrocinador apresentado no vídeo, descrito como um agente de IA que cria e publica produtos a partir de um prompt.
AI Labs (empresa): Canal que publica o vídeo e apresenta o tutorial sobre Agent Git.
AI Labs Pro (empresa): Serviço mencionado como local de acesso à skill, ao starter pack e a outros recursos do canal.

Tradução completa (pt-BR)

00:00 O maior problema de trabalhar com várias sessões é compartilhar contexto entre elas. Isso acontece porque sua sessão fica limitada ao mesmo agent trabalhando na mesma pasta. Então, quando você precisa mudar para outra sessão ou compartilhar esse contexto com outra pessoa, precisa registrá-lo em arquivos para que outros agents possam continuar de onde você parou. E nós mesmos nos deparamos bastante com isso, porque, quando estamos discutindo algo com um agent e precisamos compartilhar com outra pessoa, o arquivo que ele escreve só mantém os pontos principais e deixa de fora os detalhes. Mas existe uma ferramenta chamada Agent Git que resolve exatamente esse problema. E ela não só permite gerenciar as sessões dentro de um único

00:33 agent, como também facilita movê-las entre diferentes agents, algo que nenhuma outra ferramenta faz com a mesma facilidade. Você também pode compartilhar suas sessões com outras pessoas, para que elas continuem a partir das discussões que você já teve. Então, se você chegou agora, somos uma empresa de software e este é o AI Labs. Neste vídeo, vamos explicar o que é o Agent Git, como ele realmente resolve esse problema, qual problema a própria ferramenta tinha e como nós o resolvemos. Então, antes de falar do Agent Git, você precisa conhecer o Git, porque o Agent Git empresta toda a ideia dele. Se você já conhece o Git, pode pular direto para a próxima seção usando os marcadores de tempo abaixo. O Git é uma ferramenta que basicamente acompanha

01:07 as mudanças nos seus projetos. Quando você pede para ele acompanhar um projeto, pode ver exatamente quais linhas foram alteradas e também quem fez essas alterações. Cada versão salva do seu projeto é chamada de commit, e o Git a mantém associada ao seu nome. Então, se uma mudança causar algum problema, você pode voltar ao commit anterior que estava funcionando. Você também pode trabalhar em uma versão separada do seu projeto, chamada branch, para experimentar uma direção completamente diferente. E, se não quiser as mudanças que fez nessa branch, pode excluí-la, sem que nada no seu projeto principal seja afetado. Esses commits ficam salvos no seu computador. Quando você os envia para um site

01:39 como o GitHub para salvá-los online, isso se chama push. Assim, seus colegas de equipe podem obter as versões que você salvou e também trabalhar no projeto. Quando várias pessoas trabalham no mesmo projeto, cada uma pode fazer alterações na própria branch sem mudar a versão principal. Os commits mostram o que cada pessoa alterou e, depois que essas pessoas dão push nos commits, os colegas podem revisar as mudanças e combiná-las com a versão principal. Então, você pode usar isso nos projetos que desenvolvem juntos ou em um segundo cérebro compartilhado ou numa base de conhecimento à qual todos acrescentam suas próprias informações. O Agent Git pega a mesma ideia do Git e

02:09 a aplica às conversas que você tem com seus agents. No Git, seu projeto e o histórico dele ficam em um único lugar chamado repo. No Agent Git, o repo guarda as conversas com seus agents, em vez do código e dos arquivos, junto com a memória salva e as skills. Cada sessão tem sua própria branch dentro desse repo. Assim, você pode ter várias conversas sobre o mesmo projeto, e cada uma fica separada. E um commit no Agent Git salva as mensagens e o que o agent fez em resposta. Isso cria um registro da conversa ao qual você pode voltar mais tarde. Mas, se você voltar na conversa, isso não desfaz as alterações feitas no

02:41 seu app. O app continua igual; só muda a conversa que o agent vê. Você também pode compartilhar essas sessões com outras pessoas. Para isso, precisa de um perfil, para que as pessoas saibam quem teve a sessão e você possa controlar quem tem acesso a ela. O perfil funciona como o seu próprio perfil do GitHub. Porém, quando você salva uma sessão no computador, ela não aparece no seu perfil. Você precisa dar push nela para que apareça lá. Seus repos são privados por padrão, o que significa que outras pessoas não podem ver as sessões dentro deles, a menos que você dê acesso a elas. Mas há um limite que vale a pena conhecer antes de começar: você tem apenas 1 GB de armazenamento para guardar todas as conversas nos seus repos privados.

03:15 Mas, se quiser que qualquer pessoa possa ver suas conversas, você pode tornar o repo público. O Agent Git realiza várias verificações e depois pede que você confirme se quer torná-lo público. Quando você confirma, ele se torna público. As pessoas podem copiar esse histórico, e você não pode tornar o repo privado novamente. E, quando quiser compartilhar uma conversa com pessoas específicas, há duas maneiras de fazer isso. A primeira é adicioná-las ao próprio repo. Você precisa ir ao painel de configurações, procurar a seção de colaboradores e adicionar quem quiser que trabalhe com você. Essas pessoas podem continuar de onde você parou e, em seguida, enviar uma solicitação para adicionar o trabalho delas de volta ao seu repo, chamada de pull request. A segunda maneira é criar um link somente de leitura

03:48 para que qualquer pessoa com quem você o compartilhar possa ler a conversa sem alterá-la. Você pode definir quantas vezes o link poderá ser aberto. Quando esse limite for atingido, o link deixará de funcionar e ninguém poderá acessar aquela sessão usando o link que você forneceu. Mas, antes de instalar a ferramenta, vamos ouvir nosso patrocinador, Runnable. Criar produtos de verdade geralmente significa lidar com toda uma pilha de ferramentas separadas que mal se comunicam entre si e pagar por uma nova assinatura cada vez que você adiciona uma delas. Runnable é um único agent de IA que cria tudo isso a partir de um único prompt. Pedimos a ele uma landing page que pudesse receber pagamentos de verdade. Ele fez

04:20 algumas perguntas rápidas sobre nosso produto e preços e, em seguida, começou a criar. Primeiro, organizou a página no canvas: uma seção principal, uma linha de recursos e uma tabela de preços com três níveis, cada seção aparecendo à medida que ele a escrevia. Depois, preencheu o texto: o título, as descrições e o texto do botão. Para o checkout, configurou os pagamentos, criou os planos, iniciou um checkout ativo e conectou a ele todos os botões de preços, sem precisar de painel nem de chaves para copiar e colar. Quando terminou, fez o deploy e nos entregou uma URL real. Abrimos a página, clicamos em um plano e um checkout funcional carregou em uma página que não existia 10

04:52 minutos antes. Criar produtos de verdade não fica mais fácil do que isso. Então, experimente o Runnable e crie o seu hoje mesmo. Os links estão na descrição abaixo. Para instalar essa ferramenta, você precisa acessar o repo dela no GitHub, onde há dois comandos de instalação. O comando create Agent Git instala a ferramenta e a configura para sua ferramenta de programação de uma só vez. Você pode usá-lo se quiser um instalador de um único comando. O outro comando instala a mesma ferramenta por meio de outro instalador e é uma alternativa caso o primeiro não funcione para você. Ambos instalam a ferramenta no computador inteiro. Nós optamos pelo NPM porque o outro

05:22 instalador não conseguiu fazer a instalação quando o executamos. Basta copiar o comando de instalação e executá-lo no terminal. Depois de instalar, você pode verificar qual versão tem executando o comando de versão. Talvez você pense que, como a ferramenta está instalada no computador inteiro, ela começará a salvar tudo em que você está trabalhando, mas ela não salva tudo; só salva aquilo que você pedir. Você precisa criar uma conta no site deles e, depois, executar o comando de login no terminal para conectar o Agent Git a essa conta. Você precisa escolher a opção de login pelo navegador e, em seguida, aprovar o login na página que abrir. Você pode verificar em qual conta está conectado usando o comando who am I, e seu e-mail e sua conta serão exibidos. Depois de fazer login, você está pronto para criar um repo para o seu projeto. Estamos testando a ferramenta em um app de demonstração para gerenciamento de eventos. Usamos o template de app web que temos na nossa comunidade para facilitar essa criação, fizemos o download e abrimos a pasta do projeto no terminal. Você precisa executar o comando init para preparar esse projeto para o Agent Git. Quando fizer isso, uma interface será aberta. A primeira opção é o nome, que por padrão será unnamed, e você precisa dar ao repo o nome que quiser. Depois, precisa verificar se ele está usando o

05:55 o comando, e seu e-mail e sua conta serão exibidos. Depois de fazer login, você está pronto para criar um repo para o seu projeto. Agora, estamos testando em um app de demonstração para gerenciamento de eventos. Usamos o template de app web que temos na nossa comunidade para facilitar essa construção, baixamos o template e abrimos a pasta do projeto no terminal. Você precisa executar o comando init para preparar este projeto para o Git. Ao fazer isso, uma interface é aberta. A primeira opção é o nome, que será “unnamed” por padrão, e você precisa dar o nome que quiser para o seu repo. Depois, precisa verificar se ele está usando o

06:26 pasta do projeto. Depois disso, você pode optar por revisar as instruções e as skills que a configuração está salvando. Também há o push automático, que permite que o agent envie sua conversa automaticamente, sem você pedir. Se deixar essa opção desativada, ainda poderá fazer o push manualmente depois. Em seguida, você precisa selecionar em qual arquivo as instruções devem ficar. A primeira opção apresentada foi agents.md, que ferramentas de programação como Codex usam para as instruções do projeto. A outra é CLAUDE.md, que Claude Code usa. Você precisa selecionar o arquivo correspondente à ferramenta de programação que está usando. Como trabalhamos tanto com Codex quanto com Claude Code, adicionamos os dois.

06:57 Então, na pasta do nosso projeto, os dois arquivos contêm as instruções de que o agent precisa para usar o A Git. O A Git também mantém uma pasta separada para o repo, dentro da pasta .a git na sua pasta pessoal. É lá que ele armazena suas conversas, a memória e as skills. A memória guarda fatos e decisões salvos, e é nas skills que ele mantém as skills que criou e que usaria em sessões futuras. Depois de executar init, você pode dar um prompt ao agent sobre sua tarefa. Ao terminar cada turno, o A Git salva a conversa no seu computador. Mas, antes de explorarmos mais recursos do A Git, seria ótimo se você

07:28 se inscrevesse no canal e clicasse no botão de gostei. Esse pequeno gesto de apoio significa muito para nós. Agora, há momentos em que o agent faz algo errado e você precisa voltar uma etapa na conversa. Talvez você pense que é a mesma coisa que o comando rewind, que muitos agents já têm e que faz exatamente isso. Mas, no A Git, é diferente, porque você pode voltar não só nas suas conversas, como também nas conversas que outra pessoa compartilhou com você. Mas isso só altera a conversa. Não faz seu app voltar a uma versão anterior. Antes de executar rewind, porém, você precisa executar o comando log, que vai listar suas sessões para que você possa

08:01 escolher a conversa que quer alterar. Você pode selecionar a sessão desejada, e ela mostrará os prompts que você deu e o que o agent fez em resposta. Os números ao lado desses prompts identificam cada turno, que inclui seu prompt e a resposta do agent a ele. Se quiser voltar a um ponto anterior de uma sessão, você precisa usar o comando revert e o número que viu no log para indicar ao agent a qual prompt quer voltar. No comando, o número do turno vem depois do nome da sessão, precedido por um símbolo de cerquilha. Mas você não informa o número do turno para o qual quer voltar. Em vez disso, precisa informar quantos turnos são necessários para chegar ao

08:34 ponto para o qual quer reverter e mencionar os números, começando pelo fim e voltando até esse ponto. Você pode incluir todos eles em um único comando. Esses turnos não desaparecem do log. O registro do que aconteceu continua lá, mas o agent deixa de ver os turnos que você removeu. Você precisa executar o comando resume para continuar essa conversa. E, se também quiser atualizar a versão no seu perfil, pode usar o comando push. Com o A Git, você também pode pegar uma mensagem de uma conversa e levá-la para outra. Quando faz isso, a resposta do agent e o registro de tudo o que ele fez também vêm junto. Então, se houver algo útil em outra

09:05 conversa, você pode trazer esse trecho para a sessão em que está trabalhando e continuar a partir dali. Para fazer isso, primeiro você precisa usar o comando log para encontrar a mensagem na conversa da qual quer copiar. Depois de encontrá-la, pode usar o comando cherry-pick, informar o nome daquela sessão e o número da mensagem, e pedir que ela seja adicionada à sessão atual. A mensagem e a resposta do agent serão adicionadas ao fim da sessão atual, o que significa que você poderá continuar trabalhando com todo aquele contexto disponível. E, se precisar de mais de uma mensagem, pode incluir vários números de mensagem no mesmo comando. Uma coisa importante é

09:37 que isso só copia o histórico da conversa. Não aplica nenhuma das alterações no app que foram feitas ou descritas naquelas mensagens. Com o A Git, você também pode continuar em outro agent uma conversa que está tendo com um agent. Nenhum dos agents de programação permite fazer isso por padrão. Muitas vezes precisamos disso porque usamos tanto Codex quanto Claude Code. Quando estamos no meio de uma conversa com Claude Code e queremos que Codex continue o trabalho, normalmente pedimos a Claude que anote o que fez e o que Codex precisa saber. Depois, pedimos a Codex que leia essas informações antes de passar a próxima tarefa. Mas o A Git permite

10:09 que você leve a conversa diretamente para Codex, sem precisar escrever essa passagem de contexto por conta própria. Você precisa usar o comando fork e escolher Codex. Isso cria uma nova sessão a partir da conversa que você já teve, converte-a para o formato que Codex lê e a abre nele. Sua conversa original também continua disponível. Você pode pedir ao agent atual que escreva o comando para você, assim não precisa se lembrar de todas as opções. Mas precisa executá-lo no terminal, em vez de pedir ao agent que faça isso por você, para poder continuar a conversa em outro terminal. Agents costumam lidar com coisas como chaves de API e senhas, às quais você não gostaria que outras

10:42 pessoas tivessem acesso. E, assim que o agent lê essas informações, elas passam a fazer parte da conversa. Então, se você fizer push dessa conversa, pode acabar compartilhando esses segredos também. Para evitar isso, o A Git procura segredos ao salvar a conversa e substitui as chaves reconhecidas por marcadores. Esses marcadores indicam onde a chave estava, sem incluir o valor real. Testamos isso com algumas chaves de API inventadas e, ao verificar o histórico salvo, vimos que elas tinham sido substituídas por marcadores. O A Git também verifica o histórico novamente antes de fazer push, mas há uma limitação

11:12 porque as chaves de API geralmente têm um padrão reconhecível, como um prefixo específico e um comprimento fixo. Uma senha composta por palavras comuns não necessariamente tem nenhum desses padrões. Por isso, o A Git pode não detectá-la, mesmo que a conversa diga explicitamente que se trata de uma senha. Foi por isso que criamos uma skill que registra as senhas no A Git antes de a conversa ser salva. Ela começa registrando os segredos que já estão no seu projeto e, em seguida, instrui o agent a registrar qualquer nova senha que você fornecer antes de continuar. Depois que uma senha é registrada, o A Git sabe que deve substituir esse valor por um

11:44 marcador ao salvar a conversa. Você não precisa adicionar essa skill no início da sessão, porque, se o A Git já tiver salvo uma senha no histórico, adicionar a skill depois não vai removê-la. Mesmo que você remova a mensagem, a senha continuará no histórico. Essa skill que criamos, junto com o pacote inicial que mostramos aqui e todos os outros recursos, está disponível no AI Labs Pro. Então, se você achou nosso conteúdo útil e quer apoiar o canal, essa é a melhor maneira de fazer isso. O link está na descrição. Com isso, chegamos ao fim deste vídeo. Se quiser apoiar o canal e ajudar a gente a continuar fazendo vídeos como este, você pode

12:18 usar o botão Super Thanks abaixo. Como sempre, obrigado por assistir e até o próximo vídeo.

Transcrição original

[00:00] The biggest problem with working with multiple sessions is sharing context between them. This is because your session is limited to the same agent working in the same folder. So, when you need to move to another session or share that context with someone else, you need to write it out into files so that other agents can continue from where you left off. And we run into this a lot ourselves because when we’re discussing something with an agent and need to share it with someone else, the file it writes just keeps the key points and misses the details. But there’s a tool called Agent Git that solves exactly this problem. And not only does it let you manage the sessions inside one

[00:33] agent, it also makes moving them across different agents easier, which no other tool does as cleanly. And you can share your sessions with other people as well, so they can carry on from the discussions you’ve already had. So, if you’re new here, we’re a software company and this is AI Labs. And in this video, we’re going over what A Git is, how it actually solves this problem, and the one problem the tool itself had and how we solved it. So, before [snorts] we get into A Git, you need to know about Git because A Git borrows the whole idea from it. If you already know about it, you can skip straight to the next section from the timestamps below. Git is actually a tool that basically tracks

[01:07] the changes in your projects. When you let it track a project, not only can you see exactly which lines were changed, but you can also see who made those changes. Each saved version of your project is called a commit and Git keeps it under your name. So, if a change breaks something, you can go back to the previous commit that was working. You can also work on a separate version of your project called a branch, so you can experiment with a completely different direction. And if you don’t want the changes you made in that branch, you can delete that branch and nothing in your main project would be affected at all. Now, those commits are saved on your computer. When you send them to a site

[01:39] like GitHub to save them online, that’s called a push. That way, your teammates can get the versions you’ve saved and work on the project, too. Now, when multiple people work on the same project, each person can make changes on their own branch without changing the main version. Their commits show what they changed and once they push those commits, their teammates can review the changes and combine them with the main version. So, you can use this for the projects you build together or a shared second brain or knowledge base where everyone adds their own information. A get takes the same idea from get and

[02:09] uses it on the conversations you have with your agents. In get, your project and its history are kept in one place called a repo. In A get, the repo holds your agents conversations instead of code and file along with its saved memory and skills. Each session gets its own branch inside that repo. So, you can have multiple conversations about the same project and each one stays separate. And a commit in A get saves the messages and what the agent did in response. This gives you a record of the conversation that you can go back to later. But, if you go back in the conversation, it doesn’t undo changes to

[02:41] your app. The app stays the same, just the conversation that the agent sees is changed. You can share these sessions with other people as well. For that, you need a profile so people know who had the session and you can control who gets access to it. The profile works the same as your own get hub one does. When you save a session on your computer, it doesn’t appear on your profile though. You need to push it and then it appears there. Your repos are private by default, which means other people can’t view the sessions inside them unless you give them access. But, there’s a limit worth knowing before you start. You only get 1 GB of storage for storing all the conversations in your private repos.

[03:15] But, if you want anyone to be able to view your conversations, you can make the repo public. A get runs multiple checks and then asks you to confirm if you want convert to public. Once you confirm it, will be public. People can copy that history and you can’t make the repo private again. And when you want to share a conversation with particular people, there are two ways to do it. The first is adding them to the repo itself. You need to go to the settings pane, look for collaborators, and add whoever you want to work with. They can continue from where you stopped then send a request to add their work back to your repo, which is called a pull request. The second way is creating a read-only

[03:48] link so whoever you send it to can read the conversation without changing it. You can set how many times the link can be opened. Once that limit is reached, the link stops working and no one will be able to access that session using the link you gave. But before we install it, let’s have a word by our sponsor, Runnable. Building real products usually means juggling a whole stack of separate tools that barely talk to each other and paying for a new subscription every time you add one. Runnable is one AI agent that builds all of it from a single prompt. We asked it for a landing page that could take real payments. It asked

[04:20] a couple of quick questions about our product and pricing, then started building. First, it laid out the page on the canvas, a hero, a features row, and a three-tier pricing table, each section appearing as it wrote it. Then it filled in the copy, the headline, the descriptions, the button text. For checkout, it set up the payments itself, created the plans, spun up a live checkout, and wired every pricing button to it with no dashboard and no keys to paste. When it finished, it deployed and handed us a real URL. We opened it, clicked a plan, and a working checkout loaded on a page that didn’t exist 10

[04:52] minutes earlier. Building real products doesn’t get any easier than this. So, try Runnable and build yours today. Links in the description below. So, in order to install this tool, you need to go to their GitHub repo, where there are two install commands. The create A Git command installs the tool and sets it up for your coding tool in one go. You can use that if you want the one command installer. The other command installs the same tool through another installer, and it’s an alternative if the first installer doesn’t work for you. Both install it for your whole computer. We went with NPM because the other

[05:22] installer couldn’t install when we ran it. You just need to copy the install command and run it in your terminal. Once it’s installed, you can check which version you have by running the version command. Now, you might think that since it is installed on all of your computer, it will start saving everything that you’re working on, but it won’t be saving everything and it will only save where you ask it to. You need to create an account on their site, then run the login command in your terminal to connect A Git to that account. You need to choose the browser login option, then approve the login on the page that opens. You can check which account you’re logged into by using the who am I

[05:55] command and your email and account will be shown. Once you’re logged in, you’re ready to create a repo for your project. Now, we’re [snorts] testing it on a demo event management app. We use the web app template that we have in our community to make that build easier, downloaded it, and open the project folder in the terminal. You need to run the init command to make this project ready for A git. When you do that, it opens up an interface. The first option is the name, which will be unnamed by default, and you need to give it whichever name you want for your repo. Then, you need to check that if it’s using the right

[06:26] project folder. After that, you can choose to review the instructions and skills that the setup is saving. There’s also auto push, which lets the agent push your conversation automatically without you asking for it. If you leave that off, you can still push it yourself later. Then, you need to select which file should hold the instructions. The first option it gave was agents. md, which coding tools like Codex use for project instructions. The other is Claude.md, which Claude code uses. You need to select the file for the coding tool you’re using. Since we work in both Codex and Claude code, we added both.

[06:57] So, in our project folder, both files contain the instructions the agent needs to use A git. A git also keeps a separate folder for the repo inside the .a git folder in your home folder. That’s where it stores your conversations, memory, and skills. Memory holds saved facts and decisions, and skills is where it keeps any skills that it created and would be used in the future sessions. Once you’ve run init, you can prompt the agent about your task. As it finishes each turn, A git saves the conversation on your computer. But, before we explore more features of A git, it would be great if you

[07:28] subscribe to the channel and hit the like button. This small gesture of support goes a long way for us. Now, there are times [snorts] when the agent does something wrong and you need to go back a step in the conversation. You might think that it’s the same as the rewind command that a lot of agents already have and does exactly this. But that’s different with A get because you can rewind not only your conversations, but the conversations that somebody else shared with you as well. But this only changes the conversation. It doesn’t take your app back to an earlier version. But before you run rewind, you need to run the log command first and it will list your sessions so you can

[08:01] choose the conversation you want to change. You can select the session you want and it will show the prompts you gave and what the agent did in response. The numbers next to those prompts identify each turn, which is your prompt and the agent’s response to it. If you want to take a session back to an earlier point, you need to use the revert command and use the number you saw in the log to tell agent which prompt you want to go back to. In the command, the turn number goes after the session name with a hash symbol before the number. But you don’t give it the number of turn you want to return to. Instead, you need to tell it what number of turns that are needed to go to the

[08:34] point you want to revert to and mention the numbers from the end back to that point. You can include all of them in one command. Now, those turns don’t disappear from the log. The record of what happened stays there, but the agent no longer sees the turns you removed. You need to run the resume command to continue that conversation. And if you want the version on your profile updated as well, you can use the push command. Now, with A get, you can also take a message from one conversation and bring it into a different one. When you do that, the agent’s response and the record of everything it did come along with it as well. So, if there’s something useful in another

[09:05] conversation, you can pull that part into the session you’re currently working in and continue from there. To do this, you’ll first need to use the log command to find the message in the conversation you want to copy from. Once you found it, you can use the cherry pick command, provide that session’s name and the message number, and tell it to add the message to your current session. The message and the agent’s response will be added to the end of your current session, which means you can keep working with all of that context available. And if you need more than one message, you can include multiple message numbers in the same command. One thing to keep in mind is

[09:37] that this only copies the conversation history. It doesn’t apply any of the app changes that were made or described in those messages. Now, with A Git, you can also continue a conversation that you’re having in one agent in another agent as well. This is something that none of the coding agents let you do by default. We often need this because we use both Codex and Claude code. When we’re deep in a conversation with Claude code and want Codex to continue the work, we normally ask Claude to write down what it’s done and what Codex needs to know. Then we ask Codex to read that before giving it the next task. But A Git lets

[10:09] you bring the conversation into Codex directly, so you don’t have to write that handoff yourself. You need to use the fork command and choose Codex. This creates a new session from the conversation you’ve already had, converts it into the format Codex reads, and opens it there. Your original conversation stays available, too. You can ask your current agent to write the command for you, so you don’t have to remember all the options. But you need to run it in your terminal instead of asking the agent to do that for you, so that you can continue the conversation in another terminal. Agents [snorts] often handle things like API keys and passwords that you wouldn’t want other

[10:42] people to have access to, and once the agent reads that information, it becomes part of the conversation. So, if you push that conversation, you could end up sharing those secrets as well. To prevent that, A Git checks for secrets when it saves the conversation and replaces any recognized keys with placeholders. These placeholders show where the key was without including the actual value. We tested this with some made-up API keys, and when we checked the saved history, those keys had been replaced with placeholders. A Git also checks the history again before pushing it, but there’s a limitation here

[11:12] because API keys usually have a recognizable pattern, like a specific beginning and a fixed length. A password made up of ordinary words doesn’t necessarily have any of those patterns. So, A Git can miss it even if the conversation explicitly says that it’s a password. That’s why we built a skill that registers passwords with A Git before the conversation gets saved. It starts by registering the secrets that are already in your project and then it tells the agent to register any new password you give it before continuing. Once a password is registered, A Git knows to replace that value with a

[11:44] placeholder when it saves the conversation. You don’t need to add this skill when you start the session because once A Git has already saved a password in the history, adding the skill later won’t remove it. Even if you remove the message, the password will still remain in the history. Now, this skill that we made along with the starter pack we showed you here and all the other resources are all available in AI Labs Pro. So, if you found value in what we do and want to support the channel, this is the best way to do it. The link’s in the description. That brings us to the end of this video. If you’d like to support the channel and help us keep making videos like this, you can do so

[12:18] by using the Super Thanks button below. As always, thank you for watching and I’ll see you in the next one.