Atlas-X-AI/hermes-kanban-watch

Monitore os cartões Hermes Kanban como linhas de fluxo de trabalho ao vivo e somente leitura. Use após enviar uma onda, para ver workers em execução, estágios em espera, bloqueios e solicitações de revisão.

O que é hermes-kanban-watch?

Esta skill permite que o Claude Code observe cartões Hermes Kanban em tempo real, exibindo-os como linhas de fluxo de trabalho interativas sem modificar os cartões. Ela exibe workers em execução como linhas ativas, cartões na fila em linhas de espera e cartões bloqueados ou em revisão com indicações de ação necessária. A skill também suporta o rastreamento automático de cartões filhos recém-criados a partir de um cartão observado, a menos que `follow_new: false` seja definido. Funciona com Claude Code com suporte a Workflow ou pode operar como um leitor independente usando `hermes-kanban-live` diretamente. Para configurar, execute o script `doctor.py` com as opções apropriadas; ele requer Python 3.11+, Hermes no PATH e perfis Hermes existentes. A skill é estritamente somente leitura e não inicia workers, arquiva cartões ou modifica permissões. Ela também oferece scripts auxiliares para relatar ondas, verificar pares de famílias de modelos e sugerir rotas, todos respeitando as convenções de permissão do Claude Code e sem conceder acesso irrestrito ao Bash.

Funciona com✓Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/Atlas-X-AI/hermes-kanban-watch/tree/HEAD/plugin/skills/kanban-watch

Installed? Explore more Produtividade e Colaboração skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Observação do Hermes Kanban

Mostre workers do Hermes dentro do Claude Code sem assumir o controle de seus cartões. Cartões em execução recebem linhas ativas, cartões na fila compartilham linhas de espera, e paradas recebem linhas de "Precisa de você". Os filhos recém-criados de um cartão observado entram automaticamente, a menos que follow_new: false.

Instalar e verificar

Inicie o Claude Code com claude --plugin-dir /caminho/para/hermes-kanban-watch/plugin. O chamador resolve a raiz do plugin desta skill; use o sibling scripts/doctor.py. Execute python3 <raiz-do-plugin>/scripts/doctor.py --board default primeiro. É somente leitura. --fix cria um board padrão ausente com hermes kanban --board default init ou um board nomeado ausente com hermes kanban boards create <slug>, além de rotas de usuário e um shim hermes-kanban-live, sem sobrescrever arquivos existentes. Adicione ~/.local/bin ao PATH e execute o doctor novamente. O doctor exige que hermes-kanban-live --version imprima exatamente hermes-kanban-watch 0.3.0. Um comando estrangeiro/desatualizado é FALHA com seu caminho resolvido; mova-o para o lado ou corrija o PATH antes de executar --fix novamente, que nunca o sobrescreve. --probe testa explicitamente cada modelo roteado com PONG e pode consumir capacidade.

Requisitos: Python 3.11+, Hermes no PATH, Claude Code com suporte a Workflow e perfis Hermes existentes. Modelos e chaves pertencem a cada perfil Hermes: chave de API, login de assinatura ou modelo local, configurado com Hermes, não com este plugin. O plugin não fornece contas nem copia credenciais. O uso do modelo observador do Claude é separado do uso do provedor do worker do Hermes.

Arquivar cartões normalmente

Crie um board nomeado primeiro com hermes kanban boards create demo, depois use hermes kanban --board demo create "Construir a funcionalidade" --assignee construtor. Use hermes kanban swarm --help para escolher sinalizadores de swarm upstream. O arquivamento não inicia um despachante. Inicie/commissione workers através do Hermes separadamente. O hook pós-Bash sugere /kanban-watch após create/swarm; ele nunca inicia ou despacha nada por si só. Pule observações duplicadas na mesma onda.

Arquivar um cartão roteado e fixado

Somente em uma solicitação de arquivamento explícita: python3 <raiz-do-plugin>/scripts/file_card.py --board demo --class app-code --title "Construir a funcionalidade" --body-file /caminho/para/resumo.txt --routes /caminho/para/rotas.yaml --worktree /caminho/absoluto/para/worktree. --routes e --worktree são opcionais. O comando resolve um verificador de worker/família diferente via route.py, cria um worker fixado, executa set-model, verifica show --json, depois imprime seu id e os argumentos exatos de /kanban-watch. Ele não cria verificador, despachante, Workflow ou worktree e não abre configurações de perfil ou credenciais. Nunca conceda este comando de criação a um observador. --dry-run valida arquivos/rotas/board e imprime comandos sem executar o Hermes; o resumo é impresso, então mantenha segredos fora. Boards ausentes/rotas inválidas são recusadas. Após falha parcial, inspecione o id retornado, nunca re-arquive cegamente. Veja detalhes completos de arquivamento; inicie uma observação somente se solicitado.

