Context Master

O que Context Master faz?

Habilidade universal de gerenciamento de contexto e planejamento para tarefas complexas, sessões longas e projetos com múltiplos arquivos. Funciona da mesma forma no Web App, na API ou no Claude Code CLI; bônus específicos do CLI estão em references/claude-code-cli.md.

Este SKILL.md é intencionalmente curto. O material detalhado está em references/ — carregue apenas o que precisar.

Quando ativar

Ative proativamente sempre que a solicitação corresponder a um dos seguintes:

• Projeto com múltiplos arquivos (3+ arquivos relacionados, sites, apps, APIs, conjuntos de documentos).
• Decisão de arquitetura ou tecnologia ("devemos usar X ou Y", "qual abordagem…").
• Pesquisa / comparação / análise de trade-offs.
• Trabalho de refatoração ou migração.
• Longa sessão de código onde a eficiência de contexto é importante.
• Qualquer tarefa com 3+ etapas sequenciais ou dependências compartilhadas.

Se a solicitação for um único arquivo sem dependências, pule esta habilidade.

O fluxo de trabalho de 5 etapas (memorize isto)

Para qualquer projeto com múltiplos arquivos — sites, apps, APIs, conjuntos de documentação — execute estas cinco etapas em ordem:

1. PARE — não crie nenhum arquivo ainda.
2. PLANEJE — use pensamento estendido ou um documento de planejamento (ambos igualmente válidos; veja references/multi-file-planning.md).
3. ANUNCIE — informe a lista de arquivos e a ordem de criação ao usuário.
4. CRIE — escreva os arquivos na ordem ideal (fundações antes das dependentes).
5. VERIFIQUE — verifique se toda referência é resolvida; corrija problemas antes de declarar concluído.

Exemplo prático (site de portfólio)

Usuário: "Crie um portfólio com páginas inicial, sobre, projetos e contato."

Etapa 1 PARE    -- não comece com index.html.
Etapa 2 PLANEJE -- "Pense bastante sobre a arquitetura: 5 arquivos necessários,
                  styles.css é a dependência compartilhada."
Etapa 3 ANUNCIE -- "Criarei:
                  1. styles.css       (estilização compartilhada)
                  2. index.html       (referencia styles.css)
                  3. about.html
                  4. projects.html
                  5. contact.html"
Etapa 4 CRIE    -- escreva os arquivos nessa ordem.
Etapa 5 VERIFIQUE -- todo arquivo HTML referencia styles.css; a navegação funciona.

Resultado: sem refatoração, sem re-exportação, sem links quebrados.

O modelo completo, padrões de ordem ideal por tipo de projeto (site / React / API backend / etc.) e listas de verificação estão em references/multi-file-planning.md.

Princípios fundamentais (uma linha cada)

1. Planeje antes de escrever — pensamento estendido ou documento de planejamento, nunca ambos ignorados.
2. Fundações primeiro — dependências compartilhadas (CSS, configuração, classes base, schemas) precedem as dependentes.
3. Delegue análise profunda a contextos isolados — subagentes (CLI) ou artefatos de pensamento (Web/API) mantêm o thread principal limpo.
4. Limites de fase — nomeie cada fase ("Fase 1 concluída; passando para a Fase 2: …") para que o contexto não se misture.
5. Artefatos em vez de conteúdo inline — código longo ou documentação fica em artefatos/arquivos, não no histórico do chat.
6. Divulgação progressiva — peça uma parte de cada vez; não agrupe etapas não relacionadas.
7. Sinalização de mudança — diga "deixando de lado a abordagem anterior…" ao mudar de direção.
8. Reflita após grandes projetos — foi planejado? As referências quebraram? Use a lista de verificação pós-projeto em references/multi-file-planning.md.

Justificativa completa e exemplos para cada princípio: references/universal-best-practices.md.

Regra prática de economia de tokens

Tamanho do projeto	Sem planejamento	Com planejamento	Economia
Pequeno (3-4 arquivos)	~6.000 tokens	~2.500 tokens	~58%
Médio (7-8 arquivos)	~12.000 tokens	~4.500 tokens	~63%
Grande (20+ arquivos)	~35.000 tokens	~12.000 tokens	~66%

Uma janela de contexto de 200.000 tokens comporta aproximadamente 16-17 projetos médios com planejamento, 7-8 sem — um aumento efetivo de 2,1x. Números e metodologia em references/multi-file-planning.md.

Arquitetura passiva de pensamento profundo

