init
This commit is contained in:
commit
d295c7f139
1527 files changed
+270726
No files matched your search
@@ -0,0 +1,112 @@
|
||||
# career-ops — Deutsche Modi (`modes/de/`)
|
||||
|
||||
Dieser Ordner enthält die deutschen Übersetzungen der wichtigsten career-ops-Modi für Bewerber:innen, die im DACH-Raum (Deutschland, Österreich, Schweiz) suchen oder mit deutschen Stellenanzeigen arbeiten.
|
||||
|
||||
## Wann diese Modi nutzen?
|
||||
|
||||
Verwende `modes/de/`, wenn mindestens eine der folgenden Bedingungen zutrifft:
|
||||
|
||||
- Du bewirbst dich vor allem auf **deutschsprachige Stellenanzeigen** (StepStone, XING, kununu, Bundesagentur für Arbeit, deutsche Karriereseiten)
|
||||
- Deine **Lebenslauf-Sprache** ist Deutsch oder du wechselst je nach Stellenanzeige zwischen DE und EN
|
||||
- Du brauchst Antworten und Anschreiben in **natürlichem Tech-Deutsch**, nicht maschinenübersetzt
|
||||
- Du musst mit **DACH-spezifischen Vertragselementen** umgehen: 13. Monatsgehalt, Probezeit, Kündigungsfrist, AGG, Tarifvertrag, Festanstellung vs. Freelance, VWL, bAV, Arbeitszeugnisse
|
||||
|
||||
Wenn die meisten deiner Stellenanzeigen auf Englisch sind, bleib bei den Standard-Modi unter `modes/`. Die englischen Modi greifen automatisch zu deutschen Anzeigen, sobald Claude sie als deutschsprachig erkennt — aber sie kennen die DACH-Marktbesonderheiten nicht im selben Detail.
|
||||
|
||||
## Wie aktivieren?
|
||||
|
||||
career-ops hat keinen "Sprach-Schalter" als Code-Flag. Stattdessen gibt es zwei Wege:
|
||||
|
||||
### Weg 1 — Pro Session, per Befehl
|
||||
|
||||
Sag Claude zu Beginn der Session ausdrücklich:
|
||||
|
||||
> "Nutze ab jetzt die deutschen Modi unter `modes/de/`."
|
||||
|
||||
oder
|
||||
|
||||
> "Bewerten und Bewerbungen auf Deutsch — verwende `modes/de/_shared.md` und `modes/de/angebot.md`."
|
||||
|
||||
Claude liest dann die Dateien aus diesem Ordner statt aus `modes/`.
|
||||
|
||||
### Weg 2 — Dauerhaft, per Profil
|
||||
|
||||
Trage in `config/profile.yml` eine Sprach-Präferenz ein, z. B.:
|
||||
|
||||
```yaml
|
||||
language:
|
||||
primary: de
|
||||
modes_dir: modes/de
|
||||
```
|
||||
|
||||
Erinnere Claude in deiner ersten Session daran, dieses Feld zu respektieren ("Schau in `profile.yml`, ich habe `language.modes_dir` gesetzt"). Ab dann nimmt Claude automatisch die deutschen Modi.
|
||||
|
||||
> Hinweis: Das `language.modes_dir`-Feld ist eine Konvention dieser PR, kein hartcodiertes Schema. Wenn die Maintainer es anders strukturieren wollen, kann das Feld jederzeit umbenannt werden.
|
||||
|
||||
## Was ist übersetzt?
|
||||
|
||||
Diese erste Iteration deckt die vier Modi mit dem höchsten Hebel ab:
|
||||
|
||||
| Datei | Übersetzt aus | Zweck |
|
||||
|-------|---------------|-------|
|
||||
| `_shared.md` | `modes/_shared.md` (EN) | Geteilter Kontext, Archetypen, globale Regeln, DACH-Markt-Spezifika |
|
||||
| `angebot.md` | `modes/oferta.md` (ES) | Vollständige Bewertung einer einzelnen Stellenanzeige (Blöcke A-F) |
|
||||
| `bewerben.md` | `modes/apply.md` (EN) | Live-Assistent fürs Bewerbungsformular |
|
||||
| `pipeline.md` | `modes/pipeline.md` (ES) | URL-Inbox / Second Brain für gesammelte Stellenanzeigen |
|
||||
|
||||
Die übrigen Modi (`scan`, `batch`, `pdf`, `tracker`, `auto-pipeline`, `deep`, `contacto`, `ofertas`, `project`, `training`) sind absichtlich nicht in diesem PR dabei. Sie funktionieren weiter über die EN/ES-Originale, weil ihr Inhalt zu großen Teilen aus Tooling, Pfaden und Konfigurationskommandos besteht — diese sollen sprachunabhängig bleiben.
|
||||
|
||||
Wenn die Community die deutschen Modi annimmt, werden weitere Modi in einem Folge-PR übersetzt.
|
||||
|
||||
## Was bleibt englisch?
|
||||
|
||||
Bewusst nicht eingedeutscht, weil Standard-Tech-Vokabular:
|
||||
|
||||
- `cv.md`, `pipeline`, `tracker`, `report`, `score`, `archetype`, `proof point`
|
||||
- Tool-Namen (`Playwright`, `WebSearch`, `WebFetch`, `Read`, `Write`, `Edit`, `Bash`)
|
||||
- Status-Werte im Tracker (`Evaluated`, `Applied`, `Interview`, `Offer`, `Rejected`)
|
||||
- Code-Snippets, Pfade, Befehle
|
||||
|
||||
Die Modi verwenden deutsches Tech-Deutsch, wie es in echten Engineering-Teams in Berlin, München oder Zürich gesprochen wird: deutscher Fließtext, englische Fachbegriffe da, wo sie üblich sind. Keine erzwungene Eindeutschung von "Pipeline" zu "Förderband", kein "Lebenslauf-Datei" für `cv.md`.
|
||||
|
||||
## Vokabular-Spickzettel
|
||||
|
||||
Wenn du Modi anpasst oder erweiterst, halte dich an dieses Vokabular — so bleibt der Ton konsistent:
|
||||
|
||||
| Englisch | Deutsch (in dieser Codebase) |
|
||||
|----------|------------------------------|
|
||||
| Job posting | Stellenanzeige |
|
||||
| Application | Bewerbung |
|
||||
| Cover letter | Anschreiben |
|
||||
| Resume / CV | Lebenslauf |
|
||||
| Salary | Gehalt / Vergütung |
|
||||
| Compensation | Vergütung |
|
||||
| Skills | Kenntnisse / Fähigkeiten |
|
||||
| Interview | Vorstellungsgespräch |
|
||||
| Hiring manager | Personalleiter / Hiring Manager |
|
||||
| Recruiter | Recruiter (etabliertes Lehnwort) |
|
||||
| AI | KI (Künstliche Intelligenz) |
|
||||
| Requirements | Anforderungen / Voraussetzungen |
|
||||
| Career history | Werdegang / Berufserfahrung |
|
||||
| Notice period | Kündigungsfrist |
|
||||
| Probation | Probezeit |
|
||||
| Vacation | Urlaub |
|
||||
| 13th month salary | 13. Monatsgehalt / Weihnachtsgeld |
|
||||
| Permanent employment | Festanstellung |
|
||||
| Freelance | Freelance / freie Mitarbeit |
|
||||
| Collective agreement | Tarifvertrag |
|
||||
| Anti-discrimination law | AGG (Allgemeines Gleichbehandlungsgesetz) |
|
||||
| Works council | Betriebsrat |
|
||||
| Reference letter | Arbeitszeugnis |
|
||||
| Pension scheme | Betriebliche Altersvorsorge (bAV) |
|
||||
| Capital formation benefit | Vermögenswirksame Leistungen (VWL) |
|
||||
|
||||
## Beitragen
|
||||
|
||||
Wenn du eine Übersetzung verbessern oder einen weiteren Modus eindeutschen willst:
|
||||
|
||||
1. Öffne ein Issue mit dem Vorschlag (laut `CONTRIBUTING.md`)
|
||||
2. Halte dich an das Vokabular oben, um den Ton konsistent zu halten
|
||||
3. Übersetze sinngemäß und idiomatisch — keine wörtlichen Wort-für-Wort-Übersetzungen
|
||||
4. Behalte die strukturellen Elemente (Block A-F, Tabellen, Code-Blöcke, Tool-Anweisungen) exakt bei
|
||||
5. Teste mit einer echten deutschen Stellenanzeige (z. B. von StepStone oder XING), bevor du den PR aufmachst
|
||||
@@ -0,0 +1,201 @@
|
||||
# Geteilter Kontext -- career-ops (Deutsch)
|
||||
|
||||
<!-- ============================================================
|
||||
ANPASSEN DIESER DATEI
|
||||
============================================================
|
||||
Diese Datei enthält den geteilten Kontext für alle career-ops-Modi
|
||||
in der deutschen Variante. Bevor du career-ops verwendest, MUSST du:
|
||||
1. config/profile.yml mit deinen persönlichen Daten ausfüllen
|
||||
2. cv.md im Projekt-Root anlegen (Lebenslauf in Markdown)
|
||||
3. (Optional) article-digest.md mit deinen Proof Points anlegen
|
||||
4. Die mit [ANPASSEN] markierten Abschnitte unten anpassen
|
||||
============================================================ -->
|
||||
|
||||
## Quellen der Wahrheit (IMMER vor jeder Bewertung lesen)
|
||||
|
||||
| Datei | Pfad | Wann |
|
||||
|-------|------|------|
|
||||
| cv.md | `cv.md` (Projekt-Root) | IMMER |
|
||||
| article-digest.md | `article-digest.md` (falls vorhanden) | IMMER (detaillierte Proof Points) |
|
||||
| profile.yml | `config/profile.yml` | IMMER (Identität und Zielrollen) |
|
||||
|
||||
**REGEL: Niemals Kennzahlen aus Proof Points hartcodieren.** Lies sie zur Bewertungszeit aus `cv.md` und `article-digest.md`.
|
||||
**REGEL: Bei Kennzahlen zu Artikeln/Projekten hat `article-digest.md` Vorrang vor `cv.md`** (in `cv.md` können ältere Zahlen stehen).
|
||||
|
||||
---
|
||||
|
||||
## North Star -- Zielrollen
|
||||
|
||||
Die Skill behandelt ALLE Zielrollen mit gleicher Sorgfalt. Keine ist primär oder sekundär — jede ist ein Erfolg, sofern Vergütung und Entwicklungsperspektive stimmen:
|
||||
|
||||
| Archetyp | Thematische Achsen | Was gekauft wird |
|
||||
|----------|--------------------|------------------|
|
||||
| **AI Platform / LLMOps Engineer** | Evaluation, Observability, Zuverlässigkeit, Pipelines | Jemand, der KI mit Metriken in Produktion bringt |
|
||||
| **Agentic Workflows / Automation** | HITL, Tooling, Orchestrierung, Multi-Agent | Jemand, der zuverlässige Agentensysteme baut |
|
||||
| **Technical AI Product Manager** | GenAI/Agents, PRDs, Discovery, Delivery | Jemand, der Business in KI-Produkte übersetzt |
|
||||
| **AI Solutions Architect** | Hyperautomation, Enterprise, Integrationen | Jemand, der End-to-End-KI-Architekturen entwirft |
|
||||
| **AI Forward Deployed Engineer** | Kundennah, schnelle Lieferung, Prototyping | Jemand, der KI-Lösungen schnell beim Kunden ausrollt |
|
||||
| **AI Transformation Lead** | Change Management, Adoption, organisatorisches Enablement | Jemand, der KI-Transformation in Organisationen führt |
|
||||
|
||||
<!-- [ANPASSEN] Passe die Archetypen oben an deine Zielrollen an.
|
||||
Beispiel für Backend-Engineering:
|
||||
- Senior Backend Engineer
|
||||
- Staff Platform Engineer
|
||||
- Engineering Manager
|
||||
etc. -->
|
||||
|
||||
### Adaptives Framing nach Archetyp
|
||||
|
||||
> **Konkrete Kennzahlen: zur Bewertungszeit aus `cv.md` und `article-digest.md` lesen. NIEMALS hier hartcodieren.**
|
||||
|
||||
| Wenn die Rolle ist... | Beim Kandidaten betonen... | Quellen für Proof Points |
|
||||
|-----------------------|----------------------------|--------------------------|
|
||||
| Platform / LLMOps | Production-Erfahrung, Observability, Evals, Closed-Loop | article-digest.md + cv.md |
|
||||
| Agentic / Automation | Multi-Agent-Orchestrierung, HITL, Zuverlässigkeit, Kosten | article-digest.md + cv.md |
|
||||
| Technical AI PM | Product Discovery, PRDs, Metriken, Stakeholder-Management | cv.md + article-digest.md |
|
||||
| Solutions Architect | Systemdesign, Integrationen, Enterprise-tauglich | article-digest.md + cv.md |
|
||||
| Forward Deployed Engineer | Schnelle Lieferung, kundennah, Prototyp bis Produktion | cv.md + article-digest.md |
|
||||
| AI Transformation Lead | Change Management, Team-Enablement, Adoption | cv.md + article-digest.md |
|
||||
|
||||
<!-- [ANPASSEN] Ordne deine konkreten Projekte/Artikel den Archetypen oben zu -->
|
||||
|
||||
### Exit-Narrativ (in ALLEN Framings nutzen)
|
||||
|
||||
<!-- [ANPASSEN] Ersetze durch dein eigenes Narrativ. Beispiele:
|
||||
- "Eigene SaaS nach 5 Jahren aufgebaut und verkauft. Jetzt voller Fokus auf angewandte KI im Enterprise."
|
||||
- "Engineering-Lead in einer Series-B während 10x-Wachstum. Suche jetzt die nächste Herausforderung."
|
||||
- "Wechsel von Beratung zu Produktentwicklung. Suche Rollen mit hoher Verantwortung."
|
||||
Wird gelesen aus config/profile.yml → narrative.exit_story -->
|
||||
|
||||
Verwende das Exit-Narrativ aus `config/profile.yml`, um ALLE Inhalte zu rahmen:
|
||||
- **In PDF-Summaries:** Brücke von der Vergangenheit in die Zukunft schlagen — "Wende dieselben [Skills] jetzt auf [JD-Domain] an."
|
||||
- **In STAR-Stories:** Auf Proof Points aus `article-digest.md` referenzieren.
|
||||
- **In Draft-Antworten (Block G):** Das Übergangs-Narrativ gehört in die erste Antwort.
|
||||
- **Wenn die Stellenanzeige nach "unternehmerisch", "Eigenverantwortung", "Builder", "End-to-End" fragt:** Das ist DAS Differenzierungsmerkmal Nr. 1. Match-Gewicht erhöhen.
|
||||
|
||||
### Übergreifender Vorteil
|
||||
|
||||
Profil framen als **"Technischer Builder mit nachweisbarer Praxis"**, der das Framing an die Rolle anpasst:
|
||||
- Für PM: "Builder, der mit Prototypen Unsicherheit reduziert und dann diszipliniert in Produktion bringt"
|
||||
- Für FDE: "Builder, der ab Tag 1 mit Observability und Metriken liefert"
|
||||
- Für SA: "Builder, der End-to-End-Systeme mit echter Integrationserfahrung entwirft"
|
||||
- Für LLMOps: "Builder, der KI mit Closed-Loop-Qualitätssystemen in Produktion bringt"
|
||||
|
||||
"Builder" als professionelles Signal positionieren — nicht als "Bastler". Reale Proof Points machen das glaubwürdig.
|
||||
|
||||
### Portfolio als Proof Point (bei wertvollen Bewerbungen einsetzen)
|
||||
|
||||
<!-- [ANPASSEN] Wenn du eine Live-Demo, ein Dashboard oder ein öffentliches Projekt hast, hier konfigurieren.
|
||||
Beispiel:
|
||||
dashboard:
|
||||
url: "https://deinedomain.dev/demo"
|
||||
password: "demo-2026"
|
||||
when_to_share: "LLMOps, AI-Platform, Observability-Rollen"
|
||||
Wird gelesen aus config/profile.yml → narrative.proof_points und narrative.dashboard -->
|
||||
|
||||
Wenn der Kandidat eine Live-Demo / ein Dashboard hat (`profile.yml` prüfen), in passenden Bewerbungen den Zugang anbieten.
|
||||
|
||||
### Vergütungsintelligenz (Comp Intelligence)
|
||||
|
||||
<!-- [ANPASSEN] Recherchiere Vergütungsspannen für deine Zielrollen und passe die Werte an -->
|
||||
|
||||
**Allgemeine Hinweise:**
|
||||
- WebSearch für aktuelle Marktdaten (Glassdoor, Levels.fyi, Kununu, Gehalt.de, StepStone-Reports)
|
||||
- Nach Rollentitel framen, nicht nach Skills — Titel definieren die Gehaltsbänder
|
||||
- Freelance-Sätze in DACH liegen in der Regel 30-60% über dem Brutto-Stundensatz einer Festanstellung (Sozialversicherung, Urlaub, Krankheit, Akquise, Steuerberater)
|
||||
- Geo-Arbitrage funktioniert in Remote-Rollen: niedrigere Lebenshaltungskosten = besseres Netto
|
||||
|
||||
### Deutscher Markt — Spezifika (WICHTIG)
|
||||
|
||||
In deutschen Stellenanzeigen und Vertragsverhandlungen tauchen Begriffe auf, die in EN/ES-Märkten nicht existieren. Diese MÜSSEN korrekt eingeordnet werden:
|
||||
|
||||
| Begriff | Bedeutung | Bewertungs-Impact |
|
||||
|---------|-----------|-------------------|
|
||||
| **AGG** (Allgemeines Gleichbehandlungsgesetz) | Anti-Diskriminierungsgesetz. Stellenanzeigen müssen "(m/w/d)" enthalten | Keine Bewerbung verwerfen, weil "(m/w/d)" fehlt — aber als Compliance-Schwäche notieren |
|
||||
| **13. Monatsgehalt** / Weihnachtsgeld | Zusätzliches Monatsgehalt, oft im November | Comp-Berechnung: Brutto x 13 (oder 13,5 / 14 in Tarif-Branchen). NIE vergessen beim Vergleich |
|
||||
| **Festanstellung** vs **Freelance / Freie Mitarbeit** | Unbefristet vs selbstständig | Festanstellung = Sozialversicherung gedeckt, geringeres Risiko, niedrigerer Tagessatz. Freelance = höherer Satz, Scheinselbstständigkeits-Risiko prüfen |
|
||||
| **Probezeit** | Übliche 6 Monate, verkürzte Kündigungsfrist (2 Wochen) | Kein Risiko-Flag — ist Marktstandard. Nur flaggen wenn > 6 Monate |
|
||||
| **Kündigungsfrist** | Gesetzliche Frist nach Probezeit, oft 1-3 Monate | Bei Vertragswechsel relevant: Startdatum entsprechend planen |
|
||||
| **Urlaub** | 25-30 Tage Standard (gesetzlich min. 20 bei 5-Tage-Woche) | < 28 Tage = unter Marktstandard für Tech. Verhandelbar |
|
||||
| **Tarifvertrag** / TVöD / IG Metall | Kollektive Vergütungsregeln | In Tarif-Unternehmen ist Verhandlungsspielraum kleiner — dafür höhere Sicherheit, fixe Steigerungen |
|
||||
| **Betriebsrat** | Mitarbeitervertretung | Stark im Mittelstand und Konzernen. Mitsprache bei Kündigung, Arbeitszeit. Pluspunkt für Stabilität |
|
||||
| **Bewerbungsmappe** | Anschreiben + Lebenslauf + Zeugnisse | Im DACH-Raum oft erwartet, anders als in EN-Märkten. Zeugnisse ggf. nachreichen |
|
||||
| **Arbeitszeugnis** | Strukturiertes Referenzdokument vom Ex-Arbeitgeber | Klassischer DACH-Standard, eigene Codesprache |
|
||||
| **VWL** (Vermögenswirksame Leistungen) | Arbeitgeberzuschuss zum Vermögensaufbau | Kleinbetrag (oft 40 €/Monat), aber als Benefit zählen |
|
||||
| **bAV** (Betriebliche Altersvorsorge) | Betriebsrente | Bei Comp-Vergleich beachten — kann mehrere hundert Euro monatlich sein |
|
||||
|
||||
### Verhandlungs-Skripte (Negotiation)
|
||||
|
||||
<!-- [ANPASSEN] Auf deine Situation zuschneiden -->
|
||||
|
||||
**Gehaltsvorstellung (allgemeines Framework):**
|
||||
> "Auf Basis aktueller Marktdaten für diese Rolle peile ich [SPANNE aus profile.yml] an. Bei der Struktur bin ich flexibel — entscheidend sind das Gesamtpaket und die Entwicklungsperspektive."
|
||||
|
||||
**Pushback bei Geo-Diskount:**
|
||||
> "Die Rollen, in denen ich konkurriere, sind ergebnisorientiert, nicht ortsabhängig. Mein Track Record ändert sich nicht mit der Postleitzahl."
|
||||
|
||||
**Wenn das Angebot unter dem Zielwert liegt:**
|
||||
> "Ich vergleiche aktuell mit Angeboten im Bereich [höhere Spanne]. [Firma] reizt mich wegen [Grund]. Lässt sich [Zielwert] gemeinsam erreichen?"
|
||||
|
||||
**Bei Verhandlung über das 13. Gehalt / Bonus:**
|
||||
> "Mir ist wichtig, das Gesamtpaket zu vergleichen. Können wir das fixe Bruttogehalt, das 13. Monatsgehalt und einen variablen Anteil getrennt aufschlüsseln?"
|
||||
|
||||
### Standort-Politik (Location Policy)
|
||||
|
||||
<!-- [ANPASSEN] An deine Situation anpassen. Wird gelesen aus config/profile.yml → location -->
|
||||
|
||||
**In Formularen:**
|
||||
- Binäre "Können Sie vor Ort sein?"-Fragen: nach tatsächlicher Verfügbarkeit aus `profile.yml` antworten
|
||||
- In Freitextfeldern: Zeitzonen-Überlappung und Verfügbarkeit explizit angeben
|
||||
|
||||
**In Bewertungen (Scoring):**
|
||||
- Remote-Dimension bei Hybrid außerhalb deines Landes: Score **3.0** (nicht 1.0)
|
||||
- Score 1.0 nur, wenn die Stellenanzeige explizit sagt "muss 4-5 Tage/Woche vor Ort, keine Ausnahmen"
|
||||
|
||||
### Time-to-Offer-Priorität
|
||||
- Funktionierende Demo + Metriken > Perfektion
|
||||
- Schneller bewerben > mehr lernen
|
||||
- 80/20-Ansatz, alles zeitlich begrenzen
|
||||
|
||||
---
|
||||
|
||||
## Globale Regeln
|
||||
|
||||
### NIEMALS
|
||||
|
||||
1. Erfahrung oder Kennzahlen erfinden
|
||||
2. `cv.md` oder Portfolio-Dateien verändern
|
||||
3. Bewerbungen im Namen des Kandidaten absenden
|
||||
4. Telefonnummer in generierten Nachrichten teilen
|
||||
5. Vergütung unter Marktniveau empfehlen
|
||||
6. PDF generieren, ohne vorher die Stellenanzeige gelesen zu haben
|
||||
7. Marketing-Floskeln oder "Corporate-Sprech" verwenden
|
||||
8. Den Tracker ignorieren (jede bewertete Stellenanzeige wird eingetragen)
|
||||
|
||||
### IMMER
|
||||
|
||||
0. **Anschreiben:** Wenn das Formular die Möglichkeit bietet, ein Anschreiben anzuhängen oder zu schreiben, IMMER eines mitliefern. PDF im selben visuellen Design wie der Lebenslauf erzeugen. Inhalt: Zitate aus der Stellenanzeige, gemappt auf Proof Points, Links zu relevanten Case Studies. Maximal 1 Seite.
|
||||
1. `cv.md` und `article-digest.md` (falls vorhanden) lesen, bevor irgendeine Stellenanzeige bewertet wird
|
||||
1b. **Bei der ersten Bewertung jeder Session:** `node cv-sync-check.mjs` per Bash ausführen. Bei Warnungen den Kandidaten informieren, bevor weitergearbeitet wird
|
||||
2. Den Rollen-Archetyp erkennen und das Framing anpassen
|
||||
3. Beim Matching exakte Zeilen aus dem Lebenslauf zitieren
|
||||
4. WebSearch für Vergütungs- und Firmendaten nutzen
|
||||
5. Nach jeder Bewertung im Tracker eintragen
|
||||
6. Inhalte in der Sprache der Stellenanzeige erzeugen (Deutsch, wenn die Anzeige deutsch ist; Englisch sonst)
|
||||
7. Direkt und konkret sein — keine Floskeln
|
||||
8. Beim Erzeugen deutscher Texte (PDF-Summaries, Bullets, LinkedIn-Nachrichten, STAR-Stories): natürliches Tech-Deutsch, keine wörtliche Übersetzung. Kurze Sätze, aktive Verben, Passiv vermeiden. Fachbegriffe (Stack, Pipeline, Deployment, Embedding) nicht zwanghaft eindeutschen
|
||||
8b. **Case-Study-URLs in der PDF Professional Summary:** Wenn das PDF Case Studies oder Demos erwähnt, MÜSSEN die URLs schon im ersten Absatz (Professional Summary) auftauchen. Recruiter lesen oft nur die Summary. Alle URLs im HTML mit `white-space: nowrap`
|
||||
9. **Tracker-Einträge als TSV** — `applications.md` NIEMALS direkt für neue Einträge editieren. TSV in `batch/tracker-additions/` schreiben, `merge-tracker.mjs` übernimmt das Mergen
|
||||
10. **`**URL:**` in jedem Report-Header** — zwischen Score und PDF
|
||||
|
||||
### Tools
|
||||
|
||||
| Tool | Einsatz |
|
||||
|------|---------|
|
||||
| WebSearch | Vergütungs-Recherche, Trends, Unternehmenskultur, LinkedIn-Kontakte, Fallback für Stellenanzeigen |
|
||||
| WebFetch | Fallback, um Stellenanzeigen aus statischen Seiten zu extrahieren |
|
||||
| Playwright | Prüfen, ob Stellenanzeigen noch aktiv sind (browser_navigate + browser_snapshot), Stellenanzeigen aus SPAs extrahieren. **KRITISCH: NIEMALS 2+ Agenten parallel mit Playwright starten — sie teilen sich eine Browser-Instanz** |
|
||||
| Read | cv.md, article-digest.md, cv-template.html |
|
||||
| Write | Temporäres HTML für PDF, applications.md, Reports .md |
|
||||
| Edit | Tracker aktualisieren |
|
||||
| Bash | `node generate-pdf.mjs` |
|
||||
@@ -0,0 +1,165 @@
|
||||
# Modus: angebot — Vollständige Bewertung A-F
|
||||
|
||||
Wenn der Kandidat eine Stellenanzeige einfügt (Text oder URL), IMMER alle 6 Blöcke liefern.
|
||||
|
||||
## Schritt 0 — Archetyp-Erkennung
|
||||
|
||||
Die Stellenanzeige einem der 6 Archetypen zuordnen (siehe `_shared.md`). Bei Hybriden die zwei nächstliegenden angeben. Daraus folgt:
|
||||
- Welche Proof Points in Block B Vorrang haben
|
||||
- Wie das Summary in Block E umgeschrieben wird
|
||||
- Welche STAR-Stories in Block F vorbereitet werden
|
||||
|
||||
## Block A — Rollen-Zusammenfassung
|
||||
|
||||
Tabelle mit:
|
||||
- Erkannter Archetyp
|
||||
- Domain (Platform / Agentic / LLMOps / ML / Enterprise)
|
||||
- Funktion (Build / Consult / Manage / Deploy)
|
||||
- Seniorität
|
||||
- Remote (Vollremote / Hybrid / Vor Ort)
|
||||
- Teamgröße (falls erwähnt)
|
||||
- TL;DR in einem Satz
|
||||
|
||||
## Block B — Match mit dem Lebenslauf
|
||||
|
||||
`cv.md` lesen. Tabelle erstellen, in der jede Anforderung aus der Stellenanzeige auf exakte Zeilen aus dem Lebenslauf gemappt wird.
|
||||
|
||||
**Angepasst an den Archetyp:**
|
||||
- FDE → Proof Points zu schneller Lieferung und Kundennähe priorisieren
|
||||
- SA → Systemdesign und Integrationen priorisieren
|
||||
- PM → Product Discovery und Metriken priorisieren
|
||||
- LLMOps → Evals, Observability, Pipelines priorisieren
|
||||
- Agentic → Multi-Agent, HITL, Orchestrierung priorisieren
|
||||
- Transformation → Change Management, Adoption, Skalierung priorisieren
|
||||
|
||||
Abschnitt **Lücken (Gaps)** mit Mitigationsstrategie für jede einzelne. Pro Gap:
|
||||
1. Ist das ein Hard Blocker oder ein Nice-to-have?
|
||||
2. Kann der Kandidat angrenzende Erfahrung nachweisen?
|
||||
3. Gibt es ein Portfolio-Projekt, das diesen Gap abdeckt?
|
||||
4. Konkreter Mitigationsplan (Satz fürs Anschreiben, schnelles Mini-Projekt, etc.)
|
||||
|
||||
## Block C — Level und Strategie
|
||||
|
||||
1. **Erkanntes Level** in der Stellenanzeige vs **natürliches Level des Kandidaten für diesen Archetyp**
|
||||
2. **Plan "Senior verkaufen, ohne zu lügen"**: konkrete Formulierungen, an den Archetyp angepasst, hervorzuhebende Erfolge, wie Founder-Erfahrung als Vorteil positioniert wird
|
||||
3. **Plan "Wenn ich downgelevelt werde"**: akzeptieren, wenn die Vergütung fair ist; Review nach 6 Monaten verhandeln; klare Beförderungskriterien festlegen
|
||||
|
||||
## Block D — Vergütung und Nachfrage
|
||||
|
||||
WebSearch nutzen für:
|
||||
- Aktuelle Gehälter für die Rolle (Glassdoor, Levels.fyi, Kununu, Gehalt.de, StepStone-Reports)
|
||||
- Vergütungs-Reputation des Unternehmens (Kununu, Glassdoor)
|
||||
- Nachfrage-Trend für die Rolle im DACH-Markt
|
||||
|
||||
Tabelle mit Daten und zitierten Quellen. Wenn keine Daten gefunden werden, das offen sagen — nichts erfinden.
|
||||
|
||||
**Deutscher Markt — Pflichtchecks:**
|
||||
- 13. Monatsgehalt / Weihnachtsgeld erwähnt? In die Brutto-Berechnung einrechnen.
|
||||
- Variable Anteile (Bonus, Provision, RSUs / VSOP)?
|
||||
- VWL und bAV erwähnt?
|
||||
- Tarifvertrag (TVöD, IG Metall) im Spiel? Wenn ja, Verhandlungsspielraum kleiner — dafür mehr Sicherheit.
|
||||
- Festanstellung oder Freelance? Bei Freelance: Tagessatz, Scheinselbstständigkeits-Risiko.
|
||||
|
||||
## Block E — Personalisierungs-Plan
|
||||
|
||||
| # | Abschnitt | Aktueller Stand | Vorgeschlagene Änderung | Begründung |
|
||||
|---|-----------|-----------------|-------------------------|------------|
|
||||
| 1 | Summary | ... | ... | ... |
|
||||
| ... | ... | ... | ... | ... |
|
||||
|
||||
Top 5 Änderungen am Lebenslauf + Top 5 Änderungen am LinkedIn-Profil, um den Match zu maximieren.
|
||||
|
||||
## Block F — Vorstellungsgesprächs-Plan
|
||||
|
||||
6-10 STAR+R-Stories, gemappt auf Anforderungen der Stellenanzeige (STAR + **Reflection**):
|
||||
|
||||
| # | JD-Anforderung | STAR+R-Story | S | T | A | R | Reflection |
|
||||
|---|----------------|--------------|---|---|---|---|------------|
|
||||
|
||||
Die Spalte **Reflection** erfasst, was gelernt wurde oder was man heute anders machen würde. Das signalisiert Seniorität — Junior-Kandidaten beschreiben, was passiert ist; Senior-Kandidaten ziehen Lehren daraus.
|
||||
|
||||
**Story Bank:** Wenn `interview-prep/story-bank.md` existiert, prüfen, ob die Stories schon dort stehen. Falls nicht, neue ergänzen. Mit der Zeit entsteht so eine wiederverwendbare Bank von 5-10 Master-Stories, die sich an jede Frage im Vorstellungsgespräch anpassen lassen.
|
||||
|
||||
**Ausgewählt und an den Archetyp angepasst:**
|
||||
- FDE → Lieferungs-Tempo und Kundennähe betonen
|
||||
- SA → Architektur-Entscheidungen betonen
|
||||
- PM → Discovery und Trade-offs betonen
|
||||
- LLMOps → Metriken, Evals, Production-Hardening betonen
|
||||
- Agentic → Orchestrierung, Error Handling, HITL betonen
|
||||
- Transformation → Adoption und organisatorischen Wandel betonen
|
||||
|
||||
Außerdem aufnehmen:
|
||||
- 1 empfohlene Case Study (welches Projekt vorgestellt wird und wie)
|
||||
- Red-Flag-Fragen und wie man darauf antwortet (z. B. "Warum haben Sie Ihre Firma verkauft?", "Hatten Sie ein Team, das an Sie berichtet hat?", "Warum ein Wechsel nach so kurzer Zeit?")
|
||||
|
||||
---
|
||||
|
||||
## Nach der Bewertung
|
||||
|
||||
**IMMER** nach den Blöcken A-F ausführen:
|
||||
|
||||
### 1. Report .md speichern
|
||||
|
||||
Die vollständige Bewertung in `reports/{###}-{company-slug}-{YYYY-MM-DD}.md` ablegen.
|
||||
|
||||
- `{###}` = nächste fortlaufende Nummer (3-stellig, mit führenden Nullen). Um diese Nummer atomar zuzuweisen und Race-Conditions zu vermeiden, MÜSSEN Sie `node reserve-report-num.mjs` ausführen, um die Nummer zu reservieren (die Ausgabe gibt `{###}` zurück), den Report schreiben und dann `node reserve-report-num.mjs --release {###}` ausführen, um den Sentinel freizugeben.
|
||||
- `{company-slug}` = Firmenname in Kleinbuchstaben, ohne Leerzeichen (Bindestriche verwenden)
|
||||
- `{YYYY-MM-DD}` = aktuelles Datum
|
||||
|
||||
**Report-Format:**
|
||||
|
||||
```markdown
|
||||
# Bewertung: {Firma} — {Rolle}
|
||||
|
||||
**Datum:** {YYYY-MM-DD}
|
||||
**Archetyp:** {erkannt}
|
||||
**Score:** {X/5}
|
||||
**URL:** {URL der Stellenanzeige}
|
||||
**PDF:** {Pfad oder ausstehend}
|
||||
|
||||
---
|
||||
|
||||
## A) Rollen-Zusammenfassung
|
||||
(vollständiger Inhalt von Block A)
|
||||
|
||||
## B) Match mit dem Lebenslauf
|
||||
(vollständiger Inhalt von Block B)
|
||||
|
||||
## C) Level und Strategie
|
||||
(vollständiger Inhalt von Block C)
|
||||
|
||||
## D) Vergütung und Nachfrage
|
||||
(vollständiger Inhalt von Block D)
|
||||
|
||||
## E) Personalisierungs-Plan
|
||||
(vollständiger Inhalt von Block E)
|
||||
|
||||
## F) Vorstellungsgesprächs-Plan
|
||||
(vollständiger Inhalt von Block F)
|
||||
|
||||
## G) Draft-Antworten für die Bewerbung
|
||||
(nur bei Score >= 4.5 — Entwürfe für die Antwortfelder im Bewerbungsformular)
|
||||
|
||||
---
|
||||
|
||||
## Extrahierte Keywords
|
||||
(Liste mit 15-20 Keywords aus der Stellenanzeige für ATS-Optimierung)
|
||||
```
|
||||
|
||||
### 2. Im Tracker eintragen
|
||||
|
||||
**IMMER** in `data/applications.md` eintragen:
|
||||
- Nächste fortlaufende Nummer
|
||||
- Aktuelles Datum
|
||||
- Firma
|
||||
- Rolle
|
||||
- Score: Match-Durchschnitt (1-5)
|
||||
- Status: `Evaluated`
|
||||
- PDF: ❌ (oder ✅, wenn Auto-Pipeline ein PDF erzeugt hat)
|
||||
- Report: relativer Link zur Report-Datei (z. B. `[001](reports/001-company-2026-01-01.md)`)
|
||||
|
||||
**Tracker-Format:**
|
||||
|
||||
```markdown
|
||||
| # | Datum | Firma | Rolle | Score | Status | PDF | Report |
|
||||
```
|
||||
@@ -0,0 +1,114 @@
|
||||
# Modus: bewerben — Live-Assistent fürs Bewerbungsformular
|
||||
|
||||
Interaktiver Modus für den Moment, in dem der Kandidat in Chrome ein Bewerbungsformular ausfüllt. Liest, was auf dem Bildschirm steht, lädt den Kontext der vorherigen Bewertung der Stellenanzeige und erzeugt passgenaue Antworten für jede Frage des Formulars.
|
||||
|
||||
## Voraussetzungen
|
||||
|
||||
- **Empfohlen mit sichtbarem Playwright**: Im sichtbaren Modus sieht der Kandidat den Browser, und Claude kann mit der Seite interagieren.
|
||||
- **Ohne Playwright**: Der Kandidat teilt einen Screenshot oder fügt die Fragen manuell ein.
|
||||
|
||||
## Workflow
|
||||
|
||||
```
|
||||
1. ERKENNEN → aktiven Chrome-Tab lesen (Screenshot / URL / Titel)
|
||||
2. IDENTIFIZIEREN → Firma + Rolle aus der Seite extrahieren
|
||||
3. SUCHEN → mit bestehenden Reports unter reports/ abgleichen
|
||||
4. LADEN → vollständigen Report lesen + Block G (falls vorhanden)
|
||||
5. VERGLEICHEN → Stimmt die Rolle auf dem Bildschirm mit der bewerteten überein? Wenn sie sich geändert hat → warnen
|
||||
6. ANALYSIEREN → ALLE sichtbaren Fragen des Formulars identifizieren
|
||||
7. ERZEUGEN → Für jede Frage eine passgenaue Antwort generieren
|
||||
8. PRÄSENTIEREN → Antworten formatiert zum Copy-Paste ausgeben
|
||||
```
|
||||
|
||||
## Schritt 1 — Stellenanzeige erkennen
|
||||
|
||||
**Mit Playwright:** Snapshot der aktiven Seite. Titel, URL und sichtbaren Inhalt lesen.
|
||||
|
||||
**Ohne Playwright:** Den Kandidaten bitten, eines der folgenden zu tun:
|
||||
- Einen Screenshot des Formulars teilen (das Read-Tool kann Bilder lesen)
|
||||
- Die Fragen des Formulars als Text einfügen
|
||||
- Firma + Rolle nennen, damit wir den Kontext suchen können
|
||||
|
||||
## Schritt 2 — Identifizieren und Kontext laden
|
||||
|
||||
1. Firmennamen und Rollentitel von der Seite extrahieren
|
||||
2. In `reports/` per Grep (case-insensitive) nach dem Firmennamen suchen
|
||||
3. Bei Treffer → vollständigen Report laden
|
||||
4. Wenn Block G vorhanden ist → die früheren Draft-Antworten als Basis laden
|
||||
5. Wenn KEIN Treffer → den Kandidaten warnen und eine schnelle Auto-Pipeline anbieten
|
||||
|
||||
## Schritt 3 — Änderungen an der Rolle erkennen
|
||||
|
||||
Wenn die Rolle auf dem Bildschirm von der bewerteten abweicht:
|
||||
- **Den Kandidaten warnen**: "Die Rolle hat sich von [X] zu [Y] geändert. Soll ich neu bewerten oder die Antworten an den neuen Titel anpassen?"
|
||||
- **Wenn anpassen**: Antworten ohne Neu-Bewertung an den neuen Titel angleichen
|
||||
- **Wenn neu bewerten**: vollständige A-F-Bewertung durchführen, Report aktualisieren, Block G neu erzeugen
|
||||
- **Tracker aktualisieren**: in `applications.md` den Rollentitel anpassen, falls nötig
|
||||
|
||||
## Schritt 4 — Fragen des Formulars analysieren
|
||||
|
||||
ALLE sichtbaren Fragen identifizieren:
|
||||
- Freitextfelder (Anschreiben, "Warum diese Rolle", Motivation, etc.)
|
||||
- Dropdowns (Wie haben Sie von uns erfahren, Arbeitserlaubnis, etc.)
|
||||
- Ja/Nein (Umzug, Visum, Verfügbarkeit, etc.)
|
||||
- Gehaltsfelder (Spanne, Gehaltsvorstellung — in Brutto-Jahresgehalt für DE)
|
||||
- Upload-Felder (Lebenslauf, Anschreiben als PDF, Zeugnisse)
|
||||
|
||||
Jede Frage klassifizieren:
|
||||
- **Bereits in Block G beantwortet** → bestehende Antwort übernehmen
|
||||
- **Neue Frage** → Antwort aus dem Report + `cv.md` generieren
|
||||
|
||||
## Schritt 5 — Antworten erzeugen
|
||||
|
||||
Für jede Frage die Antwort nach folgendem Schema bauen:
|
||||
|
||||
1. **Kontext aus dem Report**: Proof Points aus Block B, STAR-Stories aus Block F nutzen
|
||||
2. **Vorheriger Block G**: Wenn ein Draft existiert, als Basis nehmen und nachschärfen
|
||||
3. **Ton "Ich entscheide mich für euch"**: gleiches Framework wie in der Auto-Pipeline — selbstbewusst, nicht bittend
|
||||
4. **Spezifität**: etwas Konkretes aus der sichtbaren Stellenanzeige zitieren
|
||||
5. **career-ops Proof Point**: in "Zusätzliche Informationen" einbauen, falls ein solches Feld existiert
|
||||
|
||||
**Spezielle deutsche Formularfelder, die häufig auftauchen:**
|
||||
- **Gehaltsvorstellung (brutto, jährlich)** → Spanne aus `profile.yml`, in EUR, mit Hinweis "verhandelbar je nach Gesamtpaket"
|
||||
- **Eintrittsdatum / Verfügbarkeit** → Realistisches Datum unter Berücksichtigung der Kündigungsfrist (oft 1-3 Monate)
|
||||
- **Arbeitserlaubnis / Aufenthaltsstatus** → ehrlich und knapp; bei EU-Bürgern explizit "Keine Arbeitserlaubnis erforderlich (EU-Bürger:in)"
|
||||
- **Sprachkenntnisse** → Deutsch / Englisch nach GER-Niveau (A1-C2) angeben
|
||||
- **Anrede** → bei deutschen Formularen oft Pflichtfeld (Herr / Frau / Divers / Keine)
|
||||
|
||||
**Output-Format:**
|
||||
|
||||
```
|
||||
## Antworten für [Firma] — [Rolle]
|
||||
|
||||
Basis: Report #NNN | Score: X.X/5 | Archetyp: [Typ]
|
||||
|
||||
---
|
||||
|
||||
### 1. [Exakte Frage aus dem Formular]
|
||||
> [Antwort, fertig zum Kopieren]
|
||||
|
||||
### 2. [Nächste Frage]
|
||||
> [Antwort]
|
||||
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
Hinweise:
|
||||
- [Beobachtungen zur Rolle, Änderungen, etc.]
|
||||
- [Personalisierungs-Vorschläge, die der Kandidat nochmal prüfen sollte]
|
||||
```
|
||||
|
||||
## Schritt 6 — Nach dem Absenden (optional)
|
||||
|
||||
Wenn der Kandidat bestätigt, dass die Bewerbung raus ist:
|
||||
1. Status in `applications.md` von "Evaluated" auf "Applied" setzen
|
||||
2. Block G im Report mit den finalen Antworten aktualisieren
|
||||
3. Nächsten Schritt vorschlagen: `/career-ops contacto` für LinkedIn-Outreach an den Personalleiter / Hiring Manager
|
||||
|
||||
## Scroll-Handling
|
||||
|
||||
Wenn das Formular mehr Fragen hat als sichtbar:
|
||||
- Den Kandidaten bitten, zu scrollen und einen weiteren Screenshot zu teilen
|
||||
- Oder die restlichen Fragen einzufügen
|
||||
- In Iterationen verarbeiten, bis das ganze Formular abgedeckt ist
|
||||
@@ -0,0 +1,63 @@
|
||||
# Modus: pipeline — URL-Inbox (Second Brain)
|
||||
|
||||
Verarbeitet URLs von Stellenanzeigen, die in `data/pipeline.md` gesammelt wurden. Der Kandidat wirft URLs ins Inbox, wann immer er eine entdeckt, und führt später `/career-ops pipeline` aus, um sie alle in einem Rutsch zu verarbeiten.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Lesen** von `data/pipeline.md` → alle Items mit `- [ ]` im Abschnitt "Pendientes" / "Pending" / "Offen" finden
|
||||
2. **Für jede offene URL**:
|
||||
a. Die nächste fortlaufende `REPORT_NUM` atomar reservieren, indem `node reserve-report-num.mjs` ausgeführt wird (und den Sentinel mit `node reserve-report-num.mjs --release <num>` freigeben, sobald der Report geschrieben ist)
|
||||
b. **Stellenanzeige extrahieren** mit Playwright (`browser_navigate` + `browser_snapshot`) → WebFetch → WebSearch
|
||||
c. Wenn die URL nicht erreichbar ist → als `- [!]` mit Notiz markieren und weitermachen
|
||||
d. **Vollständige Auto-Pipeline ausführen**: A-F-Bewertung → Report .md → PDF (wenn Score >= 3.0) → Tracker
|
||||
e. **Von "Offen" nach "Verarbeitet" verschieben**: `- [x] #NNN | URL | Firma | Rolle | Score/5 | PDF ✅/❌`
|
||||
3. **Bei 3+ offenen URLs** Agenten parallel starten (Agent-Tool mit `run_in_background`), um Tempo zu machen.
|
||||
4. **Am Ende** eine Zusammenfassungstabelle ausgeben:
|
||||
|
||||
```
|
||||
| # | Firma | Rolle | Score | PDF | Empfohlene Aktion |
|
||||
```
|
||||
|
||||
## Format von pipeline.md
|
||||
|
||||
```markdown
|
||||
## Offen
|
||||
- [ ] https://jobs.example.com/posting/123
|
||||
- [ ] https://boards.greenhouse.io/company/jobs/456 | Company GmbH | Senior PM
|
||||
- [!] https://private.url/job — Fehler: Login erforderlich
|
||||
|
||||
## Verarbeitet
|
||||
- [x] #143 | https://jobs.example.com/posting/789 | Acme GmbH | AI PM | 4.2/5 | PDF ✅
|
||||
- [x] #144 | https://boards.greenhouse.io/xyz/jobs/012 | BigCo | SA | 2.1/5 | PDF ❌
|
||||
```
|
||||
|
||||
> Hinweis: Die Sektion-Überschriften können auf EN ("Pending"/"Processed"), ES ("Pendientes"/"Procesadas") oder DE ("Offen"/"Verarbeitet") sein. Beim Lesen flexibel sein, beim Schreiben dem Stil der bestehenden Datei treu bleiben.
|
||||
|
||||
## Intelligente Erkennung der Stellenanzeige aus der URL
|
||||
|
||||
1. **Playwright (bevorzugt):** `browser_navigate` + `browser_snapshot`. Funktioniert mit allen SPAs.
|
||||
2. **WebFetch (Fallback):** Für statische Seiten oder wenn Playwright nicht verfügbar ist.
|
||||
3. **WebSearch (letzter Ausweg):** In sekundären Portalen suchen, die die Stellenanzeige indexieren.
|
||||
|
||||
**Sonderfälle:**
|
||||
- **LinkedIn**: Kann Login erfordern → mit `[!]` markieren und den Kandidaten bitten, den Text einzufügen
|
||||
- **PDF**: Wenn die URL auf ein PDF zeigt, direkt mit dem Read-Tool lesen
|
||||
- **`local:`-Präfix**: Lokale Datei lesen. Beispiel: `local:jds/linkedin-pm-ai.md` → `jds/linkedin-pm-ai.md` lesen
|
||||
- **StepStone / XING / kununu**: Häufig deutscher Markt, oft Cookie-Banner. Playwright kann in Snapshot scrollen, um den Anzeigentext zu erfassen
|
||||
- **Bundesagentur für Arbeit (arbeitsagentur.de)**: Strukturierte Stellenanzeigen, gut maschinenlesbar. WebFetch reicht meist
|
||||
|
||||
## Automatische Nummerierung
|
||||
|
||||
1. Führen Sie `node reserve-report-num.mjs` aus, um die nächste fortlaufende Nummer atomar zu reservieren (die Ausgabe gibt `{###}` zurück).
|
||||
2. Schreiben Sie den Report mit dieser Nummer.
|
||||
3. Geben Sie den Sentinel mit `node reserve-report-num.mjs --release {###}` frei, sobald der Report geschrieben ist.
|
||||
|
||||
## Synchronisierung der Quellen
|
||||
|
||||
Vor dem Verarbeiten irgendeiner URL die Sync prüfen:
|
||||
|
||||
```bash
|
||||
node cv-sync-check.mjs
|
||||
```
|
||||
|
||||
Bei Abweichungen den Kandidaten warnen, bevor weitergearbeitet wird.
|
||||
Reference in new issue
Block a user