arch3rPro/digestpilot

Release Watch

Aperçu

Utilisez ce skill lorsque l'utilisateur demande si des logiciels, frameworks, outils ou dépôts surveillés ont de nouvelles versions et si ces versions valent la peine d'être mises à jour.

Gardez ce workflow séparé de la découverte de tendances publiques. Les versions GitHub sont des signaux de surveillance des mises à jour, pas des entrées pour le Trend Radar.

Sélection du Workflow

• Pour les mises à jour de versions de logiciels surveillés, utilisez ce skill.
• Pour les fiches de tendances de l'écosystème public, utilisez public-trend-radar.
• Pour les actualités RSS quotidiennes ordinaires, utilisez rss-ai-digest.
• Pour la maintenance de la qualité des sources et des registres, utilisez rss-source-curator.
• Pour la synthèse de recherche approfondie à partir de preuves, utilisez subscription-research-agent.

Commande d'Exécution

Les exemples utilisent subscription-research comme commande de compatibilité. Avant d'exécuter des commandes, résolvez la commande d'exécution :

• Lorsque DIGESTPILOT_BACKEND_URL est disponible, les actions du produit telles que l'actualisation de la liste de surveillance ou la surveillance des mises à jour via l'interface WebUI peuvent utiliser l'API Backend en premier, puis lire la sortie de l'espace de travail résultante.
• Si l'API Backend est indisponible, continuez à utiliser la solution de repli de la commande d'exécution locale ci-dessous. N'exigez pas WebUI, cloud ou un service hébergé dans des environnements d'agent génériques.
• Utilisez DIGESTPILOT_RUNTIME_CMD lorsque l'environnement fournit une commande d'exécution personnalisée.
• Utilisez digestpilot-runtime lorsqu'elle est disponible sur PATH.
• Utilisez subscription-research lorsque seule la commande de compatibilité héritée est disponible sur PATH.
• À partir d'un checkout du dépôt sans commande liée, remplacez subscription-research par node packages/research-cli/dist/src/cli.js.
• Exécutez node scripts/doctor.mjs depuis la racine du dépôt pour diagnostiquer la configuration locale de l'exécution.
• Si aucune commande d'exécution n'est disponible mais que ce dépôt ou le paquet du plugin inclut le code source de l'exécution, exécutez node scripts/bootstrap-runtime.mjs, puis réessayez la commande.

Commande Principale

Préparez une liste de surveillance :

{
  "repos": [
    {
      "id": "vercel/ai",
      "importance": "high",
      "current_version": "v5.1.0",
      "used_capabilities": ["streaming", "tool-calling"]
    }
  ]
}

Récupérez les versions GitHub en direct et générez des fiches de mise à jour :

subscription-research release watch \
  --watchlist release-watchlist.json \
  --state release-seen.json \
  --mark-seen \
  --format markdown \
  --output release-watch.md

Par défaut, l'exécution récupère les versions GitHub récentes pour chaque dépôt surveillé. Définissez GITHUB_TOKEN lorsque des limites d'API GitHub plus élevées sont nécessaires, ou passez --github-token-env NOM pour lire une variable de jeton différente.

Pour les tests hors ligne ou les données exportées, passez un fichier JSON de versions GitHub préparé :

subscription-research release watch \
  --watchlist release-watchlist.json \
  --github-releases github-releases.json \
  --state release-seen.json \
  --format markdown

Le fichier JSON de versions préparé utilise cette forme :

{
  "repositories": [
    {
      "repo": "vercel/ai",
      "releases": [
        {
          "tag_name": "v5.1.1",
          "name": "v5.1.1",
          "html_url": "https://github.com/vercel/ai/releases/tag/v5.1.1",
          "published_at": "2026-06-12T00:00:00Z",
          "body": "Notes de version..."
        }
      ]
    }
  ]
}

Guide de Sortie

La sortie de Release Watch doit être une file d'attente de mise à jour, pas une liste de tendances.

Utilisez ces priorités :

• upgrade-now : correctifs de sécurité ou correctifs urgents qui affectent les capacités surveillées.
• review : changements cassants, mises à jour majeures, ou mises à jour touchant les capacités surveillées.
• watch : préversions ou impact incertain.
• ignore : versions de maintenance ou de documentation uniquement.

La sortie Markdown doit se concentrer sur les versions exploitables. Le JSON préserve toutes les fiches, y compris les versions ignorées, pour l'automatisation.

Lorsque current_version est présent dans la liste de surveillance, Release Watch ajoute version_delta, upgrade_action et le contexte de la version actuelle. Utilisez cela pour distinguer les mises à jour de correctifs (patch) des mises à jour mineures et des révisions de migration majeures.

Limites

Ne modifiez pas les dépendances de l'utilisateur, ne créez pas de PRs de mise à jour et ne publiez pas de notifications automatiquement. Produisez des fiches de mise à jour révisables et laissez l'utilisateur décider de l'action suivante.