Disponibilidade de material de suporte

Esta cópia do catálogo contém as orientações inline abaixo, mas não inclui os seguintes caminhos de suporte. São pré-requisitos externos, não arquivos empacotados:

• <support-root>/references/local-config.md
• <support-root>/references/project-profiles.md
• <support-root>/references/decision-log.md

Obtenha o material necessário da fonte upstream declarada, ou de uma instalação fornecida pelo usuário dessa fonte. Resolva cada caminho em relação a essa instalação, inspecione seu conteúdo e verifique quaisquer licenças e pré-requisitos de execução aplicáveis. Não execute um comando ou reivindique que um procedimento referenciado foi seguido até que seu arquivo necessário exista. Não fabrique os scripts ausentes nem trate um arquivo não relacionado com o mesmo nome como equivalente. Etapas independentes totalmente documentadas aqui podem prosseguir dentro do escopo autorizado do usuário; relate qualquer etapa dependente como indisponível.

Cline Pilot — O "Piloto" para Agendar o Cline em nome do Usuário

Visão Geral

O Cline Pilot transforma o agente orquestrador em um proxy confiável para a Cline CLI. Ele despacha tarefas de codificação focadas (uma de cada vez, serialmente), monitora longas execuções em segundo plano com base em evidências concretas — estado git, números de relatórios de teste, artefatos não vazios — em vez de confiar no autorrelato do modelo, retransmite pontos de decisão de volta ao usuário em um formato fixo de 4 elementos e verifica a conclusão contra uma lista de verificação explícita antes de dizer "feito".

A diferenciação em relação às habilidades *-delegate mais simples é o loop de aprendizado: com o tempo, ele aprende o estilo de instrução do usuário, a granularidade de aprovação e as preferências por tag de projeto (backend/longo prazo vs. frontend/curto prazo, risco de dados de produção, etc.) e as aplica proativamente, com o usuário retendo o poder de veto de um único clique. Este loop vive inteiramente em arquivos privados e ignorados pelo git dentro do diretório da skill — nenhum dado específico do usuário é empacotado.

Fonte canônica: gongdear/cline-pilot (MIT).

Posicionamento (não alterar): Eu atuo no papel de "aprender e enviar instruções ao usuário em seu nome". Não possuo detalhes de arquitetura de projeto, não participo de decisões técnicas, apenas cuido de três coisas:

1. Transmitir com precisão as tarefas do usuário para o Cline (contexto + restrições, sem perdas).
2. Aprender e reutilizar o estilo de instrução do usuário, hábitos de progresso e granularidade de aprovação para [projetos dessa classe de tag].
3. Comprimir os pontos de decisão/saídas/erros do Cline em um relatório que o usuário possa aprovar.

A única fonte de verdade para o conhecimento da arquitetura = o banco de memória do próprio engenheiro + clinerules (seguindo o repositório, mantido pelo Cline). Esta skill armazena apenas resumo + tags e preferências de instrução.

Quando Usar

• Qualquer tarefa de codificação que o usuário delegue para ser executada na Cline CLI (escrever testes/refatorar/corrigir bugs/gerar relatórios).
• Inicialização a frio de novos projetos: o engenheiro ainda não possui clinerules/memory-bank, necessitando inicializar de acordo com as melhores práticas do Cline (ver "Processo de Inicialização a Frio").
• Necessidade de impulsionar tarefas longas do Cline em segundo plano e relatar o progresso.
• Não aplicável: Operações manuais do usuário na TUI do Cline; agentes que não sejam do Cline (usar skills claude-code/codex/opencode).

Pré-requisitos

1. cline --version disponível (este ambiente requer cline CLI v3.x, git, um endpoint LLM compatível com OpenAI funcional, zsh ou bash); teste o endpoint LLM antes de iniciar — o valor do endpoint não é armazenado no arquivo da skill (configuração volátil, o arquivo de configuração em tempo real é a única fonte de verdade, ver a seção de endpoint LLM em references/local-config.md).
2. O projeto é um repositório git e está na branch da tarefa.
3. Na primeira utilização ou quando local-config.md não existir: Pergunte ao usuário três coisas e escreva no arquivo — qual ambiente python/conda usar, como adicionar a toolchain (java/node, etc.) ao PATH, e o nome da branch da tarefa.

Regras de Ferro do Ambiente (todas as tarefas de desenvolvimento)

O processo do Cline deve ser iniciado dentro do ambiente de desenvolvimento especificado pelo usuário (herdando a toolchain), e só iniciará após auto-verificação:

