arch-linux-triage

Visão geral da skill arch-linux-triage

O que a arch-linux-triage faz

arch-linux-triage é uma skill focada em troubleshooting de problemas no Arch Linux que exigem mais do que uma resposta genérica do tipo “tente reinstalar”. Ela orienta o agente para um diagnóstico específico de Arch com pacman, systemctl, journalctl, atenção a reboot e instruções de rollback ou limpeza.

Para quem ela é indicada

Esta skill é ideal para quem está depurando updates quebrados, serviços que falharam, regressões de boot, conflitos de pacotes ou comportamentos estranhos após upgrade no Arch Linux. Ela é mais útil para quem quer comandos prontos para copiar e colar e uma sequência de troubleshooting mais segura, e não apenas uma explicação de alto nível.

O problema real que ela resolve

Na prática, o objetivo é transformar um relato vago como “o áudio quebrou depois do update” ou “o serviço não inicia” em um fluxo estruturado de triagem com comandos, checkpoints e validação. Isso é especialmente importante no Arch, porque problemas em rolling release costumam depender de updates recentes, do estado atual do sistema e de fatores como reboot pendente ou incompatibilidade de kernel.

Por que esta skill é melhor do que um prompt comum

Um prompt comum pode gerar orientações para Linux genéricas demais, misturando distros ou pulando etapas de validação. arch-linux-triage conduz explicitamente o agente a:

• confirmar o momento do update e as premissas do ambiente
• usar primeiro ferramentas relevantes para Arch
• fornecer comandos de remediação que você pode executar diretamente
• validar cada mudança importante
• incluir etapas de rollback ou limpeza

O que está faltando no repositório

O repositório é intencionalmente minimalista: existe apenas o arquivo SKILL.md. Isso facilita inspecionar a arch-linux-triage skill, mas também significa que não há scripts auxiliares, diagnósticos prontos nem documentação de referência incluídos. A qualidade da resposta depende bastante do snapshot e do resumo do problema que você fornecer.

Como usar a skill arch-linux-triage

Leia SKILL.md primeiro

Comece por skills/arch-linux-triage/SKILL.md no repositório upstream. Esse arquivo define as entradas, a sequência obrigatória de troubleshooting e a estrutura esperada da saída. Como não há arquivos de apoio, ler esse único arquivo já mostra praticamente todo o contrato da skill.

Entenda as três entradas que realmente importam

A skill foi construída em torno de três entradas:

• ProblemSummary para o sintoma e a mudança recente
• ArchSnapshot para o contexto do sistema
• Constraints para o que você pode ou não pode fazer

Se você só puder fornecer uma coisa, priorize um ProblemSummary preciso. Se quiser resultados melhores, adicione também um snapshot enxuto do sistema.

O que incluir em ProblemSummary

Um bom arch-linux-triage usage começa com uma descrição do problema que diga qual componente falhou, quando isso aconteceu e qual foi o impacto. Bons exemplos:

• “Depois de pacman -Syu ontem, sshd não inicia e a porta 22 está fechada.”
• “O notebook dá boot, mas o login gráfico entra em loop depois do update do NVIDIA.”
• “O áudio do PipeWire sumiu após upgrade de kernel; tanto os alto-falantes quanto o Bluetooth falham.”

Exemplo fraco:

• “O Arch quebrou.”

O que incluir em ArchSnapshot

Para arch-linux-triage for Debugging, o snapshot deve reduzir a adivinhação. Inclua apenas o que realmente muda o diagnóstico:

• quando ocorreu o pacman -Syu mais recente
• versão do kernel e se você já reiniciou
• nome do pacote ou serviço afetado
• erro relevante de systemctl status ou journalctl
• ambiente desktop ou detalhe de hardware, se for relevante
• se é bare metal, VM ou host remoto

Adicione restrições antes que o agente sugira passos arriscados

Use Constraints para impedir orientações inseguras ou inviáveis. Exemplos:

• “Servidor remoto; evitar reboot até ser último recurso.”
• “Sem acesso à rede, apenas console local.”
• “Root criptografada; não sugerir reinstalação.”
• “Preciso de downtime mínimo; prefira correções reversíveis.”

Esta é uma das partes de maior impacto do arch-linux-triage guide.

Como transformar um objetivo vago em um prompt forte

Uma boa invocação normalmente tem quatro partes: sintoma, gatilho, evidência e limites. Exemplo:

“Use arch-linux-triage. Problema: nginx.service parou de iniciar depois de um update completo do sistema hoje. Snapshot: Arch x86_64, kernel 6.x, reiniciado uma vez, systemctl status nginx mostra falha de configuração ou dependência, journalctl -u nginx -b disponível. Constraints: host de produção, evitar remoção de pacotes a menos que seja necessário. Forneça passos de triagem, comandos de remediação, validação após cada mudança e opções de rollback.”

O que esperar de uma boa saída

A skill orienta o agente a retornar:

• Summary
• Triage Steps
• Remediation Commands
• Validation
• Rollback/Cleanup

Essa estrutura é útil porque separa diagnóstico de ação. Se a resposta pular validação ou rollback, peça ao agente para gerar novamente no formato exato da skill.

Melhor fluxo de trabalho para incidentes reais

Use a arch-linux-triage skill nesta ordem:

