arch3rPro/digestpilot

Release Watch

Übersicht

Verwenden Sie diese Fähigkeit, wenn der Benutzer fragt, ob überwachte Software, Frameworks, Tools oder Repositorys neue Versionen haben und ob sich ein Upgrade lohnt.

Halten Sie diesen Workflow von der öffentlichen Trendermittlung getrennt. GitHub-Releases sind Signale zur Upgrade-Überwachung, keine Trend-Radar-Eingaben.

Workflow-Auswahl

• Verwenden Sie diese Fähigkeit für Versionsupdates überwachter Software.
• Verwenden Sie public-trend-radar für öffentliche Ökosystem-Trendkarten.
• Verwenden Sie rss-ai-digest für normale abonnierte RSS-Tagesnachrichten.
• Verwenden Sie rss-source-curator für Quellenqualität und Registry-Pflege.
• Verwenden Sie subscription-research-agent für tiefgehende Forschungssynthese aus Belegen.

Laufzeitbefehl

Beispiele verwenden subscription-research als Kompatibilitätsbefehl. Lösen Sie den Laufzeitbefehl vor der Ausführung von Befehlen auf:

• Wenn DIGESTPILOT_BACKEND_URL verfügbar ist, können Produktaktionen wie Release-Watch-Aktualisierung oder WebUI-gestützte Upgrade-Überwachung zuerst die Backend-Task-API verwenden und dann die resultierende Workspace-Ausgabe lesen.
• Wenn die Backend-API nicht verfügbar ist, verwenden Sie weiterhin den unten stehenden lokalen Laufzeitbefehl als Fallback. Erfordern Sie in generischen Agent-Umgebungen keine WebUI, Cloud oder einen gehosteten Dienst.
• Verwenden Sie DIGESTPILOT_RUNTIME_CMD, wenn die Umgebung einen benutzerdefinierten Laufzeitbefehl bereitstellt.
• Verwenden Sie digestpilot-runtime, wenn es auf dem PATH verfügbar ist.
• Verwenden Sie subscription-research, wenn nur der Legacy-Kompatibilitätsbefehl auf dem PATH verfügbar ist.
• Ersetzen Sie subscription-research durch node packages/research-cli/dist/src/cli.js bei einem Repository-Checkout ohne verknüpften Befehl.
• Führen Sie node scripts/doctor.mjs vom Repository-Stammverzeichnis aus, um die lokale Laufzeiteinrichtung zu diagnostizieren.
• Wenn kein Laufzeitbefehl verfügbar ist, dieses Repository oder Plugin-Paket jedoch Laufzeitquellen enthält, führen Sie node scripts/bootstrap-runtime.mjs aus und wiederholen Sie den Befehl.

Kernbefehl

Bereiten Sie eine Watchlist vor:

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

Holen Sie Live-GitHub-Releases ab und rendern Sie Upgrade-Karten:

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

Standardmäßig ruft die Laufzeitumgebung aktuelle GitHub-Releases für jedes überwachte Repository ab. Setzen Sie GITHUB_TOKEN, wenn höhere GitHub-API-Limits benötigt werden, oder übergeben Sie --github-token-env NAME, um eine andere Token-Variable zu lesen.

Für Offline-Tests oder exportierte Daten übergeben Sie vorbereitetes GitHub-Release-JSON:

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

Vorbereitetes Release-JSON hat diese Form:

{
  "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": "Release notes..."
        }
      ]
    }
  ]
}

Ausgabe-Richtlinien

Die Release-Watch-Ausgabe sollte eine Upgrade-Warteschlange sein, keine Trendliste.

Verwenden Sie diese Prioritäten:

• upgrade-now: Sicherheitskorrekturen oder dringende Fehlerbehebungen, die überwachte Fähigkeiten betreffen.
• review: Bahnbrechende Änderungen, Hauptversionen oder Updates, die überwachte Fähigkeiten betreffen.
• watch: Vorabversionen oder unklare Auswirkungen.
• ignore: Nur Wartungs- oder Dokumentationsfreigaben.

Die Markdown-Ausgabe sollte sich auf umsetzbare Releases konzentrieren. JSON behält alle Karten, einschließlich ignorierter Releases, für die Automatisierung bei.

Wenn current_version in der Watchlist vorhanden ist, fügt Release Watch version_delta, upgrade_action und den Kontext der aktuellen Version hinzu. Nutzen Sie dies, um Patch-Upgrades von Minor-Upgrades und großen Migrationsüberprüfungen zu unterscheiden.

Grenzen

Nehmen Sie keine Änderungen an Benutzerabhängigkeiten vor, erstellen Sie keine Upgrade-PRs und veröffentlichen Sie keine Benachrichtigungen automatisch. Erstellen Sie überprüfbare Upgrade-Karten und lassen Sie den Benutzer über die nächste Aktion entscheiden.