Sugerir rotas após verificações PONG

Execute python3 <raiz-do-plugin>/scripts/doctor.py --board demo --routes /caminho/para/rotas.yaml --probe --suggest-routes /caminho/para/rotas-verificadas.yaml somente com aprovação explícita de capacidade. Requer --probe, recusa destinos existentes (incluindo diretórios/links simbólicos) e nunca altera as rotas de origem ou ativa a proposta. Revise as alterações de perfil/provedor/custo antes de selecioná-la. Ambas as faixas devem passar pelo PONG desta execução e ter famílias declaradas diferentes, não apenas hosts diferentes. Workers/verificadores aprovados são mantidos; substituições usam ordem lexicográfica das faixas. Classes sem um par são omitidas com comentários de diagnóstico; nenhum par significa rotas inutilizáveis. Falhas originais ainda saem com código 1. PONG não é adequação ou capacidade duradoura. Veja detalhes de seleção e auditoria.

Iniciar

Trate $ARGUMENTS como um objeto JSON de argumentos. Resolva o workflows/kanban-watch.js do plugin instalado, depois invoque Workflow({scriptPath: "<raiz-do-plugin>/workflows/kanban-watch.js", args: <args>}). Se Workflow não estiver disponível, relate essa limitação e execute comandos somente leitura do hermes-kanban-live diretamente, nunca finja que linhas de fluxo de trabalho ao vivo foram criadas.

Exemplos de args:

  • {"board":"default","tasks":["t_1234abcd"]}
  • {"board":"demo","phases":[{"title":"Construir","tasks":["t_1234abcd"]},{"title":"Verificar","tasks":["t_11111111"]}]}
  • {"board":"demo","follow_new":false,"stale_days":7,"max_hours":12}

Uma observação de board simples inclui cartões na fila/em execução, pulando cartões na fila ociosos por mais de stale_days (7 por padrão). stale_days: 0 desativa a filtragem; ids explícitos sempre permanecem. Use verbose: true para texto legado de worker e resultados de ferramentas. O leitor é hermes-kanban-live no PATH; live_cmd pode substituí-lo por um comando seguro, como python3 ~/plugins/hermes-kanban-watch/plugin/scripts/kanban_live.py. Apenas letras, números, espaços, /, ., _, -, ~ são aceitos. Sem operadores de shell. Cada linha usa o agente hermes-kanban-watch:kanban-watcher do plugin por padrão; nenhum agente de usuário privado é necessário. agent_type pode nomear outro agente disponível, usando letras ASCII, dígitos, -, _ e um : opcional entre nomes não vazios.

Ler o resultado

CONCLUÍDO é um resultado de cartão observado, não integração ou aceitação do usuário. Verifique o modelo real, fallback, avisos, resumo e entregável. BLOQUEADO/REVISÃO obtém linhas "Precisa de você" e pode ser reativado na retomada. NÃO_INICIANDO significa pronto, mas nenhum despachante o iniciou. DESCONHECIDO significa que uma leitura falhou, não que um cartão desapareceu. Timeouts repetem apenas na saída 3; uma ativação de 270 segundos mantém as esperas abaixo do TTL do cache de prompt. O observador nunca age no texto do worker, altera um cartão, repara nada ou ignora permissões.

Quando as mensagens do worker não estão disponíveis, siga relatórios que uma vez por execução/observador e usa o log do cartão; um batimento cardíaco nunca conta. Um log crescente/alterado evita um aviso de possível travamento. Apenas duas chamadas consecutivas da mesma execução sem movimento no log podem ser sinalizadas; primeiras observações, mudanças de execução e sinais ilegíveis não contam. Com mensagens, duas chamadas silenciosas sinalizam.

Use python3 <raiz-do-plugin>/scripts/route.py --class app-code para inspecionar a tabela de roteamento opcional. Ela retorna o JSON do worker e do verificador de família diferente; nunca arquiva ou despacha um cartão. Edite as rotas do usuário para nomear seus próprios perfis e famílias de modelos.

Convenção de pergunta humana

