Un Claude Skill qui interroge un hiring manager sur un poste nouvellement ouvert et produit un draft de JD structuré, axé sur les compétences, adapté à la juridiction dans la même journée ouvrée. Le skill est livré sous la forme d’un SKILL.md plus trois fichiers de référence dans apps/web/public/artifacts/jd-writer-claude-skill/. Déposez-le dans votre répertoire de skills Claude Code, remplacez les modèles par les vrais scaffolds de votre équipe, et le skill transforme le pattern « je vais écrire la JD cette semaine » de 90 minutes en une conversation de 20 minutes qui produit un draft que le recruteur peut modifier et publier.
Quand l’utiliser
Utilisez le skill au moment où le poste est ouvert, avant tout sourcing, avant toute publication externe, avant que le recruteur n’ait passé du temps sur l’appel d’intake. La bonne forme d’input est : titre du poste plus niveau, les notes d’intake vagues du hiring manager, la juridiction cible et une à trois JDs comparables (internes ou externes) pour l’ancrage vocal. Le skill conduit un entretien en cinq à huit questions sur ces notes, mappe les réponses sur le scaffold de famille de rôle pertinent depuis references/1-role-family-templates.md, et émet un draft Markdown.
Le cas d’utilisation où le skill gagne le plus fortement : ouvrir un poste le lundi et avoir besoin d’une JD publiable le mercredi dans une juridiction de transparence salariale. La matrice de juridictions dans references/3-jurisdiction-matrix.md insère le langage verbatim de divulgation salariale, la déclaration EEO et le langage d’accommodation pour la juridiction cible ; le recruteur n’a pas à chercher NYC Local Law 32 ou California SB 1162 en cours de rédaction.
Quand NE PAS l’utiliser
Publier automatiquement une JD sans révision du recruteur. Le skill émet un draft, pas une publication. Le hiring manager et le recruteur révisent tous les deux avant qu’elle ne touche un ATS ou un site d’emploi. Les JDs rédigées par IA introduisent des erreurs subtiles — mauvais titre, mauvaise juridiction, mauvais périmètre — qui nécessitent un contrôle humain.
Postes dans des juridictions d’audit de fourchette salariale avant revue de conformité. NYC §8-1402, California SB 1162, Colorado Equal Pay Act exigent tous que la fourchette publiée reflète une estimation « de bonne foi » ; la fourchette du skill provient de l’input du manager, qui n’a pas été auditée par rapport à l’historique réel des offres. Routez le draft vers la conformité, pas vers l’API de publication.
Publications de mobilité interne. Voix différente, exigences EEO différentes, conventions de formulation du périmètre souvent différentes. Utilisez plutôt un modèle spécifique à la mobilité.
Reconductions où la JD précédente est encore exacte. Mettez à jour la date last_reviewed de la JD précédente et publiez-la. La rerédaction introduit une dérive sans bénéfice.
Postes où le hiring manager n’a pas encore décidé du périmètre. Le skill amplifie l’intake — il ne peut pas le remplacer. Si le manager ne peut pas répondre à « à quoi ressemble le succès à douze mois comme résultat mesurable », la prochaine étape est un autre appel de cadrage, pas un draft de JD.
Configuration
Placez SKILL.md et le répertoire references/ dans votre dossier de skills Claude Code, en préservant la structure.
Remplacez references/1-role-family-templates.md par les vrais scaffolds de votre équipe. Les valeurs par défaut couvrent ingénierie, ventes, marketing, ops et leadership mais utilisent des ordres de sections génériques.
Remplacez references/2-biased-language-blocklist.md par la vraie liste de blocage de votre équipe. Les valeurs par défaut s’appuient sur la recherche publique sur les biais dans les JDs (Gaucher 2011, benchmarks Textio 2023) mais chaque équipe a ses propres termes contextuels spécifiques à ajouter.
Faites réviser references/3-jurisdiction-matrix.md par le conseil juridique en matière d’emploi avant de s’appuyer sur les blocs EEO et d’accommodation verbatim — les valeurs par défaut sont un point de départ, pas un conseil juridique.
Testez sur un poste où une JD actuelle existe déjà. Comparez l’output du skill à la JD existante ; l’écart révèle ce que vos scaffolds et votre liste de blocage doivent encoder.
Ce que le skill fait réellement
Le skill exécute cinq sous-tâches dans un ordre strict, documenté dans la section Method de SKILL.md. L’étape un interroge sur les notes d’intake — cinq à huit questions de clarification ciblées couvrant le périmètre, le succès à douze mois comme résultat mesurable, le contexte d’équipe, les compétences incontournables vs souhaitables comme comportements observables, le quotidien réaliste et les aspects difficiles. Pourquoi notes-d’intake-d’abord plutôt que modèle-d’abord : commencer depuis un modèle biaise vers des responsabilités génériques, et la JD résultante ressemble à toutes les autres JDs sur LinkedIn.
L’étape deux mappe les réponses sur le scaffold de famille de rôle le plus proche. L’étape trois convertit chaque exigence en compétence ou résultat observable — « 5+ ans chez FAANG » devient « a conçu et géré des systèmes distribués à plus de 10M de requêtes par jour » ; « diplôme en informatique requis » devient « maîtrise avérée de la conception de systèmes par entretien ou portfolio, diplôme non requis ». Les exigences basées sur des credentials réduisent le pool de candidats de 40-60 % sans améliorer la qualité d’embauche, selon des études publiques de BCG et Burning Glass. Le skill refuse d’écrire « X années d’expérience requises » sans une justification de résultat spécifique.
L’étape quatre exécute un pass de détection de biais séparé sur l’ensemble du draft. Les termes de biais se regroupent dans les révisions, pas dans les premiers drafts ; la détection post-draft les attrape plus fiablement que l’auto-surveillance pendant la rédaction. L’étape cinq insère les blocs de conformité verbatim spécifiques à la juridiction.
Réalité des coûts
Par JD, le skill dépense environ 30k-60k tokens (tours d’entretien, lectures de référence, draft, pass de détection de biais, recherche de juridiction), ce qui représente environ 0,15-0,40 $ sur Sonnet 4.5 ou 0,75-2,00 $ sur Opus 4.7. Coût en temps : 15-20 minutes de temps du hiring manager lors de l’entretien, 10-15 minutes de temps d’édition du recruteur. Comparez au statu quo où le recruteur passe 60-90 minutes à rédiger depuis un appel d’intake de 30 minutes, puis reloope vers le manager pour deux cycles d’édition sur trois à cinq jours. Le skill compresse la queue de rédaction sans supprimer la révision humaine.
Le coût composé que le skill évite est en aval : une JD vague produit un pool de candidats vague, ce qui produit 2-3 tours de filtrage supplémentaires par embauche, selon les métriques du funnel de recrutement. Le coût par JD du skill est amorti sur l’ensemble du funnel, pas seulement à l’étape de rédaction.
Métriques de succès
Cycle de temps de « poste ouvert » à « JD publiée ». Statu quo sur la plupart des équipes ops : 4-7 jours calendaires. Avec le skill en place : 1-2 jours calendaires. Suivez-le dans votre ATS comme req_opened_at vers posting_published_at, filtré sur les postes où le hiring manager a réellement utilisé le skill. Métrique secondaire : ratio d’exigences incontournables vs souhaitables. Le skill plafonne les incontournables à cinq ; la métrique devrait converger vers une forme 5:N plutôt que la forme 12:0 que produisent les JDs chargées de credentials.
Alternatives
JDs rédigées manuellement par le hiring manager : variance la plus élevée. Un manager compétent produit une excellente JD ; un manager réticent produit une copie de la JD du poste précédent avec le titre changé. Le skill normalise l’output quelle que soit l’implication du manager.
Textio : détection de biais en temps réel forte, bons benchmarks, faible sur la rédaction structurelle (il édite, il ne rédige pas). Bon complément, pas un remplacement — lancez d’abord le skill, puis collez dans Textio pour un second pass de détection.
Datapeople : similaire à Textio avec un meilleur guidage sur la transparence salariale. Même pattern de complémentarité.
Prompt Claude générique sans le skill : produit des JDs génériques car la voix de marque, les scaffolds de famille de rôle, la matrice de juridictions et la liste de blocage vivent dans vos fichiers de référence, pas dans un prompt libre. Le skill est la structure qui rend l’output LLM non générique.
Points de vigilance
Les termes de biais glissent lors des éditions. Le pass de détection de biais s’exécute sur le premier draft ; si le recruteur réécrit une section, le pass doit être relancé. Protection : le skill émet un indice rerun-bias-screen comme dernière ligne de chaque output, et refuse de marquer une JD bias_checked: true sans un appel de re-détection explicite.
Les exigences incontournables irréalistes gonflent quand le manager est un expert du domaine. Les ingénieurs rédigeant des JDs d’ingénierie ont tendance à lister chaque outil qu’ils utilisent personnellement comme incontournable. Protection : le skill plafonne les incontournables à cinq et force tout ce qui dépasse dans les souhaitables, avec un remplacement explicite du manager requis pour dépasser le plafond.
Omission de la fourchette salariale dans les juridictions réglementées. Publier sans fourchette à NY, CA, CO, WA ou IL déclenche des amendes par violation. Protection : quand la juridiction correspond à la liste réglementée et que pay_range est absent, le skill remplace la section rémunération par un TODO bloquant et refuse d’émettre un statut « prêt à publier ».
Non-concordance vocale avec la marque employeur. Les valeurs par défaut génériques de Claude produisent des JDs génériques. Protection : le skill exige au moins une JD comparable dans l’input comparables et refuse de rédiger sans elle.
Gonflement de longueur. Les JDs de plus de 600 mots sont parcourues en diagonale et la qualité des embauches diminue avec la longueur. Protection : le skill cible 400 mots pour les rôles IC et 550 pour le leadership, avec un pied de page de nombre de mots qui avertit au-dessus du plafond.
Stack
Claude Code ou Claude.ai avec les Skills personnalisés activés — exécute la boucle d’entretien SKILL.md et les lectures de référence.
Votre ATS — destination de la JD publiée. Le skill émet du Markdown ; le recruteur colle dans l’ATS.
Votre référence de voix de marque employeur — au moins une JD comparable chargée dans l’input comparables à chaque exécution.
Optionnel : Textio ou Datapeople — second pass de détection de biais sur le draft avant publication.
---
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.
