Modulos
3.1
Hierarquia de CLAUDE.md
3 niveis de config, @import modular, .claude/rules/ por topico
~25 min · 6 topicos
3.2
Commands e Skills Customizados
Commands de projeto, pessoais, Skills com SKILL.md e frontmatter
~25 min · 6 topicos
3.3
Regras Condicionais por Caminho
Frontmatter YAML paths, carregamento condicional, glob patterns
~20 min · 6 topicos
3.4
Plan Mode vs Execucao Direta
Quando usar plan mode, execucao direta, subagente Explore
~25 min · 6 topicos
3.5
Tecnicas de Refinamento Iterativo
Exemplos concretos, iteracao test-driven, padrao entrevista
~25 min · 6 topicos
3.6
Claude Code em CI/CD
Flag -p nao-interativo, --output-format json, pipeline pratico
~30 min · 6 topicosConteudo Detalhado
3.1
Hierarquia de CLAUDE.md
Compreenda os 3 niveis de configuracao do Claude Code, como usar @import para modularidade e .claude/rules/ para regras por topico, otimizando o consumo de tokens.
O que e: O arquivo ~/.claude/CLAUDE.md e o nivel mais alto de configuracao pessoal do Claude Code. Ele e carregado em TODAS as sessoes, independentemente do projeto. Contem preferencias globais como estilo de comunicacao, convencoes de codigo pessoais e atalhos que voce usa em todos os projetos.
Por que aprender: Entender a hierarquia de configuracao e fundamental para o exame CCA. Saber que o nivel usuario e sempre carregado e se aplica a todos os projetos permite separar preferencias pessoais de regras de projeto, evitando duplicacao e conflitos.
Conceitos-chave: ~/.claude/CLAUDE.md como config global, carregamento automatico em todas as sessoes, preferencias pessoais vs regras de projeto, menor precedencia na hierarquia, ideal para estilo e convencoes pessoais.
O que e: O arquivo .claude/CLAUDE.md na raiz do projeto define configuracoes especificas do projeto. E versionado no Git e compartilhado com toda a equipe. Contem convencoes de codigo do projeto, estrutura de pastas, dependencias importantes e regras que todos os desenvolvedores devem seguir.
Por que aprender: O nivel projeto e o mais importante na pratica — define o comportamento padrao de Claude para todo o time. O exame testa a diferenca entre config pessoal e de projeto, e quando cada uma deve ser usada.
Conceitos-chave: .claude/CLAUDE.md na raiz do projeto, versionado no Git, compartilhado pela equipe, maior precedencia que nivel usuario, convencoes e regras do projeto.
O que e: Voce pode colocar CLAUDE.md em subdiretorios do projeto para definir regras especificas para aquela area. Por exemplo, um CLAUDE.md em src/api/ pode definir convencoes de API, enquanto um em src/frontend/ define regras de componentes React. Essas regras sao carregadas apenas quando Claude trabalha em arquivos daquele diretorio.
Por que aprender: Regras por diretorio permitem configuracao granular sem poluir o contexto global. O exame testa cenarios onde regras conflitantes em diferentes niveis devem ser resolvidas pela hierarquia de precedencia.
Conceitos-chave: CLAUDE.md em subdiretorios, carregamento por proximidade, precedencia local sobre global, regras contextuais por area do projeto, economia de tokens por escopo.
O que e: A diretiva @import permite incluir outros arquivos Markdown dentro do CLAUDE.md, criando uma estrutura modular. Em vez de um unico arquivo monolitico, voce pode dividir as regras em arquivos separados e importa-los conforme necessario, facilitando manutencao e reutilizacao.
Por que aprender: Projetos grandes precisam de configuracoes extensas. O @import permite organizar essas configuracoes de forma sustentavel, evitando arquivos CLAUDE.md gigantes que dificultam a manutencao e desperdicam tokens com regras irrelevantes.
Conceitos-chave: Sintaxe @import para incluir arquivos, modularizacao de regras, reutilizacao entre projetos, organizacao por dominio, reducao de duplicacao.
O que e: O diretorio .claude/rules/ permite criar arquivos de regras separados por topico (ex: testing.md, api-design.md, security.md). Cada arquivo contem regras especificas para um dominio, e podem ter frontmatter YAML para controlar quando sao carregados.
Por que aprender: O .claude/rules/ e a forma mais avancada e eficiente de configurar o Claude Code. Permite carregamento condicional baseado em caminhos, reduzindo drasticamente o consumo de tokens em projetos grandes.
Conceitos-chave: .claude/rules/ como diretorio de regras, um arquivo por topico, frontmatter YAML para condicoes, carregamento seletivo, economia de tokens por relevancia.
O que e: O CLAUDE.md serve para instrucoes ativas (regras que Claude deve seguir), nao como base de conhecimento passiva. Instrucoes sao imperativas ("sempre use TypeScript strict"), enquanto base de conhecimento e informativa ("o projeto usa TypeScript"). A distincao impacta como Claude interpreta e prioriza o conteudo.
Por que aprender: Misturar instrucoes com informacoes passivas dilui a eficacia do CLAUDE.md. O exame testa a capacidade de distinguir entre configuracao efetiva (instrucoes) e contexto informativo (base de conhecimento), e onde cada um deve ficar.
Conceitos-chave: Instrucoes imperativas vs informacoes descritivas, CLAUDE.md para regras ativas, documentacao do projeto para contexto, regras path-scoped economizam tokens, foco em acoes concretas.
3.2
Commands e Skills Customizados
Aprenda a criar commands de projeto e pessoais, skills com SKILL.md e frontmatter avancado para automacao e reutilizacao de workflows no Claude Code.
O que e: Commands de projeto sao arquivos Markdown em .claude/commands/ que definem workflows reutilizaveis. Cada arquivo .md se torna um slash command disponivel para toda a equipe. Sao versionados no Git e compartilhados automaticamente com todos os desenvolvedores do projeto.
Por que aprender: Commands de projeto padronizam workflows da equipe — como fazer deploy, criar componentes, rodar testes. O exame testa a diferenca entre commands de projeto (versionados) e pessoais (locais), e quando usar cada um.
Conceitos-chave: .claude/commands/ como diretorio de commands, arquivos .md como slash commands, versionamento no Git, compartilhamento com a equipe, invocacao via /nome-do-command.
O que e: Commands pessoais ficam em ~/.claude/commands/ e sao disponiveis em todos os projetos, mas apenas para voce. Sao ideais para workflows pessoais como formatacao de commits, templates de PR, ou atalhos de produtividade que nao fazem sentido para toda a equipe.
Por que aprender: A separacao entre commands pessoais e de projeto segue o mesmo principio da hierarquia CLAUDE.md. O exame testa se voce sabe onde colocar cada tipo de command para maximo compartilhamento sem poluir o escopo do projeto.
Conceitos-chave: ~/.claude/commands/ como diretorio pessoal, disponivel em todos os projetos, nao versionado no Git, preferencias individuais, complementa commands de projeto.
O que e: Skills sao uma evolucao dos commands que incluem um arquivo SKILL.md com frontmatter YAML. O frontmatter define metadados como context (fork/normal), allowed-tools, e argument-hint. Skills podem ser mais sofisticadas que commands simples, com isolamento de contexto e restricoes de ferramentas.
Por que aprender: Skills representam a forma mais avancada de automacao no Claude Code. O exame testa o uso correto de frontmatter YAML, especialmente context: fork para isolamento e allowed-tools para restringir ferramentas disponiveis.
Conceitos-chave: SKILL.md com frontmatter YAML, metadados de configuracao, context para modo de execucao, allowed-tools para restricoes, argument-hint para guiar parametros.
O que e: O campo context: fork no frontmatter de um SKILL.md faz com que a skill seja executada em um contexto isolado (fork da sessao atual). Isso significa que a skill tem sua propria janela de contexto, nao polui a conversa principal, e seus resultados sao retornados de forma compacta ao contexto original.
Por que aprender: Fork e essencial para skills que fazem operacoes verbosas (ex: busca em muitos arquivos) ou que precisam de isolamento. O exame testa quando usar fork vs execucao normal e os trade-offs de cada abordagem.
Conceitos-chave: context: fork para isolamento, janela de contexto separada, resultado compactado, nao polui conversa principal, ideal para operacoes verbosas ou exploratias.
O que e: O campo allowed-tools no frontmatter de SKILL.md restringe quais ferramentas estao disponiveis durante a execucao da skill. Por exemplo, uma skill de revisao pode ter allowed-tools: [Read, Grep, Glob] para impedir que faca modificacoes. Isso cria guardrails deterministicos por skill.
Por que aprender: Restringir ferramentas por skill e um padrao de seguranca fundamental. O exame testa cenarios onde skills com ferramentas demais causam problemas, e como allowed-tools resolve isso de forma deterministicael.
Conceitos-chave: allowed-tools como whitelist de ferramentas, restricao por skill, seguranca por design, prevencao de acoes indesejadas, guardrail deterministico vs instrucao no prompt.
O que e: O campo argument-hint no frontmatter fornece uma dica visual de que tipo de argumento a skill espera quando invocada. Por exemplo, argument-hint: "caminho do arquivo" mostra ao usuario o que passar apos o slash command. Melhora a UX sem impor restricoes tecnicas.
Por que aprender: Boas skills sao auto-documentadas. O argument-hint faz parte do conjunto de metadados que tornam skills descobriveis e faceis de usar, complementando o nome e a descricao do arquivo SKILL.md.
Conceitos-chave: argument-hint como dica visual, melhoria de UX, guia para o usuario, complementa nome do command, auto-documentacao de skills.
3.3
Regras Condicionais por Caminho
Domine o sistema de regras condicionais com frontmatter YAML paths em .claude/rules/, carregando regras apenas quando relevantes para economizar tokens.
O que e: Arquivos em .claude/rules/ podem ter frontmatter YAML com o campo paths que define quando a regra deve ser carregada. O frontmatter usa a sintaxe --- no inicio do arquivo, seguido de paths: com uma lista de glob patterns que determinam para quais arquivos a regra se aplica.
Por que aprender: O frontmatter paths e o mecanismo central das regras condicionais. O exame testa a sintaxe correta, a semantica dos glob patterns e como o carregamento condicional funciona na pratica.
Conceitos-chave: Sintaxe --- para frontmatter YAML, campo paths como lista de patterns, carregamento sob demanda, economia de contexto, regras aplicadas apenas quando relevantes.
O que e: Quando Claude edita ou le um arquivo, o sistema verifica quais regras em .claude/rules/ tem paths que correspondem ao caminho do arquivo. Apenas as regras cujos patterns fazem match sao carregadas no contexto. Regras sem frontmatter paths sao sempre carregadas (comportamento global).
Por que aprender: O carregamento condicional e a chave para escalar configuracoes em projetos grandes. Sem ele, todas as regras seriam carregadas sempre, desperdicando tokens com informacoes irrelevantes para a tarefa atual.
Conceitos-chave: Match baseado em arquivos editados/lidos, carregamento sob demanda, regras sem paths = globais, economia de tokens, escala para projetos grandes.
O que e: Os glob patterns usados no campo paths seguem a convencao padrao: * para qualquer sequencia em um nivel, ** para recursivo em subdiretorios, e extensoes especificas como *.ts, *.py. Exemplos: "src/api/**/*.ts" (todos os .ts em src/api), "*.test.js" (todos os arquivos de teste JS).
Por que aprender: Saber escrever glob patterns corretos e essencial para configurar regras condicionais eficazes. Patterns muito amplos carregam regras desnecessarias; muito estreitos perdem arquivos relevantes. O exame testa a interpretacao de patterns.
Conceitos-chave: * para nivel unico, ** para recursivo, extensoes especificas, combinacao de patterns, precisao vs cobertura, exemplos praticos de matching.
O que e: Regras condicionais por caminho economizam tokens porque so carregam instrucoes relevantes para os arquivos sendo manipulados. Em um projeto com 20 arquivos de regras, se Claude esta editando um arquivo .py, apenas as regras com paths matching *.py sao carregadas — nao as regras de TypeScript, CSS ou SQL.
Por que aprender: O consumo de tokens impacta diretamente custo e qualidade. Regras condicionais podem reduzir drasticamente o contexto carregado, liberando espaco para o raciocinio de Claude e os resultados das ferramentas.
Conceitos-chave: Tokens economizados por carregamento seletivo, menos contexto irrelevante, mais espaco para raciocinio, reducao de custo em projetos grandes, path-scoped rules como otimizacao.
O que e: Exemplos concretos de regras condicionais: testing.md com paths: ["**/*.test.*", "**/*.spec.*"] para regras de testes; api-design.md com paths: ["src/api/**", "src/routes/**"] para convencoes de API; security.md com paths: ["src/auth/**", "*.env*"] para regras de seguranca.
Por que aprender: Exemplos praticos consolidam a teoria. O exame apresenta cenarios reais e pede para configurar regras condicionais corretas, entao praticar com exemplos concretos e essencial para a preparacao.
Conceitos-chave: Regras de teste com patterns de test/spec, regras de API com patterns de rotas, regras de seguranca com patterns sensiveis, organizacao por dominio, nomes descritivos de arquivos.
O que e: Regras condicionais em .claude/rules/ sao superiores a CLAUDE.md por diretorio por varios motivos: centralizacao (todas as regras em um local), flexibilidade de paths (patterns podem cruzar diretorios), e carregamento por tipo de arquivo (nao apenas por diretorio). CLAUDE.md por diretorio so se aplica ao diretorio onde esta.
Por que aprender: O exame testa a escolha entre .claude/rules/ com paths e CLAUDE.md por diretorio. Saber as vantagens de cada abordagem permite responder corretamente questoes sobre configuracao otima em diferentes cenarios.
Conceitos-chave: Centralizacao vs distribuicao, paths por tipo de arquivo vs por diretorio, flexibilidade de glob patterns, manutencao simplificada, .claude/rules/ como abordagem preferida.
3.4
Plan Mode vs Execucao Direta
Saiba quando usar plan mode para tarefas complexas, execucao direta para tarefas simples, e como o subagente Explore auxilia na descoberta verbosa.
O que e: Plan mode faz Claude pensar e planejar antes de executar. Em vez de comecar a editar arquivos imediatamente, Claude primeiro analisa a codebase, identifica arquivos relevantes, propoe uma estrategia e espera aprovacao. So entao executa as mudancas planejadas.
Por que aprender: Plan mode e essencial para tarefas de grande escala como refatoracoes, migracoes ou features que tocam muitos arquivos. O exame testa quando plan mode e a escolha correta e quando execucao direta e mais eficiente.
Conceitos-chave: Planejamento antes de execucao, analise previa da codebase, aprovacao humana do plano, ideal para mudancas de grande escala, reduz risco de erros em cascata.
O que e: Execucao direta e o modo padrao do Claude Code — Claude analisa a requisicao e comeca a executar imediatamente, usando ferramentas conforme necessario. E ideal para tarefas simples, bem definidas e de escopo limitado, como corrigir um bug especifico, adicionar uma funcao ou modificar um arquivo.
Por que aprender: Usar plan mode para tarefas simples e desperdicio de tokens e tempo. O exame testa a capacidade de escolher o modo correto com base na complexidade da tarefa — execucao direta para tarefas simples, plan mode para complexas.
Conceitos-chave: Modo padrao do Claude Code, execucao imediata, ideal para tarefas simples, sem overhead de planejamento, eficiente para mudancas de escopo limitado.
O que e: O subagente Explore e uma funcionalidade que permite a Claude explorar a codebase de forma verbosa em um contexto isolado. Ele navega por arquivos, entende a estrutura e retorna um resumo compacto ao contexto principal. E como um "scout" que mapeia o terreno antes de Claude tomar decisoes.
Por que aprender: Explore e fundamental para tarefas em codebases desconhecidas. O exame testa quando usar Explore vs leitura direta de arquivos, e como o isolamento de contexto previne poluicao da conversa principal.
Conceitos-chave: Subagente de exploracao, contexto isolado, resultado compacto, ideal para codebases desconhecidas, previne poluicao da conversa principal.
O que e: A distincao entre tarefas complexas e simples guia a escolha entre plan mode e execucao direta. Tarefas complexas envolvem multiplos arquivos, dependencias entre mudancas, ou decisoes arquiteturais. Tarefas simples sao isoladas, bem definidas e de escopo claro — um arquivo, uma funcao, um bug.
Por que aprender: O exame apresenta cenarios e pede para classificar a complexidade e escolher o modo adequado. Saber avaliar a complexidade de uma tarefa e uma habilidade fundamental para usar Claude Code eficientemente.
Conceitos-chave: Criterios de complexidade: numero de arquivos, dependencias entre mudancas, ambiguidade dos requisitos, impacto potencial, reversibilidade das mudancas.
O que e: Na pratica, o melhor workflow combina ambos os modos: comece com plan mode para entender o escopo e definir a estrategia, depois execute cada etapa do plano em modo direto. Isso da visao global sem perder agilidade na execucao. Voce pode alternar entre modos dentro da mesma sessao.
Por que aprender: A combinacao de modos e a abordagem mais madura e produtiva. O exame testa se voce entende que plan e execucao nao sao mutuamente exclusivos, e como combina-los para diferentes fases de uma tarefa.
Conceitos-chave: Plan para estrategia global, execucao para implementacao, alternancia entre modos, fases de uma tarefa, flexibilidade de abordagem.
O que e: Decisoes de arquitetura — como estruturar modulos, definir interfaces, escolher padroes — devem sempre passar por plan mode. Essas decisoes tem impacto de longo prazo e sao dificeis de reverter. Plan mode permite discutir trade-offs, considerar alternativas e obter aprovacao antes de implementar.
Por que aprender: O exame testa cenarios onde decisoes arquiteturais tomadas em execucao direta levam a problemas. Saber identificar quando uma tarefa envolve decisoes arquiteturais e crucial para escolher o modo correto.
Conceitos-chave: Decisoes de alto impacto, irreversibilidade, discussao de trade-offs, aprovacao antes de implementacao, plan mode como checkpoint de qualidade.
3.5
Tecnicas de Refinamento Iterativo
Domine tecnicas para obter melhores resultados do Claude Code: exemplos concretos, iteracao test-driven, padrao entrevista e refinamento progressivo de requisitos.
O que e: Exemplos concretos de entrada/saida (I/O) sao muito mais eficazes que descricoes em prosa para comunicar requisitos a Claude. Em vez de "formate a saida como uma tabela bonita", mostre exatamente como a tabela deve ficar com dados reais. Exemplos concretos eliminam ambiguidade e reduzem iteracoes.
Por que aprender: O exame testa a eficacia de diferentes formas de comunicar requisitos. Exemplos concretos sao consistentemente mais eficazes que descricoes verbais, especialmente para formatos de saida, transformacoes de dados e regras de negocio.
Conceitos-chave: Exemplos I/O > prosa descritiva, eliminacao de ambiguidade, reducao de iteracoes, dados reais nos exemplos, formato de saida concreto.
O que e: Na iteracao test-driven, voce escreve os testes ANTES de pedir a Claude para implementar a funcionalidade. Os testes definem o contrato de forma inequivoca. Claude implementa ate que todos os testes passem. Isso cria um ciclo de feedback automatico onde os testes sao os criterios de aceitacao.
Por que aprender: Iteracao test-driven e a tecnica mais confiavel para obter resultados precisos do Claude Code. O exame testa quando usar TDD com Claude e como testes servem como especificacao executavel mais precisa que qualquer descricao textual.
Conceitos-chave: Testes como especificacao, escrever testes antes da implementacao, ciclo red-green com Claude, feedback automatico, criterios de aceitacao executaveis.
O que e: No padrao entrevista, em vez de dar instrucoes detalhadas de uma vez, voce pede a Claude para fazer perguntas antes de comecar a implementar. Claude identifica ambiguidades nos requisitos e pede esclarecimentos. Isso resulta em especificacoes mais completas e menos retrabalho.
Por que aprender: O padrao entrevista e especialmente valioso quando os requisitos sao vagos ou incompletos. O exame testa quando usar esse padrao e como ele previne implementacoes baseadas em suposicoes incorretas.
Conceitos-chave: Claude pergunta antes de implementar, identificacao de ambiguidades, esclarecimento de requisitos, prevencao de suposicoes, especificacao colaborativa.
O que e: Fornecer 2-3 exemplos concretos e o numero ideal para definir requisitos ambiguos. Um exemplo pode ser interpretado como caso unico; 2-3 exemplos revelam o padrao. Mais que 3 exemplos raramente adicionam valor e consomem tokens desnecessariamente. Os exemplos devem cobrir o caso normal, um edge case e opcionalmente um caso de erro.
Por que aprender: O exame testa a quantidade ideal de exemplos e que tipos de casos cobrir. Saber que 2-3 exemplos estrategicos sao mais eficazes que muitos exemplos redundantes e uma habilidade pratica testada no CCA.
Conceitos-chave: 2-3 exemplos como numero ideal, caso normal + edge case + erro, revelar padroes com multiplos exemplos, evitar redundancia, cobertura estrategica de cenarios.
O que e: Quando testes falham, compartilhar a saida completa do teste com Claude e mais eficaz que descrever o problema em palavras. A saida do teste contem informacoes precisas: qual assertion falhou, valor esperado vs recebido, stack trace. Claude usa esses dados para diagnosticar e corrigir com precisao.
Por que aprender: Compartilhar falhas de teste e uma tecnica de refinamento que acelera drasticamente o ciclo de correcao. O exame testa se voce sabe usar saida de testes como feedback preciso, em vez de descricoes verbais imprecisas.
Conceitos-chave: Saida de teste como feedback preciso, assertion falhou > descricao verbal, stack trace para diagnostico, ciclo de correcao acelerado, dados concretos > prosa.
O que e: Para dominios onde voce nao tem expertise (ex: configurar Kubernetes, otimizar queries SQL, implementar algoritmos criptograficos), o padrao entrevista combinado com exemplos e especialmente valioso. Peca a Claude para explicar as opcoes, faca perguntas sobre trade-offs, e use o padrao iterativo para refinar o resultado.
Por que aprender: Trabalhar em dominios desconhecidos e uma realidade do desenvolvimento. O exame testa como usar Claude Code efetivamente quando voce nao e especialista no dominio, aproveitando o conhecimento de Claude enquanto mantém controle da qualidade via testes e exemplos.
Conceitos-chave: Padrao entrevista para explorar dominio, exemplos para validar entendimento, testes como rede de seguranca, aprendizado iterativo, Claude como especialista consultado.
3.6
Claude Code em CI/CD
Integre Claude Code em pipelines CI/CD com modo nao-interativo, output JSON, sessoes separadas para revisao e boas praticas de automacao.
O que e: A flag -p (ou --prompt) executa Claude Code em modo nao-interativo: recebe um prompt como argumento, executa a tarefa e retorna o resultado sem esperar input do usuario. E essencial para CI/CD porque pipelines automatizados nao tem interacao humana.
Por que aprender: Integrar Claude Code em CI/CD requer modo nao-interativo. O exame testa o conhecimento da flag -p, suas limitacoes (sem confirmacao humana) e como configurar CLAUDE.md para compensar a falta de interacao.
Conceitos-chave: Flag -p para modo headless, sem interacao humana, prompt como argumento, saida para stdout, ideal para pipelines CI/CD automatizados.
O que e: A flag --output-format json faz Claude Code retornar a saida em formato JSON estruturado em vez de texto livre. Isso permite que scripts e pipelines CI/CD parseiem a saida programaticamente, extraindo campos especificos como resultado, erros, arquivos modificados e metricas.
Por que aprender: Output JSON e fundamental para automacao robusta. O exame testa quando usar output JSON vs texto e como integrar a saida estruturada com ferramentas de CI/CD como GitHub Actions, Jenkins ou scripts shell.
Conceitos-chave: --output-format json para saida estruturada, parsing programatico, integracao com scripts, campos extraiveis, automacao robusta.
O que e: No ambiente CI/CD, o CLAUDE.md do projeto e automaticamente carregado (pois esta no repositorio). Porem, o CLAUDE.md de usuario (~/.claude/CLAUDE.md) nao existe no runner CI. Isso significa que configuracoes especificas para CI devem estar no CLAUDE.md do projeto ou em regras dedicadas como .claude/rules/ci.md.
Por que aprender: O exame testa o entendimento de que o ambiente CI e diferente do ambiente do desenvolvedor. Saber que o CLAUDE.md de usuario nao esta disponivel no CI e como compensar isso e uma questao pratica frequente.
Conceitos-chave: CLAUDE.md de projeto disponivel no CI, CLAUDE.md de usuario ausente, regras especificas para CI, configuracao via .claude/rules/, ambiente CI vs local.
O que e: Uma pratica recomendada em CI/CD e usar uma sessao SEPARADA de Claude para revisar o trabalho de outra sessao. A sessao de implementacao gera o codigo; uma segunda sessao, com contexto limpo, revisa as mudancas. Isso evita o vies de auto-revisao onde o mesmo agente avalia seu proprio trabalho.
Por que aprender: O exame testa o conceito de auto-revisao enviesada e como sessoes separadas mitigam esse problema. E um padrao fundamental para qualidade em pipelines automatizados com Claude.
Conceitos-chave: Sessao de implementacao vs sessao de revisao, contexto limpo para revisao, evitar auto-revisao enviesada, pipeline de qualidade, duas invocacoes separadas.
O que e: Auto-revisao enviesada ocorre quando a mesma sessao de Claude que implementou o codigo e usada para revisar esse mesmo codigo. Claude tende a avaliar positivamente seu proprio trabalho porque o raciocinio que levou a implementacao ainda esta no contexto, criando um vies de confirmacao sistematico.
Por que aprender: Este e um anti-padrao critico testado no exame CCA. Entender por que auto-revisao e enviesada e como resolver (sessao separada) e fundamental para projetar pipelines de qualidade com Claude.
Conceitos-chave: Vies de confirmacao em auto-revisao, raciocinio no contexto influencia avaliacao, sessao separada como solucao, contexto limpo para objetividade, anti-padrao em pipelines CI/CD.
O que e: Um pipeline pratico com Claude Code em CI/CD tipicamente inclui: (1) Claude implementa a tarefa com -p, (2) testes automatizados rodam, (3) uma segunda sessao de Claude revisa as mudancas, (4) se tudo passa, o PR e criado ou atualizado automaticamente. Cada etapa usa --output-format json para parsing.
Por que aprender: O exame apresenta cenarios de pipeline e pede para identificar a configuracao correta. Saber montar um pipeline completo — da implementacao a revisao — e uma competencia pratica testada no CCA.
Conceitos-chave: Pipeline: implementar → testar → revisar → publicar, -p para cada etapa, --output-format json para integracao, sessoes separadas, CLAUDE.md do projeto como configuracao.