Ein Claude Skill, der einen Hiring Manager über eine neu geöffnete Rolle interviewt und noch am selben Arbeitstag einen strukturierten, kompetenzbasierten, jurisdiktionsbewussten JD-Entwurf produziert. Der Skill wird als SKILL.md plus drei Referenzdateien unter apps/web/public/artifacts/jd-writer-claude-skill/ geliefert. In das Claude Code Skills-Verzeichnis ablegen, die Vorlagen durch die tatsächlichen Gerüste des Teams ersetzen — und der Skill verwandelt das 90-minütige „Ich schreibe die Stellenbeschreibung diese Woche”-Muster in ein 20-minütiges Gespräch, das einen Entwurf produziert, den der Recruiter bearbeiten und veröffentlichen kann.
Wann verwenden
Den Skill in dem Moment einsetzen, in dem die Rolle geöffnet wird — vor jeglichem Sourcing, vor jeder externen Veröffentlichung, bevor der Recruiter Zeit in den Intake-Call investiert hat. Die richtige Eingabeform: Rollentitel plus Level, die losen Intake-Notizen des Hiring Managers, die Ziel-Jurisdiktion und ein bis drei vergleichbare Stellenbeschreibungen (intern oder extern) für die Voice-Verankerung. Der Skill führt ein fünf- bis achtfragiges Interview gegen diese Notizen durch, ordnet die Antworten dem relevanten Rollenfamilien-Gerüst aus references/1-role-family-templates.md zu und gibt einen Markdown-Entwurf aus.
Der Anwendungsfall, bei dem der Skill am stärksten überzeugt: eine Rolle am Montag öffnen und bis Mittwoch in einer Gehaltstransparenz-Jurisdiktion eine postbare Stellenbeschreibung benötigen. Die Jurisdiktionsmatrix unter references/3-jurisdiction-matrix.md fügt die wörtliche Gehaltsoffenlegungssprache, die EEO-Erklärung und die Anpassungssprache für die Ziel-Jurisdiktion ein; der Recruiter muss NYC Local Law 32 oder California SB 1162 nicht mid-Draft nachschlagen.
Wann NICHT verwenden
Auto-Veröffentlichung einer Stellenbeschreibung ohne Recruiter-Review. Der Skill gibt einen Entwurf aus — keine fertige Ausschreibung. Hiring Manager und Recruiter prüfen beide, bevor die Stellenbeschreibung ein ATS oder eine Job-Börse berührt. KI-generierte Stellenbeschreibungen enthalten subtile Fehler — falscher Titel, falsche Jurisdiktion, falscher Scope — die ein Mensch abfangen muss.
Rollen in Pay-Range-Audit-Jurisdiktionen vor dem Compliance-Review. NYC §8-1402, California SB 1162, Colorado Equal Pay Act erfordern alle, dass die veröffentlichte Spanne eine „good faith”-Schätzung widerspiegelt; die Spanne des Skills stammt aus den Angaben des Managers, die noch nicht gegen die tatsächliche Offer-History geprüft wurden. Den Entwurf an Compliance weiterleiten — nicht an die Publishing-API.
Interne Mobilitätsausschreibungen. Andere Sprache, andere EEO-Anforderungen, oft andere Scope-Formulierungskonventionen. Stattdessen eine mobilitätsspezifische Vorlage verwenden.
Nachbesetzungen, bei denen die bisherige Stellenbeschreibung noch korrekt ist. Das last_reviewed-Datum der bisherigen Stellenbeschreibung aktualisieren und sie veröffentlichen. Neu zu erstellen führt zu Drift ohne Nutzen.
Rollen, bei denen der Hiring Manager den Scope noch nicht festgelegt hat. Der Skill verstärkt den Intake — er kann ihn nicht ersetzen. Kann der Manager nicht beantworten, „wie sieht Erfolg nach zwölf Monaten als messbare Outcome aus”, ist der richtige nächste Schritt ein weiteres Scoping-Call — kein JD-Entwurf.
Setup
SKILL.md und das references/-Verzeichnis in den Claude Code Skills-Ordner legen, Struktur beibehalten.
references/1-role-family-templates.md durch die tatsächlichen Gerüste des Teams ersetzen. Die Standards decken Engineering, Sales, Marketing, Ops und Leadership ab, verwenden aber generische Abschnittsreihenfolgen.
references/2-biased-language-blocklist.md durch die tatsächliche Blocklist des Teams ersetzen. Die Standards stützen sich auf öffentliche Bias-in-JD-Forschung (Gaucher 2011, Textio 2023 Benchmarks), aber jedes Team hat seine eigenen kontextspezifischen Begriffe hinzuzufügen.
references/3-jurisdiction-matrix.md von einem Arbeitsrechtsexperten prüfen lassen, bevor man sich auf die wörtlichen EEO- und Anpassungsblöcke verlässt — die Standards sind ein Ausgangspunkt, keine Rechtsberatung.
Auf einer Rolle testen, für die bereits eine aktuelle Stellenbeschreibung vorliegt. Den Output des Skills mit der bestehenden Stellenbeschreibung vergleichen; die Lücke zeigt, was die Gerüste und die Blocklist kodieren müssen.
Was der Skill tatsächlich tut
Der Skill führt fünf Unteraufgaben in strikter Reihenfolge aus, dokumentiert im Method-Abschnitt von SKILL.md. Schritt eins interviewt gegen die Intake-Notizen — fünf bis acht gezielte Klärungsfragen zu Scope, Zwölf-Monats-Erfolg als messbarem Outcome, Team-Kontext, Must-have vs. Nice-to-have-Skills als beobachtbaren Verhaltensweisen, dem realistischen Arbeitsalltag und den schwierigen Aspekten. Warum Intake-Notes-first statt Template-first: Mit einem Template zu beginnen, biasiert hin zu generischen Verantwortlichkeiten, und die resultierende Stellenbeschreibung liest sich wie jede andere Stellenbeschreibung auf LinkedIn.
Schritt zwei ordnet die Antworten dem nächstgelegenen Rollenfamilien-Gerüst zu. Schritt drei konvertiert jede Anforderung in einen beobachtbaren Skill oder Outcome — „5+ Jahre bei FAANG” wird zu „hat verteilte Systeme bei über 10M Anfragen pro Tag designed und betrieben”; „CS-Abschluss erforderlich” wird zu „nachweisbare Systems-Design-Kompetenz durch Interview oder Portfolio, Abschluss nicht erforderlich.” Anforderungen mit Credential-Fokus schrumpfen den Kandidatenpool um 40–60 % ohne die Qualität der Einstellungen zu verbessern, laut öffentlichen BCG- und Burning-Glass-Studien. Der Skill verweigert das Schreiben von „X Jahre Erfahrung erforderlich” ohne eine spezifische Outcome-Begründung.
Schritt vier führt einen separaten Bias-Screening-Durchlauf gegen den gesamten Entwurf durch. Bias-Begriffe häufen sich in Revisionen, nicht in ersten Entwürfen; Post-Draft-Screening erkennt sie zuverlässiger als During-Draft-Selbstüberwachung. Schritt fünf fügt die wörtlichen jurisdiktionsspezifischen Compliance-Blöcke ein.
Kostenrealität
Pro Stellenbeschreibung verbraucht der Skill ca. 30k–60k Tokens (Interview-Turns, Referenz-Lesevorgänge, Entwurf, Bias-Screen-Durchlauf, Jurisdiktions-Lookup), was auf Sonnet 4.5 ca. 0,15–0,40 USD oder auf Opus 4.7 ca. 0,75–2,00 USD kostet. Zeitkosten: 15–20 Minuten Hiring-Manager-Zeit im Interview, 10–15 Minuten Recruiter-Bearbeitungszeit. Vergleich zum Status quo: Der Recruiter verbringt 60–90 Minuten mit dem Erstellen aus einem 30-minütigen Intake-Call heraus, leitet dann für zwei Bearbeitungsrunden über drei bis fünf Tage zurück an den Manager. Der Skill komprimiert den Drafting-Tail, ohne die menschliche Prüfung zu entfernen.
Die zusammengesetzten Kosten, die der Skill vermeidet, sind nachgelagert: Eine vage Stellenbeschreibung produziert einen vagen Bewerberpool, was 2–3 zusätzliche Screening-Runden pro Einstellung produziert, gemäß Recruiting-Funnel-Metriken. Die Pro-JD-Kosten des Skills zahlen sich über den gesamten Funnel aus — nicht nur beim Drafting-Schritt.
Erfolgsmetrik
Zykluszeit von „Rolle geöffnet” bis „Stellenbeschreibung veröffentlicht”. Status quo bei den meisten Ops-Teams: 4–7 Kalendertage. Mit dem Skill im Einsatz: 1–2 Kalendertage. Im ATS als req_opened_at bis posting_published_at verfolgen, gefiltert auf Rollen, bei denen der Hiring Manager den Skill tatsächlich genutzt hat. Sekundärmetrik: Verhältnis von Must-have- zu Nice-to-have-Anforderungen. Der Skill begrenzt Must-haves auf fünf; die Metrik sollte auf eine 5:N-Form konvergieren statt auf die 12:0-Form, die credential-lastige Stellenbeschreibungen produzieren.
vs. Alternativen
Manuell vom Hiring Manager verfasste Stellenbeschreibungen: höchste Varianz. Ein erfahrener Manager produziert eine hervorragende Stellenbeschreibung; ein widerwilliger Manager produziert eine Kopie der Stellenbeschreibung der letzten Rolle mit geändertem Titel. Der Skill normalisiert den Output unabhängig vom Engagement des Managers.
Textio: starkes Echtzeit-Bias-Screening, gute Benchmarks, schwach beim strukturellen Drafting (es bearbeitet, es erstellt nicht). Gute Ergänzung, kein Ersatz — zuerst den Skill ausführen, dann in Textio für einen zweiten Screen einfügen.
Datapeople: ähnlich wie Textio mit stärkerer Gehaltstransparenz-Orientierung. Dasselbe Ergänzungsmuster.
Generischer Claude-Prompt ohne Skill: produziert generische Stellenbeschreibungen, weil Markensprache, Rollenfamilien-Gerüste, Jurisdiktionsmatrix und Blocklist in den Referenzdateien liegen — nicht in einem freien Prompt. Der Skill ist die Struktur, die den LLM-Output nicht-generisch macht.
Watch-outs
Bias-Begriffe schleichen sich bei Bearbeitungen wieder ein. Der Bias-Screening-Durchlauf läuft auf dem ersten Entwurf; überarbeitet der Recruiter einen Abschnitt, muss der Durchlauf erneut ausgeführt werden. Guard: Der Skill gibt als letzte Zeile jedes Outputs einen rerun-bias-screen-Hinweis aus und verweigert die Markierung einer Stellenbeschreibung als bias_checked: true ohne einen expliziten Re-Screen-Aufruf.
Unrealistische Must-haves blähen auf, wenn der Manager Domain-Experte ist. Engineers, die Engineering-Stellenbeschreibungen schreiben, neigen dazu, jedes Tool, das sie persönlich nutzen, als Must-have aufzulisten. Guard: Der Skill begrenzt Must-haves auf fünf und zwingt alles darüber hinaus in Nice-to-have, wobei das explizite Override des Managers erforderlich ist, um die Grenze zu überschreiten.
Pay-Range-Auslassung in regulierten Jurisdiktionen. Eine Veröffentlichung ohne Gehaltsband in NY, CA, CO, WA oder IL löst Bußgelder pro Verstoß aus. Guard: Wenn die Jurisdiktion der regulierten Liste entspricht und pay_range fehlt, ersetzt der Skill den Vergütungsabschnitt durch ein blockierendes TODO und verweigert die Ausgabe eines „ready-to-post”-Status.
Voice-Mismatch mit der Employer Brand. Generische Claude-Standards produzieren generische Stellenbeschreibungen. Guard: Der Skill erfordert mindestens eine vergleichbare Stellenbeschreibung im comparables-Input und verweigert das Drafting ohne sie.
Längenexplosion. Stellenbeschreibungen über 600 Wörter werden überflogen, und die Einstellungsqualität sinkt mit zunehmender Länge. Guard: Der Skill zielt auf 400 Wörter für Individual-Contributor-Rollen und 550 für Leadership-Rollen, mit einem Wortzahl-Footer, der über dem Cap warnt.
Stack
Claude Code oder Claude.ai mit aktivierten Custom Skills — führt den SKILL.md-Interview-Loop und die Referenz-Lesevorgänge aus.
Ihr ATS — Ziel für die veröffentlichte Stellenbeschreibung. Der Skill gibt Markdown aus; der Recruiter fügt es in das ATS ein.
Ihre Employer Brand-Sprachreferenz — mindestens eine vergleichbare Stellenbeschreibung, die bei jedem Lauf in den comparables-Input geladen wird.
Optional: Textio oder Datapeople — zweiter Bias-Screen auf dem Entwurf vor der Veröffentlichung.
---
name: jd-writer
description: Interview a hiring manager about a new role and produce a structured, skills-based, jurisdiction-aware job description draft ready for recruiter review. Use this skill at the moment a role is opened, before any sourcing or posting.
---
# JD writer
## When to invoke
Whenever a hiring manager has decided to open a role and you need a usable JD within the same working day. Take a role title plus level, the manager's intake notes, and the target jurisdiction as input, then produce a structured Markdown JD that a recruiter can edit and post.
Do NOT invoke this skill for:
- Auto-publishing a JD to a careers site or job board without recruiter review
- Roles that include compensation in jurisdictions that require pay-range audits (NYC §8-1402, CA SB 1162, CO Equal Pay Act) before public posting — produce the draft, but route it to compliance, not the publishing API
- Internal-mobility postings (different voice, different EEO requirements, use the mobility-template skill instead)
- Backfills where the prior JD is still accurate (just refresh the prior JD's `last_reviewed` date — don't redraft)
## Inputs
- Required: `role` — title plus level (e.g. `Senior Backend Engineer`, `Director of Marketing Operations`). Title alone is insufficient.
- Required: `intake_notes` — free-text notes from the hiring-manager intake call. The skill interviews against these, not from a blank canvas.
- Required: `jurisdiction` — primary posting jurisdiction (e.g. `US-NY`, `US-CA`, `US-CO`, `EU-DE`, `UK`). Drives the compliance footer.
- Optional: `comparables` — paths or URLs to 1-3 comparable JDs, internal or external. The skill uses these for voice and structure calibration.
- Optional: `icp_candidate` — short description of the target candidate shape (years of experience band, prior-company patterns, motion). Used to tune must-have vs nice-to-have language.
- Optional: `pay_range` — min/max in local currency. Required if `jurisdiction` matches a pay-transparency state.
- Optional: `comp_philosophy` — one paragraph on equity, bonus, benefits. Reused across roles so usually loaded once.
## Reference files
Always read the following from `references/` before drafting. They contain the user's role-family templates, biased-language blocklist, and jurisdiction matrix. Without them the draft is generic.
- `references/1-role-family-templates.md` — JD scaffolds per role family (engineering, sales, marketing, ops, leadership). Replace contents with your team's actual scaffolds.
- `references/2-biased-language-blocklist.md` — terms to flag and the neutral substitutions to suggest. Replace contents with your team's actual blocklist; the defaults are a starting point.
- `references/3-jurisdiction-matrix.md` — per-jurisdiction compliance requirements (pay disclosure, EEO statement, accommodation language, application-data restrictions). Replace contents with your team's legal-reviewed matrix.
## Method
Run these five sub-tasks in order. Do not parallelize — the bias screen must run on the actual draft, and the jurisdiction check must run on the actual compensation language.
### 1. Interview against the intake notes
Read the intake notes, then ask the hiring manager 5-8 targeted clarifying questions. Topic order: scope and ownership, success at 12 months as a measurable outcome, the team context, must-have vs nice-to-have skills articulated as observable behaviors, the realistic day-to-day, the parts of the role that are hardest. Why intake-notes-first rather than template-first: starting from the template biases toward generic responsibilities; starting from the manager's own framing surfaces what makes this role specific to this team at this moment.
### 2. Map to the role-family scaffold
Match the role to the closest scaffold in `references/1-role-family-templates.md`. Use the scaffold for section order and headers, not for content. Why a scaffold rather than a free form: recruiters and candidates skim JDs in a predictable pattern; consistent structure raises completion rate on application forms.
### 3. Draft skills-based requirements
Convert each "must have" into an observable skill or outcome statement, not a credential. "5+ years at FAANG" becomes "designed and operated distributed systems at over 10M requests per day." "CS degree required" becomes "demonstrable systems-design fluency, by interview or portfolio, degree not required." Why skills-based: credential-laden requirements shrink the candidate pool by 40-60% without raising hire quality, per public BCG and Burning Glass studies. The skill should refuse to write "X years experience required" without a specific outcome justification.
### 4. Bias-screening pass
Run the entire draft against `references/2-biased-language-blocklist.md`. Flag every match and propose a neutral substitution. Common categories: gendered terms (rockstar, ninja, aggressive), age-coded terms (digital native, recent graduate, energetic), ableist defaults (must be able to stand for 8 hours when role is desk-based), culture-fit framings that proxy for in-group preference. Why a separate pass rather than inline screening: bias terms cluster in revisions, not first drafts — post-draft screening catches them more reliably than during-draft self-monitoring.
### 5. Jurisdiction-and-compliance check
Look up the `jurisdiction` value in `references/3-jurisdiction-matrix.md`. Insert the required pay-range disclosure, EEO statement, accommodation language, and any application-data restrictions verbatim from the matrix. If the jurisdiction requires a pay range and `pay_range` was not supplied, emit a TODO block in place of the comp section and surface the missing input at the top of the output.
## Output format
```markdown
# {Role title} — {Level}
> Draft generated by jd-writer skill on {YYYY-MM-DD}. Recruiter review
> required before posting. Jurisdiction: {jurisdiction}.
## About the role
Two to three sentences on what the role does and why it matters to the
team's twelve-month plan. Names the team and the closest collaborators.
## What you'll do
- {Outcome-framed responsibility 1}
- {Outcome-framed responsibility 2}
- {Outcome-framed responsibility 3}
- {Outcome-framed responsibility 4}
- {Outcome-framed responsibility 5}
## What we're looking for — must have
- {Observable skill or outcome 1}
- {Observable skill or outcome 2}
- {Observable skill or outcome 3}
## What we're looking for — nice to have
- {Observable skill or outcome 1}
- {Observable skill or outcome 2}
## About the team
One paragraph: team mission, who the role works with day to day, what
the team is shipping in the next two quarters.
## Compensation and benefits
- Salary range: {currency min}–{currency max} (per
{jurisdiction} pay-transparency requirements)
- Equity: {band}
- Bonus: {structure}
- Benefits: {summary linking to benefits page}
- Location: {remote / hybrid / on-site} — {office locations or remote
regions}
## Equal employment opportunity
{Verbatim EEO statement from references/3-jurisdiction-matrix.md for
the target jurisdiction.}
## Accommodations
{Verbatim accommodation statement from
references/3-jurisdiction-matrix.md.}
## How to apply
Apply via {URL}. Application deadline: {date or rolling}. Expected
process: {N stages, named, with rough timing}.
```
## Watch-outs
- **Gendered or coded language slips back in during edits.** The bias-screening pass is run on the first draft; if the recruiter rewrites a section, the pass should be rerun. Guard: the skill emits a "rerun-bias-screen" hint as the last line of every output, and refuses to mark a JD `bias_checked: true` without an explicit re-screen call.
- **Unrealistic must-haves balloon when the manager is a domain expert.** Engineers writing engineering JDs tend to list every tool they personally use as a must-have. Guard: the skill caps must-haves at five and forces anything beyond that into nice-to-have, with the manager's explicit override required to exceed the cap.
- **Pay-range omission in regulated jurisdictions.** Posting without a range in NYC, CA, CO, WA, IL (eff. 2025) triggers per-violation fines. Guard: when `jurisdiction` matches the regulated list and `pay_range` is missing, the skill replaces the comp section with a blocking TODO and refuses to emit a "ready-to-post" status.
- **Voice mismatch with employer brand.** Generic Claude defaults read as generic JDs. Guard: the skill requires at least one comparable JD in `comparables` and refuses to draft without it; the comparable is used as the voice anchor, not just for structure.
- **Length creep.** Job descriptions over 600 words get skim-read; hire-quality drops as length grows. Guard: the skill targets 400 words for individual-contributor roles, 550 for leadership, and emits a word-count footer with a warning above the cap.
# Role-family JD scaffolds — TEMPLATE
> Replace the contents of this file with your team's actual scaffolds.
> The jd-writer skill reads this file on every run and uses it for
> section ORDER, not for section CONTENT — content comes from the
> hiring-manager interview. Without your real scaffolds, every JD reads
> the same.
Each scaffold lists section headers in the order recruiters expect to see them for that role family. Add or remove sections per family — the defaults below are starting points.
## Engineering (IC)
1. About the role
2. What you'll do
3. What we're looking for — must have
4. What we're looking for — nice to have
5. Tech stack you'll work with
6. About the team
7. Compensation and benefits
8. Equal employment opportunity
9. Accommodations
10. How to apply
Notes: Tech stack section sits before "About the team" because engineers skim for it first. Cap must-haves at five. Avoid version numbers (Python 3.11+) — they age the JD fast.
## Engineering (leadership: EM, director, VP)
1. About the role
2. What success looks like in 12 months
3. What you'll do
4. What we're looking for — must have
5. What we're looking for — nice to have
6. About the team and org context
7. Compensation and benefits
8. Equal employment opportunity
9. Accommodations
10. How to apply
Notes: Lead with the 12-month outcome, not the responsibilities — senior candidates evaluate on scope and mandate before tactics. "About the team" expands to org context (reports up, dotted lines, peer functions).
## Sales (IC: AE, AM, SDR)
1. About the role
2. What you'll do
3. What we're looking for — must have
4. What we're looking for — nice to have
5. Quota, comp plan, and territory
6. About the team
7. Compensation and benefits
8. Equal employment opportunity
9. Accommodations
10. How to apply
Notes: Quota and territory sit above "About the team" because they're the deciding inputs for sales candidates. Comp section then expands the OTE math.
## Marketing (IC and leadership)
1. About the role
2. What you'll do
3. What we're looking for — must have
4. What we're looking for — nice to have
5. About the team and how marketing partners with sales/product
6. Compensation and benefits
7. Equal employment opportunity
8. Accommodations
9. How to apply
Notes: Always include the cross-functional partnership context — marketing candidates evaluate the partnership shape as much as the mandate.
## Operations (RevOps, MarketingOps, SalesOps, BizOps)
1. About the role
2. What you'll do
3. The systems you'll own
4. What we're looking for — must have
5. What we're looking for — nice to have
6. About the team
7. Compensation and benefits
8. Equal employment opportunity
9. Accommodations
10. How to apply
Notes: "Systems you'll own" (Salesforce, HubSpot, Marketo, dbt, etc.) is the deciding section for ops candidates. List the actual systems, not categories.
## Cross-family rules
- Every scaffold ends with EEO + accommodations + how-to-apply, in that order. The jurisdiction-matrix file supplies the verbatim language for the first two.
- "Compensation and benefits" is always present. The jurisdiction-matrix file decides whether the pay range is mandatory.
- "What we're looking for" is always split into must-have and nice-to-have. Combining them is the single most common source of candidate-pool shrinkage.
# Biased-language blocklist — TEMPLATE
> Replace the contents of this file with your team's actual blocklist.
> The defaults below are a starting point drawn from public bias-in-JD
> research (Gaucher et al. 2011, Textio 2023 benchmarks). The jd-writer
> skill flags every match found in a draft and suggests a neutral
> substitution.
Format: each row is `term | category | suggested substitution | reason`. The skill matches case-insensitively on whole words.
## Gendered terms
| Term | Category | Substitution | Reason |
|---|---|---|---|
| rockstar | masculine-coded | high-performing | clusters in male applicants per Gaucher |
| ninja | masculine-coded | skilled practitioner | same |
| guru | masculine-coded | expert | same |
| aggressive | masculine-coded | proactive / driven | same |
| dominant | masculine-coded | leading / strong | same |
| competitive | masculine-coded | results-oriented | same |
| nurturing | feminine-coded | supportive | same |
| sympathetic | feminine-coded | empathetic | same |
| loyal | feminine-coded | committed | same |
## Age-coded terms
| Term | Category | Substitution | Reason |
|---|---|---|---|
| digital native | age-coded (young) | comfortable with web tooling | proxies for under-30 |
| recent graduate | age-coded (young) | early-career | same |
| energetic | age-coded (young) | engaged | same |
| young | age-coded (young) | early-career | direct violation in US |
| seasoned | age-coded (older) | experienced | proxies for over-50 |
| mature | age-coded (older) | experienced | same |
## Ableist defaults
| Term | Category | Substitution | Reason |
|---|---|---|---|
| must be able to stand | ableist if desk-based | remove unless physical | ADA-relevant |
| must lift X lbs | ableist if desk-based | remove unless physical | ADA-relevant |
| see clearly / hear clearly | ableist | remove unless safety-critical | ADA-relevant |
| crazy hours | ableist + culture-flag | demanding workload (with hours stated) | same |
## Culture-fit proxies
| Term | Category | Substitution | Reason |
|---|---|---|---|
| culture fit | in-group proxy | values alignment with {specific value} | well-documented bias vector |
| we work hard, play hard | in-group proxy | remove or specify hours | same |
| family | in-group proxy | team | same |
| like-minded | in-group proxy | aligned on {specific principle} | same |
| native English speaker | nationality proxy | strong professional English | direct EEOC concern in US |
## Credential-laden defaults
| Term | Category | Substitution | Reason |
|---|---|---|---|
| Ivy League | credential proxy | strong undergraduate background | proxies for class |
| top-tier university | credential proxy | strong undergraduate background | same |
| FAANG | credential proxy | experience at scale (state the scale) | proxies for in-network |
| 10+ years experience | credential proxy | demonstrated outcome at this scope | shrinks pool 40-60% |
## Override mechanism
Some terms in this list are unavoidable in some roles (e.g. "must lift 50lbs" for a warehouse role). The skill accepts an inline override of the form `<!-- jd-writer:keep "<term>" reason="<reason>" -->` placed immediately above the line. The override and reason are preserved in the final draft for recruiter review.
## Last edited
{YYYY-MM-DD}
# Jurisdiction compliance matrix — TEMPLATE
> Replace the contents of this file with your team's legal-reviewed
> matrix. The defaults below reflect public legislation as of mid-2025
> but are not legal advice and will age. The jd-writer skill reads
> this file on every run and inserts the verbatim language for the
> target jurisdiction.
For each jurisdiction, the matrix supplies four blocks: pay-disclosure rule, EEO statement (verbatim), accommodation statement (verbatim), and application-data restrictions (e.g. salary-history ban). The skill copies the verbatim blocks into the JD output without paraphrasing.
## US-NY (New York City + New York State)
- **Pay disclosure**: Required. Must include good-faith minimum and maximum annual salary range for the role. NYC Local Law 32 / NY State S9427A.
- **EEO statement**: `{Company}` is an equal opportunity employer. All qualified applicants will receive consideration for employment without regard to race, color, religion, sex, sexual orientation, gender identity or expression, national origin, age, disability, marital status, veteran status, or any other characteristic protected by federal, state, or local law.
- **Accommodation statement**: `{Company}` is committed to providing reasonable accommodations to qualified individuals with disabilities. If you require an accommodation during the application or interview process, please contact `{accommodations email}`.
- **Application-data restrictions**: Salary-history inquiries prohibited. Do not include "What is your current salary?" on application forms.
## US-CA (California)
- **Pay disclosure**: Required for employers with 15+ employees. Must include pay scale (range). SB 1162.
- **EEO statement**: as US-NY, with the addition of "or any characteristic protected under California Fair Employment and Housing Act."
- **Accommodation statement**: as US-NY.
- **Application-data restrictions**: Salary-history inquiries prohibited (Labor Code §432.3). Ban-the-box: criminal-history inquiry only after conditional offer.
## US-CO (Colorado)
- **Pay disclosure**: Required. Must include hourly or salary compensation, a general description of bonuses/commissions, and a general description of benefits. Equal Pay for Equal Work Act.
- **EEO statement**: as US-NY.
- **Accommodation statement**: as US-NY.
- **Application-data restrictions**: Salary-history inquiries prohibited.
## US-WA (Washington)
- **Pay disclosure**: Required for employers with 15+ employees. Must include wage scale or salary range, and a general description of benefits and other compensation. RCW 49.58.110.
- **EEO statement**: as US-NY.
- **Accommodation statement**: as US-NY.
- **Application-data restrictions**: Salary-history inquiries prohibited.
## US-IL (Illinois, eff. 2025)
- **Pay disclosure**: Required for employers with 15+ employees. Must include pay scale and benefits. PA 103-0539.
- **EEO statement**: as US-NY.
- **Accommodation statement**: as US-NY.
- **Application-data restrictions**: Salary-history inquiries prohibited.
## US-other (federal floor)
- **Pay disclosure**: Not required by federal law. Recommended for consistency.
- **EEO statement**: as US-NY (federal characteristics only).
- **Accommodation statement**: as US-NY.
- **Application-data restrictions**: Federal floor only. Check state and city law before posting.
## EU-DE (Germany)
- **Pay disclosure**: Not required at posting. Required on request under Entgelttransparenzgesetz for employers with 200+ employees.
- **EEO statement**: `{Company}` ist Arbeitgeber, der Chancengleichheit fördert. Wir berücksichtigen alle qualifizierten Bewerber unabhängig von Rasse, Hautfarbe, Religion, Geschlecht, sexueller Orientierung, Geschlechtsidentität, nationaler Herkunft, Alter, Behinderung, Familienstand oder Veteranenstatus.
- **Accommodation statement**: as US-NY, German equivalent.
- **Application-data restrictions**: Photo and date-of-birth on application discouraged under AGG. Do not request.
## UK
- **Pay disclosure**: Not legally required at posting (consultation ongoing). Recommended.
- **EEO statement**: `{Company}` is committed to equal opportunities and welcomes applications from all sections of the community, regardless of age, disability, gender reassignment, marriage and civil partnership, pregnancy and maternity, race, religion or belief, sex, or sexual orientation.
- **Accommodation statement**: Reasonable adjustments available on request — contact `{accommodations email}`.
- **Application-data restrictions**: GDPR / UK GDPR compliance required for any data collected.
## Regulated-jurisdictions list
These jurisdictions require pay-range disclosure. The jd-writer skill treats this list as the trigger for the "pay-range missing" guard:
- US-NY
- US-CA
- US-CO
- US-WA
- US-IL
## Last edited
{YYYY-MM-DD} — review quarterly. This matrix is a starting point, not legal advice. Have employment counsel review before relying on it for posting.
