A aceleração mais rápida que obtive no Claude Code este ano não foi uma melhoria de modelo. Foi aprender a digitar uma única barra seguida de quatro letras.
Eu já usava o Claude Code diariamente há mais de um ano antes de admitir algo embaraçoso: eu estava deixando a maior parte do seu potencial na mesa. Abria uma sessão, digitava um parágrafo inteiro de instruções, assistia funcionar, batia numa parede e começava uma sessão totalmente nova fechando o terminal por completo. Toda. Santa. Vez. Estava pagando por contexto que eu ficava jogando fora, re-explicando o mesmo projeto do zero e queimando uso em conversas que tinham se desviado tanto do assunto que o Claude basicamente estava adivinhando.
Então comecei a realmente usar os comandos slash. Não da forma como a documentação os lista — alfabeticamente, de forma plana, como um glossário que ninguém lê. Quero dizer os quatro ou cinco que agora busco tão reflexivamente que meus dedos se movem antes do meu cérebro terminar o pensamento. Os que decidem se uma sessão de construção de duas horas parece fluir ou parece lutar contra a ferramenta.
Esta é a versão prática disso. Os comandos slash do Claude Code que genuinamente uso todos os dias, agrupados pelo problema real que cada um resolve — contexto que ficou obsoleto, uma compilação que deu errado, um plano que eu precisava ver antes de qualquer código ser escrito. Para cada um: o que faz, a forma exata como o invoco e o momento específico em que recorro a ele em trabalho real.
Alguns dos "comandos" que circulam em tutoriais e vídeos acabaram sendo jargão da comunidade ou recursos que funcionam um pouco diferente do que as pessoas descrevem. Vou sinalizá-los honestamente conforme avançamos, porque conhecer a imagem precisa é todo o ponto — um comando que você acha que existe mas não existe é pior do que nenhum comando.
Vamos começar onde toda boa sessão começa e termina: com o contexto.
O que são comandos slash no Claude Code?
Comandos slash são atalhos que você ativa digitando / no prompt do Claude Code, o que abre um menu de autocompletar de ações que você pode executar sem escrever instruções longas. Eles controlam a sessão em si — limpar contexto, rebobinar código, retomar conversas antigas, configurar a interface — em vez de serem prompts que você envia ao modelo.
Essa distinção importa mais do que parece. Uma mensagem normal pede ao Claude para fazer algo na sua base de código. Um comando slash pede ao Claude Code para fazer algo com a sessão em que você está trabalhando. Um edita arquivos; o outro gerencia o ambiente onde essas edições acontecem.
O autocompletar aparece no momento em que você digita / — no terminal e no aplicativo de desktop — então você não precisa memorizar grafias exatas. Digite /re e você verá /rewind e /resume aparecerem juntos. É também assim que descubro comandos que eu tinha esquecido que existiam, o que é metade da razão pela qual me dou ao trabalho de digitar a barra em vez de procurar um atalho de teclado que meio lembro.
Aqui está o que a maioria das folhas de referência erra: tratam todos os quarenta e tantos comandos como igualmente dignos de aprender. Não são. Uso talvez seis deles diariamente e o resto quase nunca. Então não vou listar tudo. Vou guiá-lo pelo punhado que ganha seu lugar na memória muscular — e dizer quais a internet erra.
O primeiro é o comando que eu deveria ter aprendido no primeiro dia.
Gerenciamento de contexto: /clear, /resume e /rewind
A maior parte da frustração que eu costumava sentir no Claude Code remontava a uma única causa raiz: eu era ruim em gerenciar contexto. Ou eu tinha demais (uma conversa inflada onde o Claude ficava tropeçando em instruções antigas e irrelevantes) ou eu tinha perdido o contexto que realmente queria (uma sessão que fechei cedo demais e não conseguia recuperar). Três comandos resolveram quase tudo.
/clear — o reset que evitei por tempo demais
/clear limpa o histórico de conversa atual da janela de contexto e permite começar do zero — sem deletar sua memória de projeto.
Essa segunda metade é a parte que eu errei por meses, e vale a pena ser preciso porque muda o quão agressivamente você deveria usar o comando. Quando você executa /clear, ele remove tudo da janela de contexto ativa: o vai-e-vem, os arquivos que o Claude leu, os becos sem saída. Mas não toca seu arquivo CLAUDE.md. O CLAUDE.md é recarregado do zero no início de cada sessão por design, então ele sobrevive a um /clear e é reinjetado. Seu briefing do projeto permanece. Apenas a bagagem da conversa desaparece.
Eu costumava pensar que limpar significava "perder tudo e re-explicar o projeto inteiro." Não é assim — não se você colocou as coisas duradouras (arquitetura, convenções, o esquema do banco de dados) no CLAUDE.md onde elas pertencem. Essa percepção é o que finalmente me fez limpar constantemente em vez de temer.
Agora a regra que sigo: no momento em que termino uma tarefa lógica e passo para uma não relacionada, limpo. Terminei de configurar a autenticação, prestes a construir a página de faturamento? /clear. Duas razões. Primeiro, uma janela de contexto obsoleta cheia de detalhes de autenticação torna o Claude pior no trabalho de faturamento — ele reconhece padrões nas coisas erradas, referencia arquivos que não importam, e ocasionalmente edita "prestativamente" algo que eu nunca pedi que tocasse. Segundo, cada token desse contexto morto é um token pelo qual estou pagando e um token comendo meus limites de uso. Uma sessão longa e errante é cara em ambos os sentidos.
Se você adotar apenas um comando de todo este post, que seja este. Limpe entre tarefas. Sua qualidade de saída sobe e seu consumo desce ao mesmo tempo, o que quase nunca acontece junto.
Há um comando relacionado que vale a pena conhecer: /compact. Onde /clear descarta a conversa inteiramente, /compact a resume em uma forma comprimida para que você mantenha a essência enquanto libera contexto. Recorro ao /compact no meio de uma tarefa quando um trabalho individual ficou longo mas ainda preciso do histórico; recorro ao /clear quando genuinamente terminei e estou trocando de marcha. Ferramentas diferentes para momentos diferentes.
/resume — recuperar uma conversa que você achava que tinha ido embora
/resume permite reabrir uma conversa anterior do Claude Code selecionando-a de uma lista, então uma sessão que você fechou — ou até limpou — não está necessariamente perdida.
Este é o comando que me poupou um desgosto real. Imagine o cenário: limpo uma sessão, troco de tarefa, e vinte minutos depois percebo que precisava de algo da conversa que acabei de limpar — uma decisão que tomamos, um trecho de código que o Claude gerou, o raciocínio por trás de uma abordagem. Antes do /resume, isso tinha ido embora e eu sentia.
Com /resume, executo o comando, recebo uma lista de sessões recentes e escolho a que quero de volta. É diferente de rebobinar dentro de uma conversa ativa — /resume alcança através de sessões para recuperar uma anterior por completo. Pense nisso como a diferença entre desfazer suas últimas edições em um documento versus reabrir um arquivo que você fechou ontem.
O fluxo de trabalho que desenvolvi: limpo agressivamente porque sei que /resume me cobre. O medo de perder contexto era o que me fazia acumular. Uma vez que confiei que poderia recuperar uma sessão antiga quando genuinamente precisasse, limpar parou de parecer arriscado e começou a parecer higiene.
/rewind — desfazer para código, não apenas para conversas
/rewind rebobina sua sessão para um ponto de controle anterior, e pode restaurar seu código, sua conversa, ou ambos — independentemente.
Este é o comando que mudou o quão ambiciosamente deixo o Claude trabalhar. O Claude Code cria automaticamente um ponto de controle capturando o estado do seu código antes de cada edição, toda vez que você envia um prompt. Então quando uma mudança em múltiplos arquivos dá errado — e em uma refatoração grande, às vezes acontece — eu não entro em pânico e começo a reverter arquivos manualmente. Abro /rewind.
Você pode ativá-lo de duas formas: digite /rewind, ou pressione Esc duas vezes quando o campo de entrada do prompt está vazio. Ambos abrem o menu de rebobinar mostrando seus pontos de controle recentes. Então você escolhe o que restaurar:
- Restaurar código e conversa — reverta ambos para aquele ponto, como se os últimos minutos nunca tivessem acontecido.
- Restaurar conversa — rebobine o chat para uma mensagem anterior mas mantenha seu código atual. Útil quando o código está bem mas a conversa tomou um caminho confuso.
- Restaurar código — reverta as mudanças nos arquivos mas continue conversando. Este é o que mais uso: "aquela abordagem estava errada, desfaça os arquivos, mas vamos continuar discutindo por quê."
Também há opções de "resumir daqui" / "resumir até aqui" que comprimem parte da conversa para recuperar contexto — uma bela sobreposição com a ideia do /compact.
Uma limitação que você absolutamente precisa conhecer, porque já queimou pessoas: /rewind só rastreia edições que o Claude fez através de suas ferramentas de edição de arquivos. Comandos Bash não têm ponto de controle. Se o Claude executou rm, mv ou cp, essas mudanças são permanentes — rebobinar não as trará de volta. Pontos de controle também persistem entre sessões e se limpam automaticamente após 30 dias. Então rebobinar é uma rede de segurança para edições, não um substituto para git. Ainda faço commits frequentemente. Rebobinar é para os momentos intermediários; git é para a verdade fundamental.
Se você quiser se aprofundar em como estruturo o uso de tokens em torno de toda essa limpeza e compactação, desdobrei isso separadamente no meu guia para reduzir custos de tokens do Claude Code com a abordagem das cavernas — disciplina de contexto e disciplina de custos são a mesma habilidade com dois chapéus.
Isso cobre o contexto. O próximo grupo é sobre qualidade — fazer o Claude pensar antes de agir.
Planejamento e qualidade: modo plano e esclarecer-depois-planejar
O maior salto na minha qualidade de saída não veio de um comando de contexto. Veio de forçar o Claude a planejar antes de escrever uma única linha. Há duas formas como faço isso — uma integrada, uma que construo eu mesmo — e a segunda é a peça central de todo este post.
Modo plano — ver a abordagem antes de qualquer código ser escrito
Modo plano é um estado somente leitura onde o Claude analisa sua base de código e propõe um plano de implementação completo antes de tocar qualquer arquivo, para que você possa revisar e ajustar a abordagem antes da execução começar.
Nota rápida de precisão, porque isso confunde as pessoas: muitos vídeos e transcrições chamam isso de "o comando /plan," e isso é só meio correto. O modo plano está embutido no ciclo de permissões do Claude Code há muito tempo — você o ativa pressionando Shift+Tab duas vezes para aterrissar em ⏸ modo plano ativado na parte inferior do seu terminal. A partir do Claude Code v2.1.0, também há um comando literal /plan que ativa o mesmo modo, além de poder iniciar com claude --permission-mode plan ou torná-lo um padrão do projeto em .claude/settings.json. Então se você ouviu "/plan" e não pareceu fazer nada em uma versão anterior — é por isso. O caminho Shift+Tab sempre funciona.
Aqui está o que o modo plano realmente faz. Enquanto está ativo, o Claude mantém acesso total às suas ferramentas de leitura — Read, Glob, Grep, WebSearch, WebFetch — mas cada ferramenta de escrita está bloqueada: sem Edit, sem Write, sem execução de Bash. Ele lê sua base de código, mapeia dependências, raciocina por toda a abordagem e te entrega um plano numerado. Você lê. Corrige se estiver errado. Então aprova, e só então ele executa.
O momento em que recorro ao modo plano: qualquer tarefa que toque mais de dois ou três arquivos, ou qualquer coisa onde não estou 100% seguro de que o Claude e eu compartilhamos o mesmo modelo mental de como a mudança deveria acontecer. Uma migração de banco de dados. Uma refatoração entre componentes. Conectar uma nova API a um fluxo existente. Para esses, ver o plano do Claude captura o mal-entendido antes de se tornar trinta minutos de código errado que preciso rebobinar.
O erro que vejo as pessoas cometerem é usar modo plano para tudo, incluindo edições triviais de um único arquivo, onde só adiciona fricção. Modo plano ganha seu lugar na ambiguidade e na escala. Para "adicione um console.log aqui," pule.
Modo plano é poderoso, mas é reativo — o Claude planeja baseado no que eu disse. A próxima técnica resolve o problema mais profundo: o que acontece quando meu prompt em si estava incompleto.
Comandos slash personalizados — construindo um comando "esclarecer, depois planejar, depois executar"
Esta é a seção que eu diria para você ler duas vezes. Comandos slash personalizados são o recurso de maior alavancagem no Claude Code que a maioria das pessoas nunca toca, e são genuinamente simples de construir.
Um comando slash personalizado é simplesmente um arquivo Markdown. Você cria um arquivo em .claude/commands/ (de escopo de projeto, compartilhado com todos no repositório) ou ~/.claude/commands/ (pessoal, te segue em cada projeto). O nome do arquivo se torna o nome do comando. O conteúdo do arquivo se torna o prompt enviado ao Claude quando você o invoca. Esse é o mecanismo inteiro.
Então se eu executar isso:
mkdir -p .claude/commands
e criar um arquivo chamado .claude/commands/build.md, então digitar /build em qualquer sessão dentro desse projeto injeta o que eu escrevi naquele arquivo como meu prompt. O comando aparece automaticamente no menu de autocompletar /.
Agora — por que isso importa? Porque o maior assassino de qualidade na codificação com IA não é o modelo. É a lacuna entre o que pedi e o que realmente quis dizer. Escrevo um prompt vago, o Claude faz suposições razoáveis-mas-erradas para preencher a lacuna, e recebo código confiante e limpo que resolve o problema errado.
A solução é um comando que força o Claude a fechar essa lacuna antes de escrever qualquer coisa. Aqui está o comando real que mantenho nos meus repositórios. Chame de .claude/commands/scope.md:
# Esclareça a solicitação, depois planeje, depois construa.
Você está prestes a implementar: $ARGUMENTS
NÃO escreva nenhum código ainda. Trabalhe esses passos em ordem:
1. ESCLAREÇA. Me faça até 5 perguntas específicas sobre qualquer coisa
ambígua na solicitação — formatos de dados, casos extremos, nomenclatura,
onde isso se encaixa na arquitetura existente, como é "pronto". Se algo
é genuinamente inequívoco, não preencha a lista — pergunte apenas o que
você precisa.
2. PLANEJE. Depois que eu responder, reformule a tarefa em uma frase, depois
me dê um plano de implementação numerado: os arquivos que você criará ou
mudará, a ordem em que os fará, e qualquer decisão que esteja tomando que
eu deveria vetar agora em vez de depois que o código exista.
3. ESPERE. Pare e me deixe aprovar ou corrigir o plano antes de tocar
em um único arquivo.
Só depois que eu aprovar você começa a implementar.
O marcador $ARGUMENTS é o truque real — o que quer que eu digite após o nome do comando é inserido ali. Então executo /scope adicionar convites de equipe à página de configurações e o Claude pega "adicionar convites de equipe à página de configurações" como a coisa a esclarecer e planejar.
O que isso me traz na prática? As perguntas de esclarecimento são onde a mágica está. Metade das vezes, as perguntas do Claude trazem à tona algo que eu não tinha decidido ainda — "os usuários convidados devem receber um papel imediatamente ou ficar pendentes até aceitarem?" — e responder isso em voz alta, antes de existir código significa que nunca recebo a implementação errada em primeiro lugar. O passo do plano me permite então vetar uma abordagem de forma barata, enquanto ainda são palavras em uma tela em vez de arquivos no disco.
Não posso te dar uma porcentagem limpa de quanto isso melhora a saída — e quero ser honesto sobre isso, porque vi circular a afirmação de que comandos personalizados de esclarecer-depois-planejar melhoram a qualidade "em até 43% baseado em relatórios internos," e nunca consegui encontrar uma base real para esse número. Então não vou fingir. O que posso te dizer do uso diário é qualitativo e consistente: forçar a sequência esclarecer-depois-planejar-depois-executar reduz significativamente o número de reescritas "isso não é o que eu quis dizer" que faço. O retrabalho que economizo é todo o retorno do investimento. O número não ser verificável não torna a técnica menos real — só significa que não vou enfeitá-la com uma estatística que não posso defender.
Se quiser se aprofundar na construção desses, escrevi uma análise completa do comando slash personalizado /advisor e a camada metacognitiva que ele adiciona — os mesmos blocos de construção, propósito diferente. E a razão pela qual toda essa abordagem funciona se conecta diretamente com por que engenharia de contexto está se tornando uma competência fundamental à prova de futuro: os desenvolvedores que vencem com essas ferramentas não são os que digitam mais rápido, são os que estruturam melhor contexto e intenção.
Se você prefere que alguém construa uma configuração completa de comandos personalizados e agentes ajustada à sua stack em vez de montá-la você mesmo, esse é o tipo de trabalho que aceito diretamente — você pode ver o que construí no meu perfil do Fiverr.
Uma breve palavra sobre um comando sobre o qual as pessoas perguntam mas que não existe da forma como pensam.
Sobre "/goal" — um padrão que você constrói, não um botão que pressiona
Recebo perguntas sobre um comando "/goal" que supostamente permite definir uma tarefa mais uma definição de "pronto" e fazer o Claude continuar trabalhando até que um segundo agente verifique que está completo. Investiguei isso cuidadosamente, e aqui está a imagem honesta: não há um comando slash /goal integrado no Claude Code que faça isso. Não consegui confirmá-lo na documentação atual, e você não deveria procurá-lo como um recurso padrão.
O que é real é o padrão por trás — e é um bom padrão. Você absolutamente pode construir você mesmo um fluxo de trabalho orientado a verificação: um comando personalizado que dá ao Claude uma tarefa mais critérios explícitos de "definição de pronto", emparelhado com um subagente cujo único trabalho é verificar o trabalho contra esses critérios antes de declará-lo terminado. Isso é algo construível, não algo integrado. (O Codex da OpenAI, separadamente, inclui um comando literal /goal para execuções autônomas — eu testei e escrevi como o comando /goal do Codex realmente se comporta. Não confunda os dois; são ferramentas diferentes.)
A conclusão: se um tutorial te promete um botão mágico /goal do Claude Code, seja cético. A capacidade é sua para montar com comandos personalizados e subagentes — o que é mais flexível de qualquer forma.
Agora as coisas pequenas que melhoram silenciosamente cada sessão.
Ambiente e UX: /statusline e conhecer a ferramenta
Esses não mudam o que o Claude faz. Mudam quanto posso ver enquanto ele faz — e quão rápido descubro funcionalidades que não sabia que existiam.
/statusline — uma configuração única que rende em cada sessão
/statusline configura a barra de status na parte inferior do seu terminal, permitindo exibir coisas como o modelo ativo, uso de contexto e custo — para que você possa ver de relance o que está acontecendo sem adivinhar.
Mais uma nota de precisão: as pessoas escrevem como "/status line" (duas palavras). O comando real é /statusline, uma palavra, no autocompletar. Você o executa uma vez, configura o que quer ver, e então ele simplesmente está lá toda sessão.
Por que me dou ao trabalho: visibilidade de uso de contexto e custos. Quando minha barra de status me mostra quão cheia a janela de contexto está ficando, sei que é hora de /clear ou /compact antes do Claude começar a degradar — em vez de perceber a degradação depois. Ver o modelo ativo me lembra se estou no nível certo para a tarefa. É uma pequena configuração única que transforma um monte de estado invisível em algo que você pode ler de relance. Para a filosofia mais profunda de "ver e dirigir tudo que o Claude faz," me aprofundei na minha análise da camada visual do SO agêntico.
/powerup e /radio — os dois que mencionarei mas não vou supervender
Mais dois comandos reais, incluídos por completude e honestidade.
/powerup (introduzido no Claude Code v2.1.90) é um tutorial interativo dentro do terminal — lições animadas que cada uma ensina algo que o Claude Code pode fazer e que a maioria das pessoas perde. É genuinamente útil para descobrir funcionalidades, e dei a ele sua própria primeira análise completa no meu artigo sobre o que /powerup realmente ensina, então não repetirei isso aqui.
/radio também é real, e é exatamente o que parece: abre o Claude FM, uma estação de rádio lo-fi que a Anthropic opera, no seu navegador. É um comando de produtividade? Não. Eu o uso durante as partes chatas de uma compilação? Às vezes. Incluo porque te disse que daria a imagem precisa, e a imagem precisa é que existe e é um pequeno nada divertido. Trate-o de acordo.
Também há /btw — uma forma mais leve de fazer uma pergunta paralela ou adicionar contexto sem inflar o fio principal da conversa, mantendo sessões longas mais enxutas. É um mecanismo real que vale a pena conhecer se você quer se esclarecer no meio de uma tarefa sem descarrilar o fluxo.
Esse é o registro honesto. Agora deixe-me mostrar como isso fica quando encadeado em trabalho real.
Como uma sessão real se parece com esses comandos encadeados
Comandos em uma lista são abstratos. Aqui está como eles realmente se encadeiam em um dia normal de construção para mim.
Abro o Claude Code em um projeto. CLAUDE.md carrega automaticamente, então o Claude já conhece a stack e as convenções — não re-explico nada. Quero adicionar uma funcionalidade, então digito /scope adicionar exportação CSV à página de relatórios. Meu comando personalizado entra em ação: o Claude me faz quatro perguntas (quais colunas, qual formato de data, geração no servidor ou no cliente, qual deveria ser o nome do arquivo), respondo, ele me dá um plano de cinco passos, ajusto o passo três, aprovo.
Ele constrói. Na metade do caminho, a lógica de exportação se embaraça com a paginação existente e a saída não está certa. Não desfaço manualmente — abro /rewind, restauro o código para antes do embaraçamento mantendo a conversa, e digo "aquela abordagem conflitou com a paginação, vamos gerar o conjunto de dados completo separadamente." Recuperação limpa, talvez noventa segundos perdidos.
Funcionalidade pronta. /clear. Janela fresca, memória do projeto intacta, zero contexto obsoleto vazando para a próxima tarefa. Minha barra de status — configurada uma vez com /statusline semanas atrás — mostra que mal estou usando contexto, que é exatamente como uma tarefa fresca deveria começar.
Três tarefas depois percebo que preciso de uma decisão de uma sessão que limpei antes. /resume, escolho da lista, pego o que precisava, volto ao trabalho.
Cinco comandos. Nenhum deles escreveu código. Todos moldaram as condições sob as quais o código foi escrito bem. Esse é todo o ponto — os comandos slash não são o trabalho, são a oficina.
A parte honesta: onde eu errei, e o que vale seu tempo
Deixe-me ser direto sobre as correções, porque assistir um praticante recuar de suas próprias suposições é mais útil do que uma lista limpa que finge que tudo está confirmado.
Passei tempo demais tratando /clear como uma perda em vez de higiene — isso foi um imposto real no fluxo de trabalho que paguei por meses. "/plan" como comando independente é mais novo (v2.1.0) do que o modo plano de Shift+Tab sobre o qual é construído, então se você está em uma versão mais antiga, use o atalho de teclado. "/statusline" é uma palavra, não duas. E o "comando /goal" que as pessoas descrevem como integrado no Claude Code não é — é um padrão que você monta, e confundi-lo com o comando /goal real do Codex turva as águas. O número de "43% de melhoria de qualidade" atribuído a comandos personalizados não tem base que eu pudesse encontrar, então o descartei e te disse por quê em vez de lavar um número não verificável em uma afirmação confiante.
O que genuinamente vale seu tempo, em ordem de prioridade: /clear entre tarefas (maior e mais fácil ganho), um comando personalizado de esclarecer-depois-planejar (maior ganho de qualidade), /rewind para se recuperar de edições ruins (maior redução de estresse), e modo plano para qualquer coisa ambígua ou que envolva múltiplos arquivos (maior prevenção de "código errado"). O resto — /resume, /statusline, /compact, /btw — são reais, úteis e dignos de conhecer, mas são o elenco de apoio.
Se suas sessões do Claude Code atualmente parecem conversas longas e errantes que pioram quanto mais duram, a solução não é um modelo melhor. É uma barra, quatro letras, e a disciplina de limpar o que você não precisa. Vá construir um comando personalizado esta semana — o exemplo /scope acima, copiado direto em .claude/commands/scope.md — e use-o na sua próxima tarefa real. A primeira vez que as perguntas de esclarecimento do Claude capturarem uma suposição errada antes de se tornar código errado, você entenderá por que digito aquela barra antes do meu cérebro terminar o pensamento.
Perguntas frequentes
Qual é a diferença entre /clear e /rewind no Claude Code?
/clear limpa seu histórico de conversa atual para começar uma tarefa fresca mantendo sua memória de projeto CLAUDE.md, enquanto /rewind rebobina para um ponto de controle anterior dentro de uma sessão ativa e pode restaurar seu código, conversa ou ambos. Use /clear quando mudar para uma tarefa não relacionada; use /rewind quando uma edição deu errado e você precisa desfazê-la. Veja a seção de gerenciamento de contexto acima para a análise completa.
/clear deleta minha memória de projeto CLAUDE.md?
Não — /clear só remove a conversa ativa da janela de contexto; seu arquivo CLAUDE.md é recarregado fresco no início de cada sessão, então ele sobrevive à limpeza. É exatamente por isso que você pode limpar agressivamente entre tarefas sem perder o contexto duradouro do seu projeto, desde que o importante viva no CLAUDE.md.
Como crio um comando slash personalizado no Claude Code?
Crie um arquivo Markdown em .claude/commands/ (de escopo de projeto) ou ~/.claude/commands/ (pessoal), e o nome do arquivo se torna o nome do comando enquanto o conteúdo do arquivo se torna o prompt enviado ao Claude. Use o marcador $ARGUMENTS para passar entrada após o nome do comando. O exemplo completo de /scope esclarecer-depois-planejar está na seção de planejamento acima.
Existe um comando /plan ou é modo plano no Claude Code?
Ambos — modo plano está integrado no ciclo de permissões há muito tempo (pressione Shift+Tab duas vezes), e a partir do Claude Code v2.1.0 também há um comando literal /plan que ativa o mesmo estado de planejamento somente leitura. Se /plan não faz nada no seu setup, você provavelmente está em uma versão mais antiga; o atalho Shift+Tab sempre funciona.
Existe um comando /goal integrado no Claude Code?
Não, não há um comando /goal padrão no Claude Code que execute uma tarefa até uma definição de "pronto" com verificação automática. Essa capacidade é um padrão que você constrói você mesmo usando um comando personalizado mais um subagente de verificação. O Codex da OpenAI inclui um comando /goal separado, mas essa é uma ferramenta completamente diferente.
Vamos trabalhar juntos
Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.
- Fiverr (construções personalizadas e integrações): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e branding): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
