evgyur/hermes-bird-xurl-skill

Bird

Bird ist der zentrale X/Twitter-Router. Verwenden Sie SocialData als standardmäßige, kostengünstige Leseebene. Verwenden Sie die offizielle xurl CLI nur dann, wenn die Aufgabe einen authentifizierten Kontokontext, ein X-natives Objekt oder eine explizit genehmigte Kontoänderung erfordert. Lassen Sie nicht beide Anbieter dieselbe Routine-Leseanfrage beantworten.

Auslöser und Kompatibilität

Verwenden Sie für X/Twitter-URLs, Tweet/Thread/Artikel-Extraktion, Suche, Profile, Antworten/Zitate/Kontext, Medienabruf und X-Kontoaktionen.

Behalten Sie diese Einstiegspunkte bei:

• /bird <anfrage> — kanonischer Router.
• Legacy bird.py <URL-oder-ID> — liest weiterhin über SocialData.
• /xurl ... — Kompatibilitäts-Einstiegspunkt für Benutzer, die explizit xurl anfordern; er muss Birds Routing- und Schreibsperren befolgen.

Deterministisches Routing

Absicht	Primär	Fallback	Grenze
Tweet per URL/ID lesen	SocialData	Web/Browser nur für öffentlich sichtbare Beweise	Niemals auf xurl hochstufen, nur weil es existiert
Thread/Konversation/Antworten lesen	SocialData	xurl lesen nur, wenn X-nativer Kontext eindeutig erforderlich und unterstützt wird	Thread aus abgerufenen Daten bestimmen, nicht aus URL-Form
Beiträge suchen	SocialData begrenzte Suche	bestehende SocialData/Web-Recherche-Route	Aktueller xurl recent-search Zugriff wird nicht angenommen
Öffentliches Profil lesen	SocialData	xurl Benutzersuche, wenn kontospezifische/aktuelle X-Ansicht erforderlich ist	Keine Massen-Graph-Erfassung
X-Artikel	SocialData Tweet-Payload zuerst; verschachtelten Artikel parsen	xurl roher Tweet-Endpunkt mit article-Feld	Folgen Sie der verlinkten First-Party-Seite, wenn Artikeltext fehlt
Angehängte Medien herunterladen	SocialData Metadaten + begrenzter HTTPS-Download	Browser nur für sichtbare öffentliche Medien	Keine Cookies in URLs/Logs; Host/Größe/Typ validieren
Wer bin ich / authentifizierte Identität	xurl	keine	Schreibgeschützter Kontokontext
Exaktes X-natives Objekt für spätere Interaktion benötigt	xurl	SocialData für Entdeckung/Kontext	Verwenden Sie xurl nur für das exakte Objekt/den Endpunkt
Posten, Antworten, Zitieren, Löschen, Liken, Reposten, Lesezeichen, Folgen, Blockieren, Stummschalten, DM, Hochladen	xurl	keine	Explizite Genehmigung des exakten Ziels, Inhalts und Effekts erforderlich

Laden Sie Anbieter-Routing für Endpunkt-Rezepte, Fehler und Fallback-Regeln. Laden Sie xurl-Operationen nur für eine xurl-spezifische Aufgabe.

Anbieter- und Kostenvertrag

• SocialData ist der Standard für jede gewöhnliche Leseanfrage. Verwenden Sie zuerst den konfigurierten direkten SOCIALDATA_API_KEY in der aktuellen Laufzeit. Verwenden Sie den genehmigten Human20 Keys SocialData-Proxy, wenn ein direkter Schlüssel fehlt und der H20-Kundenschlüssel die socialdata-Fähigkeit besitzt. Ein generischer H20-Modellschlüssel könnte existieren, aber provider not allowed: socialdata zurückgeben; das rechtfertigt nicht den Wechsel zu xurl.
• Die aktuelle Human20 Keys Standard-Preisklasse für social-request wurde mit 0 credits/request verifiziert; behandeln Sie dies als veränderlichen Laufzeitzustand und überprüfen Sie es erneut, bevor Sie Kosten geltend machen.
• Eine Benutzeranfrage sollte normalerweise eine Suche/Nachschlage + nur die begrenzten abhängigen Lesevorgänge verbrauchen, die für einen Thread oder den angeforderten Kontext benötigt werden. Fächern Sie nicht auf, scrapen Sie keine Follower/Following, exportieren, streamen, pollieren oder bulk-fetchen Sie nicht.
• Fallen Sie niemals stillschweigend von SocialData auf bezahlte X-API-Aufrufe zurück. xurl wird aufgrund des Fähigkeitsbedarfs ausgewählt, nicht aufgrund eines Anbieterfehlers.

Geheimnisse und Ausführungssicherheit

