Deskbird-Automator

Steuert Deskbird ueber Telegram mit sicherem Auth-Handling, Discovery und Parkplatz-Status/Reservierung. Verwende diesen Skill, wenn ein OpenClaw-Agent Deskb...

Security Scan

The skill's code and instructions broadly match a Deskbird automation helper, but there are notable mismatches and sensitive-data handling steps (DevTools header paste → import into a local .env) that are not fully declared or constrained — review before use.

Purpose & Capability

The skill is presented as a Deskbird automation helper (Cron + Telegram notifications) and includes a local CLI and a large Python helper that replays browser requests. That capability is coherent with the stated purpose. However, the registry metadata declares no required environment variables or credentials while SKILL.md and the scripts expect/encourage several DESKBIRD_* env variables (DESKBIRD_FIREBASE_API_KEY, DESKBIRD_FIREBASE_REFRESH_TOKEN, DESKBIRD_AUTHORIZATION, DESKBIRD_COOKIE, etc.). The description mentions Telegram-based control/notifications but no Telegram credentials or delivery mechanism are declared, creating an incomplete mapping between claimed functionality and declared requirements.

Instruction Scope

SKILL.md explicitly instructs the agent/operator to collect full request headers from the browser DevTools (Authorization, Cookie, X-CSRF-Token, etc.) and paste them into Telegram so the tool can import them via auth-import. The tool then persists these values into a local .env. Collecting and importing full session headers is required for the task but is high-risk and the instructions give broad latitude (e.g., 'paste header block or token') without stricter constraints. The runtime instructions also allow fallback to 'auth-capture' and instruct frequent file reads/writes (.env) and replaying of HTTP requests — all of which are within the skill's purpose but involve sensitive credential handling that is not tightly scoped.

Install Mechanism

There is no install spec (instruction-only), which minimizes automated install risk. The repository includes Python scripts that require installing dependencies (requests, playwright, python-dotenv) and running 'python -m playwright install chromium' per SKILL.md. Requiring Playwright is plausible for an auth-capture flow but increases the local footprint and complexity. No third-party binary downloads from untrusted URLs are present in the manifest.

Credentials

The skill manifest declares no required env vars, yet the code and documentation expect many DESKBIRD_* variables and offer persistent storage of DESKBIRD_FIREBASE_API_KEY and DESKBIRD_FIREBASE_REFRESH_TOKEN in the skill .env. The SKILL.md recommends pasting highly sensitive headers into Telegram which are then imported and stored locally. The number and sensitivity of env variables used (authorization tokens, cookies, refresh tokens) are high relative to what the registry metadata declares, and there is no explicit declaration of where Telegram credentials live or who receives the pasted tokens, making the credential model unclear.

Persistence & Privilege

The tool intentionally writes and updates a skill-scoped .env file and uses dotenv.set_key to persist auth values — this is expected for long-lived refresh tokens. always is false, and the skill does not appear to modify other skills or global agent configuration. However, persistent storage of session cookies/headers on disk is a material privilege (sensitive data at rest) that users should be aware of.

What to consider before installing

This skill appears to be a legitimate Deskbird automation helper, but it asks you to paste full browser request headers (Authorization, Cookie, CSRF tokens) into chat so the tool can import them and save them to a local .env. Before installing or running: 1) Understand that pasting these headers gives the tool full access to your Deskbird session — only do this from a private, trusted chat and preferably only with short-lived tokens. 2) The registry metadata does not declare the DESKBIRD_* env vars the tool uses; expect to manage a .env in the skill folder with sensitive values. 3) If you need Telegram notifications, ask the author how Telegram credentials are provided and where messages are sent; the skill does not declare Telegram credentials. 4) Consider running the skill in an isolated environment (throwaway repo, container, or VM) and inspect the full scripts (deskbird_tool.py) before importing any tokens. 5) Prefer the Firebase refresh-token flow over pasting long-lived session cookies, and avoid pasting tokens in public or group chats. If you want higher assurance, request from the publisher: (a) an explicit list of required env vars, (b) a description of any outbound network endpoints beyond api.deskbird.com, and (c) confirmation that the skill never transmits captured tokens to third-party hosts.

Verwende diesen Skill, um Deskbird ueber das lokale CLI (scripts/deskbird_tool.py) sicher zu bedienen und optional als wiederkehrende Cron-Session laufen zu lassen.

Voraussetzungen

• Arbeite im Projektordner <repo-root>.
• Nutze bevorzugt diese CLI-Kommandos:
  • ./scripts/deskbird.sh auth-check
  • ./scripts/deskbird.sh auth-refresh --format json
  • ./scripts/deskbird.sh auth-import --stdin --format json
  • ./scripts/deskbird.sh discovery
  • ./scripts/deskbird.sh parking-status
  • ./scripts/deskbird.sh parking-book-first
  • Setup bei frischem Upload:
    • python3 -m venv .venv
    • source .venv/bin/activate
    • pip install -r requirements.txt
    • python -m playwright install chromium
    • chmod +x scripts/deskbird.sh
• Halte den Schonmodus aktiv (DESKBIRD_SAFE_MODE=true) und sende keine Request-Stuerme.
• Fuer Telegram-Reauth standardmaessig nur DevTools-Paste + auth-import verwenden.
• auth-pair-* und auth-capture nicht als Standard im Chat vorschlagen.

Deterministischer Env-Pfad

• Verwende fuer alle Skill-Aufrufe den Wrapper ./scripts/deskbird.sh.
• Der Wrapper setzt automatisch --env-file <skill-root>/.env und verhindert damit CWD-bedingte Auth-Fehler.
• Nur bei gezieltem Debugging darfst du --env-file explizit auf eine andere Datei setzen.

