Uma skill do Claude que entrevista o hiring manager sobre uma vaga recém-aberta e produz um rascunho de JD estruturado, baseado em competências, com conformidade jurisdicional, no mesmo dia útil. A skill é entregue como um SKILL.md mais três arquivos de referência em apps/web/public/artifacts/jd-writer-claude-skill/. Coloque-a no diretório de skills do Claude Code, substitua os templates pelos scaffolds reais da sua equipe, e a skill transforma o padrão de “vou escrever a JD essa semana” — que costuma levar 90 minutos — em uma conversa de 20 minutos que produz um rascunho que o recrutador pode editar e publicar.
Quando usar
Use a skill no momento em que a vaga é aberta — antes de qualquer sourcing, antes de qualquer publicação externa, antes de o recrutador ter gasto tempo na ligação de intake. O formato de entrada ideal é: título e nível do cargo, notas soltas de intake do hiring manager, a jurisdição-alvo e uma a três JDs comparáveis (internas ou externas) para ancorar o tom. A skill conduz uma entrevista de cinco a oito perguntas com base nessas notas, mapeia as respostas no scaffold do role-family relevante em references/1-role-family-templates.md e emite um rascunho em Markdown.
O caso de uso em que a skill se destaca mais: abrir uma vaga na segunda-feira e precisar de uma JD publicável na quarta em uma jurisdição com transparência salarial. A matriz de jurisdições em references/3-jurisdiction-matrix.md insere a linguagem exata de divulgação salarial, o texto de EEO e o texto de acomodações para a jurisdição-alvo; o recrutador não precisa consultar a NYC Local Law 32 ou a California SB 1162 no meio do rascunho.
Quando NÃO usar
Publicar uma JD automaticamente sem revisão do recrutador. A skill gera um rascunho, não uma publicação. O hiring manager e o recrutador revisam antes de qualquer envio ao ATS ou a um quadro de vagas. JDs geradas por AI introduzem erros sutis — título errado, jurisdição errada, escopo errado — que precisam de um olhar humano.
Vagas em jurisdições com auditoria de faixas salariais antes da revisão de compliance. NYC §8-1402, California SB 1162, Colorado Equal Pay Act exigem que a faixa publicada reflita uma estimativa de “boa-fé”; a faixa da skill vem do input do manager, que não foi auditado em relação ao histórico real de ofertas. Encaminhe o rascunho ao compliance, não à API de publicação.
Postagens de mobilidade interna. Tom diferente, requisitos de EEO diferentes, frequentemente convenções diferentes de enquadramento de escopo. Use um template específico de mobilidade.
Backfills em que a JD anterior ainda está correta. Atualize a data last_reviewed da JD anterior e publique-a. Redigir novamente introduz desvio sem nenhum benefício.
Vagas em que o hiring manager ainda não definiu o escopo. A skill amplifica o intake — não pode substituí-lo. Se o manager não consegue responder “como é o sucesso em doze meses como resultado mensurável”, a próxima etapa certa é outra ligação de scoping, não um rascunho de JD.
Setup
Coloque o SKILL.md e o diretório references/ na pasta de skills do Claude Code, preservando a estrutura.
Substitua references/1-role-family-templates.md pelos scaffolds reais da sua equipe. Os padrões cobrem engenharia, vendas, marketing, operações e liderança, mas usam ordens de seção genéricas.
Substitua references/2-biased-language-blocklist.md pela lista de bloqueio real da sua equipe. Os padrões se baseiam em pesquisas públicas sobre viés em JDs (Gaucher 2011, benchmarks Textio 2023), mas cada equipe tem termos específicos do contexto para adicionar.
Peça ao consultor jurídico trabalhista que revise references/3-jurisdiction-matrix.md antes de confiar nos blocos de EEO e acomodações verbatim — os padrões são um ponto de partida, não aconselhamento jurídico.
Teste em uma vaga para a qual já existe uma JD atual. Compare o output da skill com a JD existente; a diferença revela o que seus scaffolds e lista de bloqueio precisam codificar.
O que a skill realmente faz
A skill executa cinco subtarefas em ordem estrita, documentadas na seção Method do SKILL.md. O primeiro passo entrevista com base nas notas de intake — cinco a oito perguntas clarificadoras direcionadas cobrindo escopo, sucesso em doze meses como resultado mensurável, contexto da equipe, habilidades imprescindíveis versus desejáveis como comportamentos observáveis, o dia a dia realista e os pontos difíceis. Por que começar pelas notas de intake em vez de pelo template: começar pelo template cria viés em direção a responsabilidades genéricas, e a JD resultante parece igual a todas as outras JDs no LinkedIn.
O segundo passo mapeia as respostas no scaffold do role-family mais próximo. O terceiro converte cada requisito em uma habilidade ou resultado observável — “5+ anos no FAANG” vira “projetou e operou sistemas distribuídos com mais de 10M de requisições por dia”; “formação em Ciência da Computação obrigatória” vira “fluência demonstrável em design de sistemas por entrevista ou portfólio, graduação não obrigatória.” Requisitos cheios de credenciais reduzem o pool de candidatos em 40-60% sem melhorar a qualidade das contratações, segundo estudos públicos do BCG e Burning Glass. A skill se recusa a escrever “X anos de experiência obrigatórios” sem uma justificativa específica de resultado.
O quarto passo executa uma passagem de triagem de viés separada em todo o rascunho. Termos tendenciosos se agrupam em revisões, não em primeiros rascunhos; a triagem pós-rascunho os detecta com mais confiabilidade do que o auto-monitoramento durante a redação. O quinto passo insere os blocos de conformidade específicos de cada jurisdição.
Custo real
Por JD, a skill gasta aproximadamente 30k-60k tokens (turnos da entrevista, leituras de referência, rascunho, passagem de triagem de viés, consulta de jurisdição), o que custa cerca de $0,15-$0,40 no Sonnet 4.5 ou $0,75-$2,00 no Opus 4.7. Custo de tempo: 15-20 minutos do tempo do hiring manager na entrevista, 10-15 minutos de edição do recrutador. Compare com o status quo em que o recrutador gasta 60-90 minutos redigindo a partir de uma ligação de intake de 30 minutos e depois retorna ao manager para duas rodadas de edições ao longo de três a cinco dias. A skill comprime a cauda de redação sem remover a revisão humana.
O custo cumulativo que a skill evita está mais adiante: uma JD vaga produz um pool de candidatos vago, que gera 2-3 rodadas extras de triagem por contratação, de acordo com métricas de funil de recrutamento. O custo por JD da skill se paga ao longo do funil, não apenas na etapa de redação.
Métrica de sucesso
Tempo de ciclo de “vaga aberta” a “JD publicada”. Status quo na maioria das equipes de operações: 4-7 dias corridos. Com a skill em uso: 1-2 dias corridos. Acompanhe isso no seu ATS como req_opened_at para posting_published_at, filtrado por vagas em que o hiring manager realmente usou a skill. Métrica secundária: proporção de requisitos imprescindíveis para desejáveis. A skill limita os imprescindíveis em cinco; a métrica deve convergir para um formato 5:N em vez do formato 12:0 que JDs cheias de credenciais produzem.
vs alternativas
JDs escritas manualmente pelo hiring manager: maior variância. Um manager habilidoso produz uma JD excelente; um manager relutante produz uma cópia da JD do cargo anterior com o título alterado. A skill normaliza o output independentemente do engajamento do manager.
Textio: triagem de viés em tempo real sólida, bons benchmarks, fraco na redação estrutural (edita, não redige). Bom complemento, não substituto — use a skill primeiro, depois cole no Textio para uma segunda triagem.
Datapeople: similar ao Textio com orientação mais forte sobre transparência salarial. Mesmo padrão de complementaridade.
Prompt genérico do Claude sem a skill: produz JDs genéricas porque o tom da marca, os scaffolds de role-family, a matriz de jurisdições e a lista de bloqueio vivem nos seus arquivos de referência, não em um prompt livre. A skill é a estrutura que torna o output do LLM não-genérico.
Pontos de atenção
Termos tendenciosos voltam durante as edições. A passagem de triagem de viés roda no primeiro rascunho; se o recrutador reescrever uma seção, a passagem precisa ser reexecutada. Proteção: a skill emite uma dica rerun-bias-screen como última linha de cada output e se recusa a marcar uma JD como bias_checked: true sem uma chamada explícita de nova triagem.
Requisitos imprescindíveis irrealistas aumentam quando o manager é especialista no domínio. Engenheiros que escrevem JDs de engenharia tendem a listar cada ferramenta que usam pessoalmente como imprescindível. Proteção: a skill limita os imprescindíveis em cinco e força qualquer coisa além disso para desejável, com override explícito do manager necessário para exceder o limite.
Omissão da faixa salarial em jurisdições regulamentadas. Publicar sem uma faixa em NY, CA, CO, WA ou IL gera multas por violação. Proteção: quando a jurisdição corresponde à lista regulamentada e pay_range está ausente, a skill substitui a seção de remuneração por um TODO bloqueante e se recusa a emitir um status “pronto para publicar”.
Incompatibilidade de tom com a marca empregadora. Os padrões genéricos do Claude produzem JDs genéricas. Proteção: a skill requer pelo menos uma JD comparável no input comparables e se recusa a redigir sem ela.
Inchaço de tamanho. JDs com mais de 600 palavras são lidas superficialmente e a qualidade das contratações cai conforme o tamanho aumenta. Proteção: a skill mira em 400 palavras para cargos de contribuidor individual e 550 para liderança, com um rodapé de contagem de palavras que avisa acima do limite.
Stack
Claude Code ou Claude.ai com Skills personalizadas habilitadas — executa o loop de entrevista do SKILL.md e as leituras de referência.
Seu ATS — destino da JD publicada. A skill emite Markdown; o recrutador cola no ATS.
Sua referência de voz da marca empregadora — pelo menos uma JD comparável carregada no input comparables em cada execução.
Opcional: Textio ou Datapeople — segunda triagem de viés no rascunho antes da publicação.
---
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.