• Lesen, drucken, parsen, zusammenfassen oder legen Sie niemals geheime Speicher, ~/.xurl, Cookies, Autorisierungs-Header, API-Schlüssel, Bearer-Token, Anforderungssignaturen oder Umgebungsvariablen offen.
• Überprüfen Sie Anmeldedaten nur durch sichere Status-/Probe-Befehle. Verwenden Sie keine xurl --verbose/-v oder Inline-Anmelde-Flags.
• SocialData-Aufrufe sind schreibgeschützt und begrenzt. Behandeln Sie 401/403 als Anmelde-/Richtlinienfehler, 402 als Guthaben-/Abrechnungsproblem, 404 als abwesend/privat/gelöscht, 429 als Ratenlimit und 5xx als Anbieterfehler. Kennzeichnen Sie eine Klasse nicht fälschlich als eine andere.
• Browser/Relay ist das letzte Mittel und niemals ein Mechanismus zur Cookie-Extraktion.
• Schreibvorgänge sind geschützte Effekte. Vor jeder xurl-Mutation lesen Sie das genaue Ziel und die Payload erneut, fordern Sie eine explizite Benutzergenehmigung für diesen genauen Effekt an, führen Sie ihn einmal aus und verifizieren Sie ihn aus der rohen xurl/X-Antwort. Genehmigung zur Recherche ist keine Genehmigung zur Interaktion oder Veröffentlichung.
• DMs, Löschungen, Blockierungen, Kontoänderungen, Medien-Uploads und öffentliches Posten geschehen niemals implizit.

Arbeitsablauf

1. Klassifizieren Sie die Anfrage: read, search, profile, thread, article, media, account-read oder write.
2. Normalisieren Sie die X-URL/ID, ohne den Bezeichner zu ändern. Rufen Sie ab, bevor Sie über Tweet vs. Thread entscheiden.
3. Routen Sie gemäß der Tabelle. Rufen Sie für Routine-Lesevorgänge zuerst genau einmal SocialData auf.
4. Parsen Sie defensiv. Artikel-Payloads können sich unter article.title, article.preview_text und article.content_state.blocks[] befinden; Medien können in zitierten oder retweeteten Objekten verschachtelt sein.
5. Wenn der Benutzer fragt, ob das Element relevant ist, öffnen Sie verlinkte First-Party-Repositories/Dokumente/Artikel und inspizieren Sie angehängte Medien. Behalten Sie den X-Beitrag als Behauptung/Quelle, nicht als automatischen Beweis.
6. Wenn der ausgewählte Anbieter fehlschlägt, melden Sie den genauen Fehler. Verwenden Sie nur den angegebenen Fallback, wenn er dieselbe Anfrage beantworten kann, ohne Kosten, Privatsphäre oder Effekte zu erweitern.
7. Geben Sie quelltreue Ausgabe und einen kompakten Anbieterbeleg zurück.

Ausgabe-Vertrag

Geben Sie zurück:

Result: <vollständiger angeforderter Inhalt oder präzise, treue Antwort>
Type: tweet | thread | artikel | profil | suche | konto-aktion
Author/source: <sichere öffentliche Identität + kanonische URL>
Provider: SocialData | xurl | web/browser fallback
Evidence: <IDs, Zeitstempel, Metriken/Kontext, falls verfügbar>
Action receipt: <nur für genehmigte xurl-Mutationen; genauer Status/Objekt-ID>
Limitation: <fehlend/privat/gelöscht/rate/plan/anbieter-lücke, oder keine>

Legen Sie keine internen Schlüssel, Authentifizierungsmodi, geheimen Speicherorte oder private Laufzeitdetails in benutzerseitigen Belegen offen.

Schnelltest-Checkliste

• /bird <tweet URL> wählt SocialData, nicht xurl.
• /bird search from:handle wählt begrenzte SocialData-Suche.
• /bird whoami wählt schreibgeschützte xurl-Identität.
• /bird reply <URL> <text> stoppt für genaue Genehmigung vor xurl.
• SocialData 402 wird nicht als fehlende Anmeldedaten gemeldet; xurl recent-search Fehler deaktiviert keine Identitäts-/Profil-Lesevorgänge.
• Thread- und Artikel-Parsing verwenden abgerufene Struktur, keine URL-Erraten.
• Das Entfernen des SocialData-Standard- oder Schreibgenehmigungs-Vertrags führt zum Scheitern der Validierung.

Erledigt-Kriterien

• Der angeforderte X-Inhalt/die angeforderte Aktion ist vollständig oder ein exakter Blocker wird gemeldet.
• Routine-Lesevorgänge verwendeten zuerst SocialData und vermieden doppelte Anbieterausgaben.
• xurl wurde nur aus einem fähigkeitsspezifischen Grund verwendet.
• Jeder Schreibvorgang hatte eine genaue Genehmigung und eine Roh-API-Rücklesebestätigung.
• Kein Geheimnis/Cookie/private Anmeldeinformation gelangte in die Ausgabe, Artefakte oder Logs.