Empfohlene Dauer-Auth (Broker-Basis)

• Hinterlege nach einmaliger Ermittlung in der Skill-.env:
  • DESKBIRD_FIREBASE_API_KEY
  • DESKBIRD_FIREBASE_REFRESH_TOKEN
• Dann kann der Agent automatisch per auth-refresh einen neuen Bearer holen, ohne jeden Login-Flow.

Pflichtdialog Vor Automatisierung

Wenn noch keine passende Cron-Session existiert, frage den Nutzer in genau dieser Reihenfolge:

1. Soll ich eine wiederkehrende Cron-Session dafuer anlegen?
2. Wenn ja: Welcher Rhythmus? Default ist taeglich um 00:30 Uhr (Europe/Berlin), ein Lauf fuer den naechsten 24h-Blick.
3. Was soll die Session pro Lauf genau tun?
   Falls unklar, biete als Defaults an:
   • Nur Uebersicht ueber alle buchbaren Objekte senden
   • Uebersicht + Parkplatz automatisch buchen, wenn Regel erfuellt ist
   • Nur monitoren, nie buchen
4. Fasse Name, Rhythmus und Session-Aufgabe zusammen und hole eine letzte Bestaetigung ein.

Wenn der Nutzer keinen Rhythmus nennt, setze den Default: taeglich 00:30 (Europe/Berlin).

Reauth-Protokoll (immer vor Deskbird-Calls)

Fuehre vor Discovery/Status/Buchung immer zuerst aus:

./scripts/deskbird.sh auth-check --format json --min-valid-minutes 90

Auswertung:

• Wenn requires_reauth=false: normal fortfahren.
• Wenn requires_reauth=true:
  • Wenn DESKBIRD_FIREBASE_API_KEY und DESKBIRD_FIREBASE_REFRESH_TOKEN vorhanden sind:
    • zuerst automatisch ./scripts/deskbird.sh auth-refresh --format json --min-valid-minutes 90 ausfuehren.
    • nur wenn das fehlschlaegt, Nutzer um manuelle Reauth bitten.
  • Ohne Firebase-Refresh-Creds: Nutzer aktiv fragen, ob Reauth jetzt gestartet werden soll.
• Manueller Reauth-Standard ist Token/Header-Paste aus Chrome DevTools.

Office-Discovery Pflicht

• Vor jeder Detailabfrage (parking-status, parking-check, parking-book-first) zuerst discovery ausfuehren.
• --office-id ist optional: Das CLI loest das Office automatisch ueber internalWorkspaces auf.
• Nur wenn mehrere Offices vorhanden und der Default unklar ist:
  • zuerst --office-name "<NAME_TEILSTRING>" verwenden, oder
  • DESKBIRD_DEFAULT_OFFICE_ID in der Skill-.env setzen.
• Der Agent soll den Nutzer nicht standardmaessig nach einer Office-ID fragen.

Reauth Via DevTools Paste

Wenn Reauth noetig ist, leite den Nutzer kurz an:

1. app.deskbird.com im Browser oeffnen und normal per SSO einloggen.
2. DevTools (Network) oeffnen.
3. Einen api.deskbird.com Request anklicken.
4. Request-Header (Authorization, optional Cookie, X-CSRF-Token, X-XSRF-Token) kopieren.
5. Header-Block in Telegram an den Bot senden.

Importiere den vom Nutzer gepasteten Block dann intern so:

cat <<'EOF' | ./scripts/deskbird.sh auth-import --stdin --format json
<PASTED_HEADER_BLOCK_OR_TOKEN>
EOF

Danach immer nochmals pruefen:

./scripts/deskbird.sh auth-check --format json --min-valid-minutes 90

Fallback:

• Nur wenn DevTools-Paste unmoeglich ist, manuelles auth-capture anbieten.

Wenn Auth danach weiterhin ungueltig ist:

• Keine Buchungen ausfuehren.
• Klar melden, dass ohne erfolgreiche Reauth abgebrochen wird.

Verhalten In Cron-Laeufen

Cron-Laeufe muessen fehlertolerant und vorsichtig sein:

• Nie aggressive Retries oder enge Polling-Schleifen starten.
• Wenn Auth im Cron-Lauf nicht mehr gueltig ist, nicht blind weiterprobieren.
• Stattdessen eine Telegram-Nachricht senden mit klarer Handlungsaufforderung zur Reauth und den Lauf sauber beenden.

Cron-Session Erstellen/Aktualisieren

Nutze OpenClaw-Cron-Funktionen. Wenn Tooling verfuegbar ist, bevorzuge cron.add/cron.update; alternativ CLI:

openclaw cron add --name "Deskbird Daily" --schedule "30 0 * * *" --prompt "<SESSION_PROMPT>" --announce

Regeln:

• Verwende lokale Zeit (Europe/Berlin) fuer den Standard.
• Lege pro Aufgabe genau eine Cron-Session an (keine Duplikate).
• Aktualisiere bestehende Sessions statt neue Kopien anzulegen.

Session-Prompt Bauen

Beim Erstellen des Cron-Prompts nutze die Vorlage aus references/cron-session-template.md und ersetze Platzhalter fuer Zone/Regeln.

Ausgabeformat Gegenueber Dem Nutzer

Bei jedem Lauf (manuell oder Cron) liefere kompakt:

1. Auth-Status (ok oder reauth_noetig)
2. Was geprueft wurde (Datum/Zonen/Objekttypen)
3. Wichtige Treffer (frei/belegt/gesperrt, wer belegt)
4. Ob eine Buchung durchgefuehrt wurde oder warum nicht