Jobsuche: Agent pro Benutzer in isoliertem Docker-Container
Jeder Suchlauf läuft nun in einem frischen Container pro Benutzer, dessen pro-Benutzer-Home als ~/.claude gemountet ist — Memories und Session-Contexte liegen damit strikt getrennt pro Benutzer. Die Such-Skills sind Shared-Code aus dem Image und werden im Container nur nach ~/.claude/skills verlinkt. Der Host-Runner startet pro Lauf `docker run --rm` und führt bis zu JOBSUCHE_MAX_PARALLEL (Default 4) Läufe parallel über verschiedene Benutzer aus (jeder hat eigenen Ollama-Key = getrennte Rate-Limits). Der alte gemeinsame ~/.claude-Pfad wird vom Runner nicht mehr beschrieben. - source/agent/: neues Agent-Image (Dockerfile + entrypoint + drei Skills) - scripts/jobsuche-runner.js: agentStarten als docker run, ensureAgentDir, runPool - scripts/jobsuche-runner.sh + bin/-Kopie: Image-Guard - package.json: docker:build-agent (lokal, ohne Registry-Push) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,548 @@
|
||||
---
|
||||
name: it-stellensuche-remote
|
||||
description: Search the web for NEW 100% remote / homeoffice IT / system administrator jobs anywhere in Germany (Deutschland-weit, ortsunabhängig) that the user has NOT applied to yet, then present them and optionally import them as JobOffers into the Bewerbungs-Tracker. Use whenever the user wants to find new fully-remote IT/sysadmin postings, "Remote-Stellensuche", "Homeoffice-Jobs suchen", "100% Remote finden", "ortsunabhängige Systemadministrator-Stellen", or refresh open remote job leads. Deduplicates against existing Bewerbungen and Jobangebote via the bewerbungs-tracker skill.
|
||||
---
|
||||
|
||||
# Stellensuche REMOTE (100 % Homeoffice, deutschlandweit)
|
||||
|
||||
Findet **neue** Stellen im Web, die **100 % remote / vollständig im Homeoffice** und
|
||||
**deutschlandweit ortsunabhängig** ausübbar sind, filtert alle raus, für die sich der
|
||||
Nutzer schon beworben hat **oder die auf der Blacklist stehen**, und spielt sie auf
|
||||
Wunsch als JobOffers in den Bewerbungs-Tracker ein.
|
||||
|
||||
> **Multi-User (WICHTIG):** Der Tracker hat mehrere Benutzer, jeder mit **eigenem
|
||||
> Suchprofil und eigenem API-Key**. Der Remote-Modus ist inzwischen Teil des
|
||||
> Suchprofils (`/jobsuche` → Modus „100 % Remote" bzw. „Regional + Remote"), und der
|
||||
> Jobsuche-Runner ruft dafür den Skill `it-stellensuche` mit einem entsprechenden
|
||||
> Prompt auf. Dieser Skill hier ist der **manuelle Einstieg** für eine reine
|
||||
> Remote-Suche.
|
||||
>
|
||||
> Rolle und Technologien **nicht raten**: Sie kommen aus dem Lebenslauf des Benutzers,
|
||||
> dem der `BEWERBUNG_API_KEY` gehört (`GET /templates`, typ `Lebenslauf`) — bzw. aus dem
|
||||
> Profil, das der Prompt mitliefert. Die Rollen-/Buzzword-Listen unten sind **Beispiele
|
||||
> für ein IT-Infrastruktur-Profil**, kein Default für jeden Benutzer.
|
||||
|
||||
> **Abgrenzung zum regionalen Skill:** Dieser Skill sucht **ausschließlich
|
||||
> ortsunabhängige 100-%-Remote-Stellen deutschlandweit** — **ohne** Bindung an die
|
||||
> sechs Städte. Der **Arbeitsort/Firmensitz spielt keine Rolle**, solange die
|
||||
> Tätigkeit vollständig aus dem Homeoffice irgendwo in Deutschland erbracht werden
|
||||
> kann. Regionale, ortsgebundene Stellen sind Sache des Skills `it-stellensuche`
|
||||
> (sechs Städte) und werden hier **nicht** behandelt.
|
||||
|
||||
> **Blacklist-Prinzip (zentral):** Jeder erfolgreich importierte Job wird
|
||||
> **unmittelbar danach geblacklistet**. So taucht dieselbe Stelle in späteren
|
||||
> Suchläufen nie wieder auf — die Dublett-Vermeidung bleibt bestehen, selbst wenn
|
||||
> das JobOffer später gelöscht oder in eine Bewerbung überführt wird. Umgekehrt
|
||||
> werden Kandidaten, die schon auf der Blacklist stehen, gar nicht erst gelistet
|
||||
> oder importiert. Die Blacklist/Dedup ist **gemeinsam** mit dem regionalen Skill —
|
||||
> derselbe Job wird also über beide Suchen hinweg nicht doppelt erfasst.
|
||||
|
||||
## Suchprofil (Default)
|
||||
|
||||
**Rolle:** breit fassen — dieselbe Tätigkeit läuft je nach Firma unter vielen Titeln.
|
||||
Alle folgenden Bezeichnungen als Query-Varianten und für die Relevanzbewertung nutzen
|
||||
(zutreffend, sobald der Schwerpunkt auf IT-Infrastruktur/Systembetrieb liegt):
|
||||
|
||||
- **Kern (deckt sich mit dem CV: 2nd-Level-Sysadmin + IT-Consultant):**
|
||||
Systemadministrator, IT-Administrator, IT-Systemadministrator, IT-Systemadministration,
|
||||
IT-Systemadministrator 2nd Level, 2nd-Level-Administrator, System-Administrator (m/w/d),
|
||||
Fachinformatiker Systemintegration, Administrator (m/w/d).
|
||||
- **Support/Betrieb:** 1st/2nd/3rd-Level-Support, 2nd-Level-Support, IT-Support,
|
||||
IT-Supporter, IT-Techniker, IT-Systemtechniker, Systemtechniker, IT-Systembetreuer,
|
||||
IT-Betreuer, IT-Allrounder, IT-Koordinator, IT-Mitarbeiter, IT-Operations / IT-Betrieb,
|
||||
Remote-Support, Remote-Systemadministrator, Service-Desk, Application Manager (remote).
|
||||
(Rein ortsgebundene Onsite-/Field-Service-Rollen entfallen hier — sie sind nicht
|
||||
remote ausübbar.)
|
||||
- **Infrastruktur/Netz:** System Engineer, Systems Engineer, Infrastructure Engineer,
|
||||
IT-Infrastruktur, Infrastruktur-Administrator, Netzwerkadministrator, Network Engineer,
|
||||
Virtualisierungsadministrator, Storage-/Backup-Administrator.
|
||||
- **Cloud/Modern Workplace:** Cloud-Administrator, Cloud Engineer, Cloud-Operations-Engineer,
|
||||
Microsoft-365-Administrator, M365-/Modern-Workplace-Administrator,
|
||||
Azure-/Entra-Administrator, DevOps-Engineer (Infrastruktur-lastig),
|
||||
Site Reliability Engineer (SRE), Platform Engineer, Linux-Administrator,
|
||||
Linux System Engineer, Windows-Administrator.
|
||||
- **Managed Services / Hosting / Betrieb (passt zu Hetzner/OVH im CV):**
|
||||
IT-Consultant (remote), IT-Berater (technisch), IT-Systemberater,
|
||||
Managed-Services-Engineer, MSP-Engineer, NOC-Engineer, Cloud Operations,
|
||||
Hosting-Administrator, Hosting Engineer, Systemadministrator Rechenzentrum (remote).
|
||||
|
||||
Ausschließen bleiben reine Softwareentwickler-, Data-Science-, Vertriebs- und
|
||||
SAP-only-Stellen, außer sie passen klar zum Infrastruktur-Profil.
|
||||
|
||||
> **Ex-Arbeitgeber IMMER ausschließen (harte Regel, unabhängig von der Schreibweise):**
|
||||
> Stellen der **„IT-Problemlöser"** (Essen) — voller Firmenname u. a.
|
||||
> **„IT Problemlöser Verwaltungs- und Handels GmbH"**, auch **„IT-Problemlöser GmbH"**,
|
||||
> **„IT Problemlöser"** o. Ä. — werden **nie** gelistet oder importiert. Es ist der
|
||||
> frühere Arbeitgeber des Nutzers (siehe Lebenslauf). Diese Firma taucht immer wieder
|
||||
> mit **wechselnden Stellentiteln** auf; die `firma_stelle`-Blacklist greift dann nicht,
|
||||
> weil der Titel abweicht. Deshalb **jeden Treffer verwerfen, dessen Firmenname `IT
|
||||
> Problemlöser` / `IT-Problemlöser` (in jeder Rechtsform-/Schreibvariante) enthält** —
|
||||
> ohne auf die Blacklist zu warten. (Firmenweite `firma`-Blacklist-Einträge greifen
|
||||
> inzwischen schreibweisen-robust über `firma_slug` inkl. Präfix-Match — diese
|
||||
> Modell-Regel bleibt trotzdem als zusätzliche Sicherung bestehen.)
|
||||
|
||||
**Arbeitsmodell (harter Filter — das Kernkriterium dieses Skills):**
|
||||
Nur **100 % Remote / vollständig ortsunabhängige** Stellen, die **deutschlandweit
|
||||
aus dem Homeoffice** erbracht werden können.
|
||||
|
||||
- **Zulässig** (behalten): Anzeigen, die klar als „100 % Remote", „Full Remote",
|
||||
„vollständig remote", „remote-first", „ortsunabhängig", „deutschlandweit im
|
||||
Homeoffice", „remote (Deutschland)" o. Ä. ausgeschrieben sind — die Tätigkeit ist
|
||||
im Alltag komplett aus dem Homeoffice möglich. **Gelegentliche** Vor-Ort-Termine
|
||||
(Onboarding, wenige Team-Events/Kick-offs pro Quartal/Jahr) sind unschädlich.
|
||||
- **Verwerfen** (nicht listen, nicht importieren):
|
||||
- **Reine Vor-Ort-/Präsenz-Stellen** (kein oder nur „nach Absprache"-Homeoffice).
|
||||
- **Klassische Hybrid-Modelle mit festen Präsenz-/Bürotagen** (z. B. „2–3 Tage/
|
||||
Woche vor Ort", „überwiegend Präsenz", „Homeoffice anteilig/tageweise möglich") —
|
||||
das ist **nicht** 100 % remote.
|
||||
- Stellen, die **Wohnsitz/Anwesenheit in einem bestimmten Ort oder Umkreis**
|
||||
verlangen („Einsatzort …", „Wohnsitz im Raum …", „regelmäßig beim Kunden vor
|
||||
Ort", „Rufbereitschaft vor Ort", Onsite-Field-Service).
|
||||
- Stellen ohne **Anstellung in Deutschland** (z. B. „remote nur aus <anderes
|
||||
Land>", Arbeitsvertrag/Steueransässigkeit außerhalb DE). Der Job muss für einen
|
||||
in **Deutschland ansässigen** Bewerber als reguläre Anstellung offenstehen.
|
||||
- **Kein geografischer Prioritäts-Ranking** (deutschlandweit gleichwertig) — statt
|
||||
nach Ort **nach Relevanz** (Profil-/Buzzword-Passung, s. u.) und **Klarheit des
|
||||
100-%-Remote-Versprechens** priorisieren.
|
||||
|
||||
> Bei Unsicherheit, ob eine Stelle wirklich 100 % remote ist, die Anzeige per
|
||||
> `WebFetch` genau lesen (Abschnitte „Arbeitsmodell", „Das bieten wir", „Standort").
|
||||
> Steht dort nur „Homeoffice möglich"/„flexibel" ohne klares 100-%-Remote, im Zweifel
|
||||
> **verwerfen** — dieser Skill nimmt ausschließlich eindeutig vollständig remote
|
||||
> Stellen auf.
|
||||
|
||||
**Skills/Buzzwords** (für Query-Varianten & Relevanzbewertung): erste Gruppe stammt
|
||||
direkt aus dem Lebenslauf (Kernkompetenzen, höchste Gewichtung), die weiteren sind
|
||||
naheliegende, zum Profil passende Technologien — als Suchbegriffe und zum Erkennen
|
||||
passender Anzeigen nutzen, auch wenn sie nicht wörtlich im CV stehen:
|
||||
|
||||
- **Kern (aus dem CV, höchste Gewichtung):** Windows Server, Active Directory,
|
||||
Exchange, Microsoft 365 / MS365, Linux-Administration (Debian/Ubuntu),
|
||||
Docker/Container, Proxmox/Virtualisierung, Netzwerk (OPNsense, pfSense,
|
||||
VPN: WireGuard/OpenVPN/IPsec, LAN/WAN, TCP/IP), Firewall, Monitoring
|
||||
(Prometheus, Grafana, Beszel, Uptime Kuma), Hetzner/OVH Cloud, Self-Hosting,
|
||||
Automatisierung, AI/Claude/Agent-Workflows.
|
||||
- **Microsoft-/Windows-Umfeld:** Entra ID / Azure AD, Intune, Endpoint Manager,
|
||||
Group Policy / GPO, WSUS, PowerShell, Hyper-V, SharePoint, Teams, Windows 10/11,
|
||||
Client-Management, MDM.
|
||||
- **Virtualisierung/Server:** VMware vSphere / ESXi, Hyper-V, Citrix, KVM,
|
||||
Terminalserver / RDS, Server-Hardware (Dell/HPE/Lenovo).
|
||||
- **Backup/Storage:** Veeam, Backup & Recovery, Datensicherung, NAS/SAN, TrueNAS,
|
||||
ZFS, Ceph, Synology, QNAP.
|
||||
- **Netzwerk/Security:** VLAN, Routing & Switching, Cisco, Fortinet/FortiGate,
|
||||
Sophos, Ubiquiti/UniFi, DNS/DHCP, Reverse Proxy (Nginx, Traefik), Let's Encrypt,
|
||||
IT-Security, Patch-Management, ISO 27001, IT-Grundschutz.
|
||||
- **Cloud/DevOps/Automatisierung:** Microsoft Azure, AWS, Kubernetes, Ansible,
|
||||
Terraform, GitLab / CI/CD, Bash-/Shell-Scripting, Portainer, Nextcloud.
|
||||
- **Datenbanken/Web:** MySQL/MariaDB, PostgreSQL, MS SQL Server, Apache, Nginx, IIS.
|
||||
- **Betrieb/Organisation:** Ticketsystem (Jira, OTRS, Zammad), Helpdesk,
|
||||
Rechenzentrum, On-Premise, Managed Services, IT-Dienstleister, Systemhaus,
|
||||
Cloud-Provider, Hosting-Anbieter.
|
||||
|
||||
> Aktuelles Profil (Titel, Skills, Ort) steht in der Lebenslauf-Vorlage der API:
|
||||
> `bewerbungs-tracker` → `GET /templates` (typ `Lebenslauf`). Bei Bedarf dort
|
||||
> gegenlesen, statt zu raten.
|
||||
|
||||
## Quellen-Politik (WICHTIG)
|
||||
|
||||
Ziel ist **immer die Original-Stellenausschreibung direkt beim echten Arbeitgeber**
|
||||
— bevorzugt auf dessen **Firmen-/Karriereseite**.
|
||||
|
||||
- **Ausschließen (nicht listen, nicht importieren):**
|
||||
- **Headhunter / Personalvermittler / Personalberatungen** (recruiten für Dritte).
|
||||
- **Zeitarbeit / Arbeitnehmerüberlassung / Personaldienstleister** (z. B. Randstad,
|
||||
Hays, GULP, Amadeus FiRe, Adecco, Manpower, Piening, Tempton, DIS AG, Robert Half
|
||||
u. ä. — auch unbekannte, wenn die Anzeige „Arbeitnehmerüberlassung",
|
||||
„im Kundenauftrag", „für unseren Kunden", „Personaldienstleister" o. Ä. nennt).
|
||||
- **Stepstone** als Quelle — nicht als Board nutzen, keine `site:stepstone.de`-Query,
|
||||
keine Stepstone-Links importieren.
|
||||
- **Erkennungsmerkmale eines Vermittlers/Zeitarbeit** (bei Unsicherheit die
|
||||
Firmen-/Impressumsseite per `WebFetch` prüfen): Formulierungen wie „für unseren
|
||||
Kunden", „im Auftrag unseres Mandanten", „Arbeitnehmerüberlassung", „Direktvermittlung",
|
||||
„Personaldienstleistung", „Recruiting-Partner"; oder die inserierende Firma ist erkennbar
|
||||
eine Personal-/Recruiting-Agentur. → **verwerfen**.
|
||||
- **Zulässig als Quelle**, wenn es zur Original-Anzeige des Arbeitgebers führt:
|
||||
Firmen-Karriereseite (bevorzugt), Arbeitsagentur/Bundesagentur für Arbeit, Indeed
|
||||
oder LinkedIn **nur** wenn die Anzeige eindeutig vom echten Arbeitgeber (nicht von
|
||||
einem Vermittler) stammt. Führt ein Board-Treffer zu einer Firma, deren eigene
|
||||
Karriereseite dieselbe Stelle direkt listet, **immer den Firmen-Direktlink** nehmen.
|
||||
- **Remote-spezifische Boards** (nur als Ergänzung, immer zur Arbeitgeber-Originalanzeige
|
||||
durchklicken): z. B. `germantechjobs.de`, `remotarr`, `remote.io`, `remoteok.com`,
|
||||
`4dayweek.io`, `join.com`, `arbeitsagentur.de` (Filter „Homeoffice/Telearbeit"),
|
||||
`de.indeed.com` (Filter „Remote"), `de.linkedin.com/jobs` (Filter „Remote") — auch hier
|
||||
Vermittler/Zeitarbeit/Stepstone ausschließen und den Firmen-Direktlink bevorzugen.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Bereits erfasste Jobs + Blacklist laden** (Dedup-Basis). Dieser Schritt ist
|
||||
**immer zuerst** auszuführen, damit Stellen aus früheren Suchläufen — **auch aus
|
||||
dem regionalen Skill** — **nicht erneut** gefunden/importiert werden. Zwei Quellen:
|
||||
```bash
|
||||
scripts/applied-set.sh # firma_slug<TAB>firma<TAB>stelle<TAB>ort<TAB>quelle_url<TAB>external_id
|
||||
scripts/blacklist-set.sh # id<TAB>typ<TAB>firma<TAB>stelle<TAB>ort<TAB>domain<TAB>url_norm<TAB>firma_norm<TAB>firma_slug<TAB>stelle_norm<TAB>ort_norm<TAB>grund
|
||||
```
|
||||
- **applied-set** (Bewerbungen **und** importierte Jobangebote): **eine Zeile
|
||||
pro bereits erfasster Firma** (company-level, nicht mehr pro Stelle). Je Zeile
|
||||
drei Dublett-Merkmale merken: **`firma_slug`** (robuster Firmen-Schlüssel:
|
||||
lowercase, Umlaute→ae/oe/ue/ss, `(m/w/d)` raus, End-Rechtsform wie gmbh/ag/kg
|
||||
entfernt, mit `-` verbunden), **`quelle_url`** und **`external_id`**.
|
||||
- **blacklist-set** (gesperrte Muster): je Zeile den **`typ`** und die dazu
|
||||
passenden Felder merken (`url_norm`, `domain`, `firma_norm`, **`firma_slug`**,
|
||||
`stelle_norm`). Die `*_norm`/`firma_slug`-Felder liefert der Server bereits
|
||||
normalisiert (lowercase, Tracking-Parameter entfernt, `(m/w/d)`/Rechtsform
|
||||
bereinigt).
|
||||
|
||||
2. **Kandidaten sammeln — strukturierte Quelle zuerst, dann WebSearch.**
|
||||
|
||||
**(a) Arbeitsagentur-API mit Homeoffice-Filter (primär, strukturiert, frisch).**
|
||||
Vor der Freitext-Suche die Jobsuche-API der Bundesagentur für Arbeit abfragen —
|
||||
**deutschlandweit** (`wo` leer) mit `arbeitszeit=ho` (Homeoffice-Flag):
|
||||
```bash
|
||||
scripts/arbeitsagentur.sh search "<Rolle>" "" 0 30 100 ho
|
||||
# -> firma_slug<TAB>firma<TAB>titel<TAB>ort<TAB>datum<TAB>refnr<TAB>angebotsart
|
||||
```
|
||||
Rollen aus dem Suchprofil durchrotieren (Systemadministrator, IT-Administrator,
|
||||
Linux/Windows-Administrator, Cloud Administrator, System Engineer, DevOps, SRE, …).
|
||||
Jede Zeile sofort per `firma_slug` gegen applied-set/blacklist prüfen (Firmen-Dedup,
|
||||
Schritt 1). Für überlebende Treffer die Details holen:
|
||||
```bash
|
||||
scripts/arbeitsagentur.sh detail <refnr>
|
||||
```
|
||||
Detail liefert **Volltext** (→ `beschreibung`), **`EXTERNE_URL`** (→ bevorzugt
|
||||
`quelle_url`), **`HOMEOFFICE_MOEGLICH`**, **Vergütung**, Firmensitz und die Flags
|
||||
**`ZEITARBEIT_AUE` / `PRIVATE_ARBEITSVERMITTLUNG`** — `True` → Zeitarbeit/Vermittler
|
||||
→ **verwerfen**. ⚠️ `arbeitszeit=ho`/`HOMEOFFICE_MOEGLICH` heißt nur „Homeoffice
|
||||
möglich", **nicht** automatisch „100 % remote" — die harte 100-%-Remote-Prüfung
|
||||
(Schritt 4) gilt unverändert am Volltext. „Keine aktive Anzeige" → verwerfen; `refnr`
|
||||
stabil → Existenz-Check & `external_id`. (Die API ist ortsorientiert und deshalb hier
|
||||
nur **eine** Quelle — WebSearch bleibt für Remote-Boards & remote-first-Firmen wichtig.)
|
||||
|
||||
**(b) WebSearch (ergänzend).** Mit dem `WebSearch`-Tool **viele** Queries fahren —
|
||||
Rolle × **Remote/Homeoffice**, **deutschlandweit** (kein Ort anhängen), mit Fokus
|
||||
auf **Original-Anzeigen der Arbeitgeber**.
|
||||
|
||||
> **Query-Strategie (Recall maximieren — WICHTIG, findet die Suche „kaum noch
|
||||
> Stellen"):** Lieber **viele einfache, natürlichsprachliche Einzel-Queries** als
|
||||
> wenige überladene. **Boolesche Operatoren sparsam einsetzen** — `OR`, `"…"`,
|
||||
> `site:`, `inurl:` und `-minus`-Ausschlüsse **senken bei WebSearch oft drastisch
|
||||
> die Trefferzahl**. Statt `A OR B "…" inurl:jobs`-Monsterqueries lieber **getrennte,
|
||||
> kurze Queries**; Vermittler/Stepstone/Hybrid erst **nachträglich beim Filtern**
|
||||
> (Schritt 3) rauswerfen. Jede Rolle mit **mehreren Remote-Synonymen** und Suffixen
|
||||
> durchvariieren: Remote-Wörter `remote`, `100% Remote`, `Homeoffice`,
|
||||
> `home office`, `ortsunabhängig`, `deutschlandweit`, `remote-first`, `full remote`;
|
||||
> Suffixe `Stellenangebot`, `Job`, `Jobs`, `Festanstellung`, `unbefristet`,
|
||||
> `Vollzeit`, `2026`.
|
||||
|
||||
**Rolle × Remote (mehrere Synonyme/Suffixe durchspielen), Beispiele:**
|
||||
- `Systemadministrator 100% Remote Stellenangebot Deutschland`,
|
||||
`Systemadministrator remote Homeoffice Job`, `Systemadministrator ortsunabhängig Festanstellung`
|
||||
- `IT-Administrator remote deutschlandweit Job`, `IT-Administrator Homeoffice Vollzeit`,
|
||||
`IT-Systemadministrator full remote 2026`
|
||||
- `IT-Systemadministrator vollständig remote Stellenangebot`,
|
||||
`2nd Level Support remote deutschlandweit`, `Remote-Systemadministrator Festanstellung`
|
||||
- `Linux Administrator remote Deutschland`, `Linux System Engineer Homeoffice`,
|
||||
`Windows Administrator remote deutschlandweit`
|
||||
- `Microsoft 365 Administrator remote Homeoffice`, `Cloud Administrator 100% Homeoffice`,
|
||||
`Cloud Engineer remote Deutschland`, `Azure Administrator remote Festanstellung`
|
||||
- `System Engineer remote Deutschland`, `Infrastructure Engineer Homeoffice`,
|
||||
`Platform Engineer remote deutschlandweit`, `SRE remote Deutschland`
|
||||
- `Hosting Administrator remote`, `Managed Services Engineer remote Homeoffice`,
|
||||
`NOC Engineer remote Deutschland`, `IT-Consultant remote Homeoffice`
|
||||
- **Buzzword-getrieben** (holt Anzeigen mit abweichendem Titel, passendem Inhalt):
|
||||
`VMware Administrator remote Deutschland`, `Proxmox remote Homeoffice Job`,
|
||||
`Docker Kubernetes remote Administrator`, `Active Directory remote Homeoffice`,
|
||||
`Veeam Backup remote Job`, `Hetzner OVH remote Administrator`,
|
||||
`OPNsense pfSense Firewall remote Job`, `Ansible Automatisierung remote Deutschland`.
|
||||
- **Remote-Boards zusätzlich** (jeweils **einzeln**, nicht stapeln): `germantechjobs
|
||||
systemadministrator remote`, `remoteok IT administrator`, `4dayweek.io sysadmin`,
|
||||
`join.com systemadministrator remote`, `Systemadministrator Homeoffice arbeitsagentur`,
|
||||
`IT Administrator remote indeed`. Falls doch `site:`, dann einzeln:
|
||||
`site:germantechjobs.de systemadministrator remote`,
|
||||
`site:de.indeed.com IT Administrator remote`,
|
||||
`site:arbeitsagentur.de Systemadministrator Telearbeit`. **Kein** `site:stepstone.de`.
|
||||
Für Details/Arbeitsmodell/Firma einer Trefferseite `WebFetch` nutzen. Sieht ein
|
||||
Treffer nach Firmen-Karriereseite aus: dort direkt nach der Einzelanzeige suchen.
|
||||
|
||||
2b. **Remote-freundliche Arbeitgeber gezielt finden** (Hauptquelle für „unentdeckte"
|
||||
Stellen). Board-Suchen finden nur, was breit ausgeschrieben ist — viele
|
||||
remote-first-Arbeitgeber posten IT-Stellen **ausschließlich auf der eigenen
|
||||
Website**. Deshalb parallel zur Rolle-×-Remote-Suche **remote-affine Arbeitgeber
|
||||
deutschlandweit identifizieren** und deren Karriereseite direkt öffnen:
|
||||
- **Arbeitgeber-Typen recherchieren:** Cloud-/Hosting-Provider, Managed-Service-
|
||||
Provider (MSP), SaaS-/Tech-Unternehmen, IT-Dienstleister/Systemhäuser mit
|
||||
Remote-Kultur, verteilte/remote-first-Firmen. Beispiel-Queries:
|
||||
`remote-first Unternehmen Deutschland IT`, `MSP remote Systemadministrator Karriere`,
|
||||
`SaaS Unternehmen Deutschland remote Stellenangebote`,
|
||||
`Cloud Provider Deutschland Karriere remote`.
|
||||
- **Karriereseite direkt anfahren:** zu jeder gefundenen Firma
|
||||
`WebSearch "<Firma> Karriere remote"` bzw. `"<Firma> Jobs remote"` und die
|
||||
Jobliste per `WebFetch` öffnen; auf offene **100-%-Remote IT-/Administrator-/
|
||||
Support-Stellen** prüfen. Auch `inurl:karriere`, `inurl:jobs`, `inurl:stellen`
|
||||
gezielt einsetzen und gängige Bewerber-Portale erkennen (softgarden/onlyfy/
|
||||
Personio/Workday/join.com).
|
||||
- **Buzzwords als Türöffner:** findet die reine Titel-Suche wenig, mit den
|
||||
Technologie-Buzzwords (oben) + „remote" suchen, z. B.
|
||||
`Active Directory remote Administrator Deutschland`, `Veeam remote Job Homeoffice`.
|
||||
- Jede so gefundene Stelle läuft durch dieselben Prüf-/Filter-/Dedup-Schritte
|
||||
(3–7). Der Firmen-Direktlink ist hier ohnehin schon die bevorzugte `quelle_url`.
|
||||
|
||||
3. **Filtern & bewerten:**
|
||||
- **Arbeitsmodell (harter Ausschluss):** **nur** eindeutig **100 % Remote /
|
||||
vollständig ortsunabhängige** Stellen, deutschlandweit aus dem Homeoffice
|
||||
ausübbar (Anstellung in Deutschland). Alles andere — reine Präsenz, Hybrid mit
|
||||
festen Bürotagen, ortsgebundene/„Homeoffice möglich"-ohne-100%-Zusage,
|
||||
Anstellung außerhalb DE — **verwerfen**. Kein geografisches Ranking; nach
|
||||
Relevanz priorisieren.
|
||||
- **Rolle:** Systemadministration/IT-Infrastruktur; keine reinen Entwickler-,
|
||||
Vertriebs- oder SAP-only-Stellen (außer sie passen klar zum Profil).
|
||||
- **Quelle (harter Ausschluss):** Headhunter/Personalvermittler, Zeitarbeit/
|
||||
Arbeitnehmerüberlassung und Stepstone werden **verworfen** — siehe
|
||||
„Quellen-Politik". Nur Original-Anzeigen echter Arbeitgeber behalten.
|
||||
- **Dedup (persistent, FIRMEN-basiert):** **Eine Firma darf nur EINMAL gefunden
|
||||
werden** (regional **und** remote gemeinsam). Treffer **verwerfen**, sobald
|
||||
**eines** zutrifft: (a) gleiche/sehr ähnliche `quelle_url`, (b) gleiche
|
||||
`external_id`, oder (c) **die Firma steht schon im Applied-Set** — unabhängig vom
|
||||
Stellentitel. Firmen-Gleichheit über `firma_slug` prüfen: Kandidaten-Firma ebenso
|
||||
sluggen (lowercase, Umlaute→ae/oe/ue/ss, `(m/w/d)` & End-Rechtsform raus, mit `-`
|
||||
verbunden) und als **dieselbe Firma** werten, wenn der Slug **gleich** ist ODER
|
||||
**ein Slug ein führendes Bindestrich-Präfix des anderen** ist (mind. 2 Tokens) —
|
||||
so zählen **verschiedene Schreibweisen/Rechtsform-/Namensvarianten derselben
|
||||
Firma als eine** (z. B. „IT-Problemlöser GmbH" = „IT Problemlöser Verwaltungs-
|
||||
und Handels GmbH"). Offensichtlich derselbe Arbeitgeber → als Dublette verwerfen.
|
||||
Distinkte Firmen mit nur gleichem ersten Wort („Meyer IT" vs. „Meyer Logistik")
|
||||
sind **nicht** dieselbe Firma. Im Zweifel behalten und als „evtl. Dublette"
|
||||
markieren.
|
||||
- **Blacklist (harter Ausschluss):** Kandidat **verwerfen** (nicht listen, nicht
|
||||
importieren), sobald er auf einen Blacklist-Eintrag passt — je nach `typ`:
|
||||
- `url` → normalisierte Kandidaten-URL == `url_norm`.
|
||||
- `domain` → Host der Kandidaten-URL == `domain` (auch Subdomains).
|
||||
- `firma` → **dieselbe Firma** wie der Eintrag (Kandidaten-`firma_slug` gleich
|
||||
`firma_slug` **oder** Präfix-Match wie bei der Dedup; `firma_norm` nur als
|
||||
Fallback für Alt-Einträge ohne Slug).
|
||||
- `firma_stelle` → dieselbe Firma (`firma_slug`, wie oben) **und** `stelle_norm`
|
||||
passen (ist `ort_norm` gesetzt, muss auch der Ort passen).
|
||||
- `auto` → wie die konkreten Felder, die der Eintrag trägt.
|
||||
Diese Muster sind bewusst blockiert (u. a. jeder früher importierte Job, siehe
|
||||
Schritt 6) — geblacklistete Stellen daher **stillschweigend überspringen**,
|
||||
nicht als „evtl. Dublette" präsentieren.
|
||||
- **Relevanz:** höher gewichten, je mehr Buzzwords aus dem Profil passen.
|
||||
|
||||
4. **Existenz prüfen, Link prüfen, Remote-Zusage bestätigen, Kontakt-E-Mail &
|
||||
Firmensitz recherchieren** — für jeden Treffer, der in die engere Wahl kommt,
|
||||
**zwingend einzeln**:
|
||||
- **Existenz-Prüfung (Pflicht):** Jede Stelle mit `WebFetch` auf dem Einzel-Link
|
||||
öffnen und bestätigen, dass die Anzeige **noch aktiv** ist (Firma + Stelle
|
||||
stehen dort, kein 404/„Stelle nicht mehr verfügbar"/Redirect auf Jobliste).
|
||||
Snippets aus der WebSearch reichen **nicht** — Suchindizes zeigen oft schon
|
||||
abgelaufene Anzeigen. Kein Live-Nachweis → Treffer **verwerfen**. Bei bereits
|
||||
importierten Angeboten, die nicht mehr existieren, das JobOffer löschen
|
||||
(`DELETE /joboffers/{id}`).
|
||||
- **100-%-Remote live bestätigen (Pflicht):** Im per `WebFetch` geöffneten
|
||||
Anzeigentext prüfen, dass die Stelle **tatsächlich vollständig remote /
|
||||
deutschlandweit ortsunabhängig** ist (Abschnitte „Arbeitsmodell", „Standort",
|
||||
„Das bieten wir"). Nur „Homeoffice möglich"/„hybrid"/feste Präsenztage → **nicht**
|
||||
100 % remote → **verwerfen**. Nur eindeutig vollständig remote Stellen behalten.
|
||||
- **Vollständige Stellenausschreibung erfassen (Pflicht):** Beim `WebFetch` der
|
||||
Einzelanzeige den **kompletten Ausschreibungstext** übernehmen — nicht nur eine
|
||||
Kurzzusammenfassung. Dazu gehören: Einleitung/Unternehmensvorstellung, **Aufgaben/
|
||||
Tätigkeiten**, **Anforderungen/Profil**, **Wir bieten/Benefits**, Angaben zu
|
||||
Arbeitszeit/Vertragsart/**Remote-Regelung**, Gehalt (falls genannt), Bewerbungsweg/
|
||||
Kontakt und Referenz-/Kennziffer. Text weitgehend **wortgetreu und vollständig**
|
||||
sichern (nur Navigations-/Cookie-/Footer-Boilerplate der Seite weglassen), inkl.
|
||||
der Gliederung/Überschriften. Dieser Volltext wandert in `beschreibung`
|
||||
(Schritt 6). Ist die Seite lang/abgeschnitten, `WebFetch` gezielt erneut aufrufen.
|
||||
- **`quelle_url` verifizieren:** Muss auf die **konkrete, noch aktive
|
||||
Einzelanzeige** zeigen (nicht Trefferliste/Suchseite). Deeplink defekt/Liste →
|
||||
per Suche den echten Einzel-Link finden (bevorzugt Firmenwebsite/Karriereseite),
|
||||
sonst verwerfen.
|
||||
- **Vermittler/Zeitarbeit aussortieren (Pflicht):** Zeigt der Treffer auf eine
|
||||
Personalberatung/Headhunter/Zeitarbeit statt den echten Arbeitgeber, **verwerfen**.
|
||||
Bei Unsicherheit die inserierende Firma per `WebFetch` (Impressum/„Über uns")
|
||||
prüfen — Recruiting-/Personaldienstleister raus. Existiert dieselbe Stelle direkt
|
||||
auf der Firmen-Karriereseite, diese Original-Anzeige verwenden.
|
||||
- **Bewerber-Kontakt-E-Mail recherchieren:** Die E-Mail-Adresse ermitteln, an die
|
||||
sich Bewerber wenden. Reihenfolge: (a) direkt in der Stellenanzeige genannte
|
||||
Bewerbungs-/Kontaktadresse; (b) Karriere-/Kontaktseite der Firma
|
||||
(`WebSearch` „<Firma> Karriere Kontakt Bewerbung E-Mail", `WebFetch` der Seite);
|
||||
(c) allgemeine Bewerbungsadresse (`bewerbung@`/`jobs@`/`karriere@<domain>`) nur,
|
||||
wenn auf der Firmenseite belegt. **Nicht raten** — nur belegte Adressen; sonst
|
||||
`kontakt_email` leer lassen und als „nicht gefunden" markieren.
|
||||
- **Firmensitz recherchieren (Pflicht, soweit belegbar):** Da die Stelle
|
||||
ortsunabhängig ist, gibt es keinen festen Arbeitsort — als `adresse` den
|
||||
**eingetragenen Firmensitz** des Arbeitgebers erfassen (Straße, Hausnummer, PLZ,
|
||||
Ort; Quelle: Impressum/Kontaktseite, `WebSearch` „<Firma> Impressum Adresse",
|
||||
`WebFetch` der Seite). **Nicht raten** — nur eine belegte Anschrift übernehmen;
|
||||
sonst `adresse` leer lassen und als „nicht gefunden" markieren. Der Firmensitz
|
||||
ist reine Zusatzinfo und **kein** Filterkriterium (die Stelle bleibt zulässig,
|
||||
egal wo die Firma sitzt).
|
||||
|
||||
5. **Ergebnis präsentieren** als Tabelle: Firma · Stelle · **Arbeitsmodell (100 %
|
||||
Remote)** · Firmensitz · Quelle (Board) · **verifizierter Link** ·
|
||||
**Kontakt-E-Mail** · kurze Passt-Begründung. Sortierung: neue, klar passende
|
||||
Treffer **nach Relevanz** (Buzzword-Passung; bei Gleichstand klar/eindeutig
|
||||
100-%-Remote vor „remote, aber schwammig formuliert"). Fehlt Link, E-Mail oder
|
||||
Firmensitz, kennzeichnen.
|
||||
|
||||
6. **Importieren** — im **interaktiven** Modus nur nach Rückfrage/Bestätigung des
|
||||
Nutzers; im **autonomen Modus** (siehe unten) automatisch ohne Rückfrage. Jeden
|
||||
neuen Treffer als JobOffer einspielen (Upsert, idempotent) über den
|
||||
`bewerbungs-tracker`-Skill:
|
||||
```bash
|
||||
~/.claude/skills/bewerbungs-tracker/scripts/bt.sh POST /joboffers '{
|
||||
"external_id": "remote-<slug(firma)>-<slug(stelle)>",
|
||||
// IMMER setzen und DETERMINISTISCH aus
|
||||
// firma+stelle bilden — NICHT aus der
|
||||
// Board-/Anzeigen-ID. Präfix "remote-" hält
|
||||
// Remote-Funde auseinander; Slug = normalisiert
|
||||
// wie der firma_slug (lowercase, ohne (m/w/d)
|
||||
// & Rechtsform, Interpunktion→"-"), z. B.
|
||||
// "remote-musterfirma-cloud-administrator".
|
||||
// So bekommt DIESELBE Stelle über jeden Lauf
|
||||
// UND jedes Board dasselbe external_id →
|
||||
// Server-Upsert greift zuverlässig statt eine
|
||||
// Dublette anzulegen. (Eine flüchtige Board-ID
|
||||
// würde je Quelle abweichen und Duplikate
|
||||
// erzeugen — daher NICHT nutzen.)
|
||||
"quelle": "stellensuche-remote",
|
||||
"firma": "…", "stelle": "…",
|
||||
"ort": "Remote (Deutschland)", // ortsunabhängig; ggf. "100% Remote / Homeoffice"
|
||||
"adresse": "<eingetragener Firmensitz: Straße Hausnr, PLZ Ort; recherchiert &
|
||||
verifiziert; sonst weglassen>",
|
||||
"gehalt": "…",
|
||||
"beschreibung": "<VOLLSTÄNDIGE Stellenausschreibung>",
|
||||
// Der komplette, in Schritt 4 per WebFetch
|
||||
// erfasste Anzeigentext inkl. Remote-Regelung —
|
||||
// wortgetreu und vollständig, nicht kürzen.
|
||||
// Gliederung/Überschriften erhalten (Markdown ok).
|
||||
"quelle_url": "<verifizierter Einzel-Link, bevorzugt Firmen-Karriereseite>",
|
||||
"art": "Firmenwebsite",
|
||||
"anzeige_datum": "YYYY-MM-DD",
|
||||
"kontakt_email": "<recherchierte Bewerber-E-Mail, sonst weglassen>",
|
||||
"labels": ["Remote-Deutschlandweit", "Homeoffice-Deutschlandweit"]
|
||||
// IMMER beide setzen: dieser Skill sucht ausschließlich
|
||||
// 100% Remote / Homeoffice deutschlandweit → Arbeitsort-
|
||||
// Labels "Remote-Deutschlandweit" + "Homeoffice-Deutschlandweit".
|
||||
}'
|
||||
```
|
||||
`art`-Enum: `E-Mail`, `Online-Portal`, `Indeed`, `StepStone`, `Firmenwebsite`,
|
||||
`Post`, `Initiativbewerbung`, `Arbeitsagentur`, `Sonstiges`. **Standard ist
|
||||
`Firmenwebsite`** (Original-Anzeige des Arbeitgebers). `StepStone` nie verwenden
|
||||
(ausgeschlossene Quelle); `Arbeitsagentur`/`Indeed` nur, wenn der Link direkt zur
|
||||
Arbeitgeber-Anzeige führt.
|
||||
|
||||
**`409`-Antwort beim Import:** Steht der Job (trotz Vorfilter) auf der Blacklist,
|
||||
antwortet `POST /joboffers` mit **409** (`BlacklistConflict`) und nimmt ihn
|
||||
**nicht** auf. Das ist **kein Fehler** — als „übersprungen (Blacklist)" zählen
|
||||
und mit dem nächsten Treffer weitermachen, **nicht** mit `force` erzwingen.
|
||||
|
||||
7. **Direkt blacklisten (nach jedem erfolgreichen Import).** Sobald ein JobOffer
|
||||
angelegt wurde (Antwort **201** / `action:created`; bei `updated` ist der Job
|
||||
bereits erfasst), die **Firma sofort ganz** blacklisten, damit dieser Arbeitgeber
|
||||
in künftigen Läufen — remote **wie regional** — **mit keinem Stellentitel** wieder
|
||||
auftaucht (Regel „eine Firma nur einmal"). Per `typ: firma` sperren — der Server
|
||||
matcht firmenweit über `firma_slug` und deckt so abweichende Schreibweisen/
|
||||
Rechtsformen mit ab:
|
||||
```bash
|
||||
~/.claude/skills/bewerbungs-tracker/scripts/bt.sh POST /joboffers/blacklist '{
|
||||
"typ": "firma",
|
||||
"firma": "<firma wie importiert>",
|
||||
"grund": "auto: stellensuche-remote-import <YYYY-MM-DD>"
|
||||
}'
|
||||
```
|
||||
Server-Antwort **201** = geblacklistet. Normalisierung (Groß/Klein, `(m/w/d)`,
|
||||
Rechtsform, Umlaute) übernimmt der Server. Nur nach **echtem** Neuimport
|
||||
blacklisten — nicht bei einem 409-Skip und nicht bei bloßem `updated`.
|
||||
|
||||
## Autonomer Modus (headless / geplant)
|
||||
|
||||
Wird der Skill **nicht-interaktiv** ausgeführt — d. h. ohne Nutzer, der bestätigen
|
||||
kann (z. B. `claude -p "…" --dangerously-skip-permissions`, Cron/geplanter Lauf,
|
||||
`ollama launch claude … -p …`) — im **autonomen Modus** arbeiten:
|
||||
|
||||
- **Ohne Rückfrage importieren:** Neue, geprüfte Treffer direkt als JobOffer
|
||||
einspielen (Schritt 6) **und anschließend blacklisten** (Schritt 7). Es gibt
|
||||
niemanden zum Bestätigen — nicht auf Eingabe warten.
|
||||
- **Alle Prüfregeln gelten unverändert und strikt:** Existenz-Prüfung, **100-%-Remote
|
||||
live bestätigt**, korrekter verifizierter Einzel-Link, Kontakt-E-Mail nur wenn
|
||||
belegt, **Firmensitz nur wenn belegt**, die persistente Dedup **und der
|
||||
Blacklist-Filter** — importiere **nur** echte, live verifizierte, eindeutig
|
||||
vollständig remote, noch nicht erfasste und **nicht geblacklistete** Stellen.
|
||||
Im Zweifel **nicht** importieren (lieber auslassen).
|
||||
- **Keine Bewerbungen anlegen/versenden**, keine Löschungen bestehender Bewerbungen,
|
||||
keine Generierung anstoßen — nur neue Jobangebote (`POST /joboffers`) einpflegen
|
||||
und den jeweils importierten Job blacklisten (`POST /joboffers/blacklist`).
|
||||
- **Kurzbericht ausgeben** (für das Log): je Treffer `action`
|
||||
(created+blacklisted / updated / skip-dedup / skip-blacklist) mit Firma, Stelle,
|
||||
Arbeitsmodell, Link; am Ende Zähler „X neu importiert & geblacklistet, Y als
|
||||
Dublette/Blacklist übersprungen, Z verworfen (nicht verifizierbar / nicht 100 %
|
||||
remote)".
|
||||
|
||||
## Regeln
|
||||
|
||||
- **Nur 100 % Remote, deutschlandweit.** Es werden **ausschließlich** eindeutig
|
||||
vollständig remote / ortsunabhängige Stellen gelistet/importiert, die aus dem
|
||||
Homeoffice irgendwo in Deutschland ausübbar sind (Anstellung in DE). Reine
|
||||
Präsenz-, Hybrid- (feste Bürotage) und ortsgebundene Stellen werden **verworfen** —
|
||||
Letztere sind Sache des regionalen Skills `it-stellensuche`. Kein Orts-Ranking,
|
||||
Priorität nach Relevanz.
|
||||
- **Labels `Remote-Deutschlandweit` + `Homeoffice-Deutschlandweit` setzen (Pflicht).**
|
||||
Jedes von diesem Skill importierte JobOffer bekommt
|
||||
`labels: ["Remote-Deutschlandweit", "Homeoffice-Deutschlandweit"]` (100 % remote,
|
||||
deutschlandweit). Kein `Regional`-Label — ortsgebundene Stellen sind Sache des
|
||||
Skills `it-stellensuche`.
|
||||
- **Keine erfundenen Stellen.** Nur Jobs ausgeben, die per WebSearch/WebFetch real
|
||||
belegt sind. **`quelle_url` muss der korrekte, geprüfte Direktlink zur
|
||||
Einzelanzeige sein** (per `WebFetch` bestätigt) — keine Such-/Listenseiten, keine
|
||||
geratenen URLs. Kein verifizierbarer Einzel-Link → Treffer nicht listen/importieren.
|
||||
- **100 % Remote live belegt.** Vor dem Listen/Importieren im Anzeigentext bestätigen,
|
||||
dass die Stelle wirklich vollständig remote ist. „Homeoffice möglich"/hybrid/feste
|
||||
Präsenztage genügen **nicht** → verwerfen.
|
||||
- **Nur Original-Anzeigen echter Arbeitgeber.** Headhunter/Personalvermittler,
|
||||
Zeitarbeit/Arbeitnehmerüberlassung und **Stepstone** sind ausgeschlossen — weder
|
||||
listen noch importieren (siehe „Quellen-Politik"). Bevorzugt der Firmen-Direktlink.
|
||||
- **`beschreibung` = vollständige Ausschreibung.** Immer den kompletten, per WebFetch
|
||||
erfassten Anzeigentext (Aufgaben, Anforderungen, Benefits, Remote-Regelung,
|
||||
Bewerbungsweg, Kennziffer) übernehmen — nicht kürzen oder zusammenfassen.
|
||||
- **Kontakt-E-Mail nicht erfinden.** `kontakt_email` nur setzen, wenn die Adresse in
|
||||
der Anzeige oder auf der Firmen-Karriereseite belegt ist; sonst weglassen.
|
||||
- **Firmensitz recherchieren, nicht erfinden.** `adresse` = belegter Firmensitz aus
|
||||
dem Impressum; sonst leer lassen. Kein Filterkriterium — nur Zusatzinfo.
|
||||
- **Keine Doppelfunde — eine Firma nur EINMAL, auch über Läufe und Skills hinweg.**
|
||||
Vor dem Listen/Importieren immer `applied-set.sh` **und** `blacklist-set.sh` laden
|
||||
und jeden Kandidaten per `quelle_url`, `external_id` **und `firma_slug`
|
||||
(firmenweit)** sowie gegen die Blacklist abgleichen. Dedup/Blacklist sind mit dem
|
||||
regionalen Skill **gemeinsam**. **Steht die Firma schon im Applied-Set oder auf der
|
||||
Blacklist — egal unter welchem Stellentitel und egal in welcher Schreibweise/
|
||||
Rechtsform (`firma_slug` gleich ODER Präfix-Match, mind. 2 Tokens) — wird kein
|
||||
weiterer Treffer dieses Arbeitgebers ausgegeben oder importiert.** Auch **innerhalb
|
||||
eines Laufs** jede Firma nur **einmal** präsentieren. Beim Import die `external_id`
|
||||
**deterministisch aus `firma+stelle`** bilden (Präfix `remote-`), **nicht** aus
|
||||
einer Board-/Anzeigen-ID — so ergibt dieselbe Stelle über jeden Lauf/jedes Board
|
||||
dasselbe `external_id` (Server-Upsert statt Dublette). Der Server dedupliziert
|
||||
`POST /joboffers` über `external_id` (Upsert) und die Blacklist (409, firmenweit
|
||||
über `firma_slug`).
|
||||
- **Blacklisten nach jedem Import (Pflicht, firmenweit).** Jeder frisch angelegte Job
|
||||
(`action:created`) wird direkt anschließend per `POST /joboffers/blacklist`
|
||||
(**`typ:firma`** — die ganze Firma) gesperrt (Schritt 7), damit dieser Arbeitgeber
|
||||
in Folgeläufen mit keinem Titel wieder auftaucht. Nicht blacklisten bei `updated`
|
||||
oder 409-Skip. Ein 409 beim `POST /joboffers` bedeutet „steht schon auf der
|
||||
Blacklist" → überspringen, nie mit `force` erzwingen.
|
||||
- **Interaktiv: nicht ungefragt importieren** — erst zeigen, dann auf Bestätigung
|
||||
importieren. **Autonom/headless: automatisch importieren** (siehe „Autonomer
|
||||
Modus"). In **keinem** Modus Bewerbungen anlegen/versenden.
|
||||
- Board-Aggregatoren-Duplikate (dieselbe Stelle auf mehreren Portalen) zu einem
|
||||
Eintrag zusammenfassen, bevorzugt mit Direkt-/Firmenwebsite-Link.
|
||||
- Ist die Bewerbungs-Tracker-API nicht erreichbar (`GET /health`), Dedup nicht
|
||||
möglich → Nutzer warnen und Treffer ohne Dedup mit Hinweis liefern.
|
||||
|
||||
## Abhängigkeiten
|
||||
|
||||
- Tools: `WebSearch`, `WebFetch`.
|
||||
- Skill `bewerbungs-tracker` (für Dedup-Daten, JobOffer-Import und Blacklist:
|
||||
`GET/POST /joboffers/blacklist`).
|
||||
- Scripts: `scripts/arbeitsagentur.sh` (strukturierte Jobsuche-API der Bundesagentur
|
||||
für Arbeit, `search`/`detail` — hier mit `arbeitszeit=ho`), `scripts/applied-set.sh`
|
||||
(erfasste Firmen), `scripts/blacklist-set.sh` (gesperrte Muster) — allesamt
|
||||
**Symlinks** auf die geteilten Scripts des Skills `it-stellensuche` (eine Quelle der
|
||||
Wahrheit). `applied-set`/`blacklist-set` nutzen den `bt.sh`-Helfer des
|
||||
`bewerbungs-tracker`-Skills; `arbeitsagentur.sh` nur `curl` + `python3`.
|
||||
Reference in New Issue
Block a user