CtrlK
BlogDocsLog inGet started
Tessl Logo

spec-driven-development/agent-registry

Coordina multipli agenti AI CLI (Kimi, Claude, Gemini, OpenAI, ecc.) che lavorano contemporaneamente sullo stesso progetto e mantiene una memoria collettiva (wiki) di tutte le sessioni passate. Usa questa skill SEMPRE quando lavori in parallelo con altre AI CLI, quando devi salvare lo stato di una sessione condivisa, quando vuoi evitare sovrascritture su file toccati da altri agenti, quando devi chiedere "questo lavoro è già stato fatto? questo bug si è già visto?", o quando l'utente parla di "multi-tap", "registry agenti", "coordination", "lock file", "handoff condiviso", "wiki delle sessioni", "chi sta lavorando su cosa" o "evitare che le AI si pestino i piedi".

72

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

spec.mdopenspec/changes/2026-07-22-dockerize-sandbox/specs/whatsapp-notifications/

targets:
notifier/watchdog.py, notifier/wa_client.py

whatsapp-notifications Specification

Purpose

Notificare l'operatore via WhatsApp quando lo stato degli agenti nel registry cambia in modi rilevanti: un agente ha completato il lavoro, un agente si è fermato, o un agente è rimasto inattivo troppo a lungo. I messaggi provengono da un pool configurabile e sono scelti a caso per varietà. L'integrazione WhatsApp avviene tramite un gateway HTTP esterno (open-wa) e non richiede modifiche agli script del registry: il watchdog osserva soltanto lo stato in AGENT_REGISTRY_HOME.

Requirements

Requirement: Rilevamento dei tre eventi di notifica

Il watchdog SHALL classificare le sessioni in tre eventi — executed (una sessione passa a Finished), stopped (una sessione passa a Stop o Killed), idle (una sessione OnWorking senza attività da oltre una soglia configurabile, default 3600s) — usando lo stato precedente per emettere ogni evento una sola volta per transizione.

Verified by: [@test] tests/notifier/test_watchdog.py

Scenario: completamento rilevato una sola volta

  • WHEN una sessione passa da OnWorking a Finished fra due cicli
  • THEN viene emesso un evento executed per quella sessione
  • AND al ciclo successivo, se lo stato resta Finished, non viene emesso di nuovo

Scenario: arresto rilevato

  • WHEN una sessione passa a Stop o Killed
  • THEN viene emesso un evento stopped per quella sessione una sola volta

Scenario: inattività oltre la soglia

  • WHEN una sessione è OnWorking e la sua ultima attività è più vecchia della soglia idle
  • THEN viene emesso un evento idle una sola volta
  • AND finché resta idle senza tornare attiva non vengono emessi ulteriori eventi idle

Requirement: Avvio a freddo senza notifiche storiche

Al primo ciclo su un registry già popolato (nessuno stato precedente persistito), il watchdog SHALL registrare lo stato corrente senza emettere alcun evento; solo i cambiamenti nei cicli successivi SHALL generare notifiche.

Verified by: [@test] tests/notifier/test_watchdog.py

Scenario: nessun flood all'avvio

  • WHEN il watchdog classifica per la prima volta (cold start) sessioni già Finished o idle
  • THEN non emette alcun evento
  • AND al ciclo successivo un cambiamento nuovo genera regolarmente il suo evento

Requirement: Messaggi da pool con placeholder

Il watchdog SHALL scegliere a caso un messaggio dal pool dell'evento e sostituire i placeholder disponibili ({name}, {session_id}, {provider}, {working_on}, e {minutes} per gli eventi idle). SHALL preferire un pool locale (notifier/messages.local.json) se presente, altrimenti il pool di default committato.

Verified by: [@test] tests/notifier/test_watchdog.py

Scenario: rendering di un messaggio idle

  • WHEN si renderizza un evento idle con nome e minuti noti
  • THEN il testo risultante contiene il nome e i minuti al posto dei placeholder
  • AND non restano placeholder non sostituiti fra quelli disponibili

Requirement: Invio via gateway esterno senza segreti hardcoded

L'invio SHALL avvenire con una POST HTTP al gateway open-wa (endpoint send-text), con URL, API key e destinatario forniti da configurazione/ambiente. Il codice NON SHALL contenere il numero destinatario né la API key in chiaro.

Verified by: [@test] tests/notifier/test_watchdog.py

Scenario: la richiesta di invio è costruita da configurazione

  • WHEN si prepara l'invio di un messaggio a un destinatario configurato
  • THEN la POST punta all'endpoint send-text del gateway con il testo e il destinatario dati
  • AND destinatario e API key provengono da parametri/ambiente, non da costanti nel codice

openspec

changes

2026-07-22-dockerize-sandbox

specs

whatsapp-notifications

design.md

proposal.md

tasks.md

README.md

requirements-dev.txt

SKILL.md

SPEC_SETUP.md

tile.json