1. descreva os sintomas e os updates recentes
2. colete uma ou duas saídas reais de comandos
3. deixe o agente propor uma sequência de triagem
4. execute apenas os primeiros passos seguros de diagnóstico
5. devolva os resultados
6. peça uma remediação mais direcionada e a verificação correspondente

Isso funciona melhor do que pedir a correção completa logo de cara, especialmente quando a primeira hipótese pode estar errada.

Caminho no repositório e realidade da instalação

Não há nenhum comando de instalação documentado em SKILL.md, e as evidências do repositório mostram que não existem recursos ou scripts extras. Trate arch-linux-triage install como “adicione a skill pelo cliente com suporte a skills e depois inspecione SKILL.md”. Se o seu ambiente suportar skills baseadas em GitHub, o caminho relevante no código-fonte é skills/arch-linux-triage/SKILL.md.

Dicas práticas que melhoram a qualidade da saída

Para um arch-linux-triage usage melhor, forneça:

• nomes exatos de pacotes em vez de categorias amplas
• uma linha de erro real em vez de paráfrase
• se o problema apareceu antes ou depois do reboot
• se é um problema de pacote, serviço, boot ou regressão de hardware
• o que você já tentou, para o agente não entrar em loop

FAQ da skill arch-linux-triage

A arch-linux-triage serve só para problemas de pacote?

Não. Ela mira claramente troubleshooting com pacman, systemd e rolling release, então também se aplica a falhas de serviço, regressões após update, problemas próximos ao boot e situações em que os logs importam mais do que o estado dos pacotes.

Quando ela é melhor do que um prompt normal de troubleshooting Linux?

Use arch-linux-triage quando a sequência específica do Arch importa. Prompts genéricos costumam ignorar o estado do banco de pacotes, as implicações de reboot após update de kernel ou a importância de verificar journalctl e systemctl antes de sugerir correções.

A skill é amigável para iniciantes?

Sim, com uma ressalva: ela fornece remediação orientada por comandos, então iniciantes devem colar de volta as saídas exatas em vez de improvisar. A skill é mais segura quando usada de forma interativa, um passo por vez, e não como um script único para “corrigir tudo”.

Quando você não deve usar arch-linux-triage?

Não conte com ela para sistemas que não sejam Arch, resposta ampla a incidentes de segurança ou reparo de hardware sem dados observáveis no Linux. Ela também não é uma boa escolha se você não puder fornecer logs, nomes de serviços, momento do update ou qualquer detalhe concreto do sintoma.

Ela ajuda com servidores remotos?

Sim, especialmente se você informar cedo as restrições de acesso remoto. Assim, a skill pode priorizar inspeção, comandos reversíveis e atenção a reboot, em vez de assumir um cenário de recuperação local em desktop.

O repositório inclui diagnósticos automatizados?

Não. O repositório contém apenas a definição da skill. Não há shell scripts, coletores de logs, regras nem referências incluídos, então o agente não consegue inspecionar seu sistema automaticamente a menos que você forneça as saídas.

Como melhorar a skill arch-linux-triage

Forneça evidências, não só conclusões

A forma mais rápida de melhorar os resultados de arch-linux-triage é colar saídas brutas curtas:

• systemctl status <service>
• journalctl -u <service> -b
• a mensagem de erro do pacman
• status do kernel ou do reboot

Evidência bruta ajuda o agente a distinguir entre problemas de dependência, quebra de configuração, conflitos de pacote e processos em runtime desatualizados.

Separe diagnóstico de remediação

Peça à skill “triagem primeiro, correção depois” quando a situação for arriscada. Isso reduz sugestões ruins em produção ou em hosts remotos. Também torna o planejamento de rollback mais realista.

Diga ao agente o que mudou recentemente

Problemas no Arch costumam ser puxados por updates. Informe:

• último estado em que tudo funcionava
• pacotes atualizados antes da falha
• se houve reboot
• se o problema é novo ou intermitente

Esta é uma das formas mais fortes de melhorar a arch-linux-triage skill sem alterar o repositório.

Fique atento aos modos de falha mais comuns

A skill ainda pode ter desempenho fraco se você fornecer:

• nenhum nome de pacote ou serviço
• nenhum log
• uma descrição misturando ambiente Arch e não-Arch
• objetivos vagos como “otimize meu sistema”
• restrições só depois que o agente já sugeriu passos disruptivos

Peça verificação após cada correção

A skill já espera validação, mas os resultados ficam melhores se você exigir checkpoints explícitos, como:

• “mostre como fica o estado de sucesso após cada comando”
• “inclua um comando de validação por mudança”
• “adicione rollback se a validação falhar”

Isso torna arch-linux-triage for Debugging mais confiável em troubleshooting ao vivo.

Itere com a saída do primeiro comando

O melhor segundo prompt geralmente não é “isso não funcionou”, e sim “aqui está a saída exata da etapa 1”. Isso permite que a skill refine o caminho com base no estado real, em vez de continuar adivinhando a partir do sintoma original.

Melhore o repositório se você mantém a skill

Se você quiser tornar arch-linux-triage mais fácil de adotar, as adições de maior valor seriam:

• exemplos de conjuntos de entrada para problemas de pacote, serviço e boot
• um padrão curto de “safe on remote host”
• exemplos de fluxos guiados por journalctl e systemctl
• orientação para regressões pós-pacman -Syu e checagens de reboot

Essas adições melhorariam de forma concreta a confiança na instalação e a qualidade do primeiro uso mais do que texto extra de marketing.