O padrão mais poderoso para eficiência de contexto: roteie o raciocínio profundo para um espaço isolado e retorne um breve resumo ao thread principal.

• Claude Code CLI: /agent deep-analyzer "Pense profundamente sobre [decisão]" — ~5.000 tokens de raciocínio ocorrem fora do thread; o contexto principal recebe um resumo de ~200 tokens (~23x de eficiência).
• Web / API: "Crie um artefato de análise profunda e pense profundamente sobre [decisão]" — mesma ideia, artefato em vez de subagente.

Gatilhos, anti-padrões e prompts prontos: references/thinking-delegation.md.

Fluxos de trabalho comuns (apontadores apenas)

Cada um destes tem um procedimento passo a passo em references/workflows.md:

• Fluxo de trabalho 0 — Criação de site/projeto com múltiplos arquivos (o padrão — mesmas 5 etapas acima com detalhes extras).
• Fluxo de trabalho 1 — Tomada de decisão complexa (arquitetura, escolha de tecnologia).
• Fluxo de trabalho 2 — Desenvolvimento de funcionalidade complexa (análise → design → implementar → testar → integrar).
• Fluxo de trabalho 3 — Pesquisa e avaliação de tecnologia.
• Fluxo de trabalho 4 — Geração e iteração de código via artefatos.
• Fluxo de trabalho 5 — Refatoração com análise isolada.

Anti-padrões (evite estes)

Lista rápida — exemplos e correções em references/anti-patterns.md:

1. Criar arquivos antes de planejar — desperdiça contexto com refatorações.
2. Pedir tudo de uma vez — sobrecarrega o contexto e produz saída superficial.
3. Colocar código/documentação longos inline no chat — incha o histórico; use artefatos/arquivos.
4. Deixar raciocínio profundo ocorrer no thread principal — custa ~5.000 tokens que poderiam ser ~200.
5. Sem limites de fase — o contexto se mistura entre subtarefas não relacionadas.

Solução de problemas

Quando as sessões se desviam (respostas sem foco, conversas muito longas, código sendo regenerado em vez de editado, pensamento estendido não engajando), veja references/troubleshooting.md para uma tabela de sintoma → remédio cobrindo Web/API e CLI separadamente.

Bônus do Claude Code CLI

Se você estiver executando no Claude Code CLI, também tem:

• /clear, /compact, /continue — controles de contexto integrados.
• /agent <nome> — delegue para um subagente isolado.
• CLAUDE.md — memória persistente do projeto.
• Scripts auxiliares para gerar CLAUDE.md e definições de subagentes.

Detalhes, invocações de script e padrões de delegação de análise profunda: references/claude-code-cli.md.

Padrões de integração habilidade–subagente (quando ambos estão disponíveis) estão em references/agent-skills-integration-2025.md. Estratégias de contexto de longa duração e padrões de prompt para subagentes: references/context_strategies.md e references/subagent_patterns.md.

Mapa de referência

Arquivo	Quando usar
references/multi-file-planning.md	Modelo de planejamento, padrões de ordem ideal por tipo de projeto, listas de verificação, reflexão pós-projeto.
references/universal-best-practices.md	Precisar da justificativa ou exemplos para qualquer um dos 8 princípios fundamentais.
references/workflows.md	Precisar de um procedimento passo a passo para um cenário específico (decisão, funcionalidade, pesquisa, refatoração).
references/thinking-delegation.md	Projetar uma delegação de análise profunda ou escrever o prompt de pensamento.
references/anti-patterns.md	Revisar se a abordagem atual está desperdiçando contexto.
references/troubleshooting.md	A sessão está se desviando, lenta ou produzindo explicação demais.
references/claude-code-cli.md	Executando no Claude Code CLI e querendo ferramentas de subagente / CLAUDE.md.
references/agent-skills-integration-2025.md	Combinando habilidades com subagentes no CLI.
references/context_strategies.md	Notas de estratégia de longa duração.
references/subagent_patterns.md	Padrões de prompt para subagentes.

Indicadores de sucesso

• Você anunciou o plano antes de criar qualquer arquivo.
• Arquivos de fundação (CSS, configuração, schemas) foram escritos antes das dependentes.
• Nenhuma referência quebrou na primeira execução; nenhuma refatoração foi necessária.
• O raciocínio profundo ocorreu em um subagente ou artefato, não no thread principal.
• As fases foram nomeadas à medida que você as cruzava.

Se algum desses falhou, revise references/anti-patterns.md e references/multi-file-planning.md seção pós-projeto antes da próxima tarefa.