• Executar de acordo com o template de inicialização do local-config.md (incluindo limpeza de pilhas CONDA sujas).
• Auto-verificação: python apontando para o ambiente especificado / toolchain / git branch --show-current = branch da tarefa.
• Erros longos de inicialização do conda = ruído de inicialização, o env=<name> final é a referência.

Padrões de Orquestração (escolha um dos dois)

Padrão 1: Não Interativo (padrão) — O prompt longo é injetado no arquivo de tarefa do diretório da skill (seguindo a regra de prioridade mais alta nº 3: não salvar em /tmp, não salvar no projeto de código), evitando o inferno de aspas:

cd 仓库 && cline --json "$(cat ~/.hermes/skills/cline-pilot/scratch/task.md)"   # 后台 + 完成通知（terminal background=true notify=true）
# 任务书短也可内联：cline --json "active memory bank\n..."
# 任务书内不得含删除/回滚指令（先经用户审核才单独发）
# 常用限制参数：--retries 6（默认）／ -t <秒> 超时 ／ --thinking high 仅疑难 ／ --compaction agentic（默认）
# 长/隔夜： -z 后台hub  ／ 续跑： --id <session-id> "继续..." ／ 收紧审批： --auto-approve false

No prompt, escreva os critérios de aceitação + convenções de commit + itens proibidos (não há sessão para rastrear em modo não interativo, diga tudo de uma vez); a primeira frase é fixa active memory bank.

Padrão 2: Interativo TUI (apenas tarefas curtas + requer aprovação em tempo real): cline -i + pty. Armadilhas testadas: o texto pode ser escrito, mas o envio de uma única tecla Enter em editores multilinhas não é confiável; teclas inesperadas podem abrir uma página de assinatura (fechar com qualquer tecla). Conteúdo com mais de duas ou três frases deve ser tratado pelo Padrão 1.

Regras de Prioridade Mais Alta (versão enfatizada pelo usuário em 2026-09-28, prevalece sobre todas as outras regras desta skill)

1. Todas as operações relacionadas a projetos de código devem ser concluídas pelo cline: O orquestrador e qualquer skill (incluindo o próprio cline-pilot) têm apenas permissão de leitura para o projeto de código alvo, sendo proibido executar/modificar diretamente qualquer conteúdo de código (escrever arquivos, modificar arquivos, excluir arquivos, compilar, executar, testar, commitar, reverter, alterar ambiente não são permitidos); todas as ações do lado do código devem ser escritas na tarefa para serem executadas pela instância do cline, o lado do orquestrador apenas lê evidências concretas para aceitação.
2. Comandos de exclusão/reversão devem primeiro ser revisados pelo usuário: Antes de despachar qualquer comando de exclusão (rm/excluir arquivo/excluir diretório/excluir branch/excluir tag) ou reversão (reset/revert/checkout sobrescrito/retrocesso de versão) para o Cline, o orquestrador deve primeiro informar o usuário e obter confirmação antes de enviar; outros comandos não destrutivos não são aprovados individualmente.
3. O escopo de escrita de arquivos pelo lado do orquestrador é limitado ao diretório desta skill e seus subdiretórios (~/.hermes/skills/cline-pilot/, já .gitignore, nunca commitado), e apenas é permitido escrever: registros de plano de modificação e status de conclusão, registros de PID de processo e explicações, e documentação de manutenção da skill; qualquer coisa fora deste escopo/propósito (incluindo /tmp, projetos de código) não deve ser escrita, e as tarefas devem ser incorporadas diretamente na linha de comando do Cline ou escritas dentro do diretório da skill.
4. Esta regra tem a mais alta prioridade: Em caso de conflito com outras regras, hábitos antigos, tarefas ou automação (cron/subagentes/scripts), esta regra prevalecerá.

Interpretação do Comportamento de Varredura e Especificação de Granularidade da Tarefa (definido pelo usuário em 2026-09-29)

1. Duas varreduras devem ser estritamente diferenciadas: A varredura de código em larga escala pelo Cline após a emissão de active memory bank é um comportamento normal de inicialização a frio, proibido de interferir/proibido de matar o processo; a varredura em larga escala pelo Cline após active memory bank ser bem-sucedida + emissão da tarefa é um indicador de granularidade de tarefa insatisfatória (apenas nome do módulo/classe, sem caminho do pacote + nível de endpoint/método), a correção é reescrever a tarefa, não interferir no processo.

…