Para hermes-kanban-live needs, inicie uma linha de comentário com ASK OPERATOR: seguida pela pergunta. Uma menção em prosa como "ainda nenhum ASK OPERATOR" não é uma pergunta. Motivos de bloqueio ou espera de dependência devem dizer waiting on operator, waiting for operator ou needs operator para corresponder a uma espera humana atual. Estas são convenções de texto explícitas, não detecção de intenção em linguagem natural. Linhas de fluxo de trabalho "Precisa de você" sinalizam separadamente resultados bloqueados/em revisão e cartões que estão prontos, mas não iniciando.

Relatar execuções reais e tempo decorrido de uma onda

Execute hermes-kanban-live report --board demo, opcionalmente repetindo --task T ou adicionando --since EPOCH. Sem ids de tarefa, isso inclui todos os status, incluindo concluído/arquivado. --since seleciona o tempo de criação do cartão; ele cruza a seleção de tarefas e não recorta execuções individuais. JSON tem um objeto por cartão em cards, mais totals, read_status, now e missing. Cada cartão contém id/título/status, responsável, model_used real da última execução, provider_used, fallback_from, runs, retried, duration_s e contagens de avisos da última execução. Dados de execução desconhecidos permanecem nulos.

totals.by_status conta cartões; run_seconds soma todas as durações de execução conhecidas de cartões selecionados (execuções em andamento medidas em now); fell_back conta cartões que recuaram em qualquer tentativa; retried conta cartões com a proteção conservadora de repetição (várias execuções ou um evento de repetição/histórico de bloqueio). Estes são segundos decorridos, não custos de token/moeda faturados. Adicione --format text para colunas de texto simples alinhadas e totais, sem Markdown. Saída 4 relata ids explícitos ausentes; saída 5 é um board ilegível. Um cartão meramente excluído por --since não está ausente.

Verificar a independência real da família worker/verificador

Execute hermes-kanban-live verify-pair --board demo --worker T --verifier V, com --families FILE opcional. Ele usa a execução concluída mais recente de cada cartão (não nulo ended_at, id de execução mais novo), não um pino de modelo ou uma tentativa mais nova e inacabada. JSON inclui cada model_used real, provider_used, run_id, family mapeado e different_families. O provedor real da execução mapeia para sua família de modelos através de providers no arquivo de rotas. Mantenha hosts da mesma família mapeados de forma semelhante; hosts multi-família precisam de identificadores específicos da família. Isso não infere família de um prefixo de modelo ou prova que o trabalho de revisão aconteceu.

A ordem de consulta corresponde a route.py: --families explícito, KANBAN_WATCH_ROTES, ~/.config/hermes-kanban-watch/routes.yaml, template enviado. Apenas o mapa providers válido e não vazio é necessário. Saída 0 significa famílias diferentes, 1 significa a mesma família ou classificação inválida/desconhecida, 3 significa nenhuma execução concluída para qualquer id, e 5 significa board ilegível. Erros de classificação definem different_families como nulo e incluem error; nunca converta DESCONHECIDO em uma verificação bem-sucedida. Para chamadas diretas do Claude Code, solicite apenas Bash(hermes-kanban-live report:*) e Bash(hermes-kanban-live verify-pair:*), não permissão Bash irrestrita.

Manter uma observação de pergunta pai ativa através de timeouts

Execute hermes-kanban-live needs --board demo --loop --created-by PARENT --cursor-key WAVE uma vez, em vez de reconstruir um comando após cada saída 3. No modo loop, --since é opcional, capturado uma vez na inicialização quando ausente, e nunca avança através de janelas de timeout. Sua primeira varredura inclui esperas pré-existentes ainda em vigor, incluindo uma pergunta pai mais antiga de um criador. Esperas antigas respondidas/retomadas/substituídas permanecem excluídas e a desduplicação existente de cursor visto ainda se aplica.

O modo loop dorme em --interval e repete apenas timeouts normais, sem agitação JSON de timeout. Ele sai com 0 no primeiro resultado de itens não vazio, ou falha em um erro sem repeti-lo. --max-seconds limita cada janela, não o tempo de vida do comando; cancele o chamador para parar uma observação silenciosa. Sem --loop, o --since obrigatório, o timeout de saída 3 e o comportamento de saída são inalterados. Isso ainda é um leitor, nunca permissão para responder, despachar ou mutar um cartão.

Guias de funcionalidades

Habilidades Relacionadas