A Claude Skill that interviews a hiring manager about a newly opened role and produces a structured, skills-based, jurisdiction-aware JD draft within the same working day. The skill ships as a SKILL.md plus three reference files at apps/web/public/artifacts/jd-writer-claude-skill/. Drop it into your Claude Code skills directory, replace the templates with your team’s actual scaffolds, and the skill turns a 90-minute “I’ll write the JD this week” pattern into a 20-minute conversation that produces a draft the recruiter can edit and post.
When to use
Use the skill at the moment the role is opened, before any sourcing, before any external posting, before the recruiter has spent time on the intake call. The right input shape is: role title plus level, the hiring manager’s loose intake notes, the target jurisdiction, and one to three comparable JDs (internal or external) for voice anchoring. The skill conducts a five-to-eight-question interview against those notes, maps the answers onto the relevant role-family scaffold from references/1-role-family-templates.md, and emits a Markdown draft.
The use case the skill wins on hardest: opening a role on Monday and needing a postable JD by Wednesday in a pay-transparency jurisdiction. The jurisdiction matrix at references/3-jurisdiction-matrix.md inserts the verbatim pay-disclosure language, EEO statement, and accommodation language for the target jurisdiction; the recruiter does not have to look up NYC Local Law 32 or California SB 1162 mid-draft.
When NOT to use
Auto-publishing a JD without recruiter review. The skill emits a draft, not a posting. The hiring manager and recruiter both review before it touches an ATS or a job board. AI-drafted JDs introduce subtle errors — wrong title, wrong jurisdiction, wrong scope — that need a human catch.
Roles in pay-range-audit jurisdictions before compliance review. NYC §8-1402, California SB 1162, Colorado Equal Pay Act all require the posted range to reflect a “good faith” estimate; the skill’s range comes from the manager’s input, which has not been audited against actual offer history. Route the draft to compliance, not to the publishing API.
Internal-mobility postings. Different voice, different EEO requirements, often different scope-framing conventions. Use a mobility-specific template instead.
Backfills where the prior JD is still accurate. Bump the prior JD’s last_reviewed date and post it. Redrafting introduces drift for no benefit.
Roles where the hiring manager has not yet decided the scope. The skill amplifies the intake — it cannot replace it. If the manager cannot answer “what does success at twelve months look like as a measurable outcome,” the right next step is another scoping call, not a JD draft.
Setup
Place SKILL.md and the references/ directory into your Claude Code skills folder, preserving structure.
Replace references/1-role-family-templates.md with your team’s actual scaffolds. The defaults cover engineering, sales, marketing, ops, and leadership but use generic section orders.
Replace references/2-biased-language-blocklist.md with your team’s actual blocklist. The defaults draw from public bias-in-JD research (Gaucher 2011, Textio 2023 benchmarks) but every team has its own context-specific terms to add.
Have employment counsel review references/3-jurisdiction-matrix.md before relying on the verbatim EEO and accommodation blocks — the defaults are a starting point, not legal advice.
Test on a role where a current JD already exists. Compare the skill’s output to the existing JD; the gap surfaces what your scaffolds and blocklist need to encode.
What the skill actually does
The skill runs five sub-tasks in strict order, documented in the Method section of SKILL.md. Step one interviews against the intake notes — five to eight targeted clarifying questions covering scope, twelve-month success as a measurable outcome, team context, must-have versus nice-to-have skills as observable behaviors, the realistic day-to-day, and the hard parts. Why intake-notes-first rather than template-first: starting from a template biases toward generic responsibilities, and the resulting JD reads like every other JD on LinkedIn.
Step two maps the answers onto the closest role-family scaffold. Step three converts every requirement into an observable skill or outcome — “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.” Credential-laden requirements shrink the candidate pool by 40-60% without raising hire quality, per public BCG and Burning Glass studies. The skill refuses to write “X years experience required” without a specific outcome justification.
Step four runs a separate bias-screening pass against the entire draft. Bias terms cluster in revisions, not first drafts; post-draft screening catches them more reliably than during-draft self-monitoring. Step five inserts the verbatim jurisdiction-specific compliance blocks.
Cost reality
Per JD, the skill spends roughly 30k-60k tokens (interview turns, reference reads, draft, bias-screen pass, jurisdiction lookup), which runs about $0.15-$0.40 on Sonnet 4.5 or $0.75-$2.00 on Opus 4.7. Time cost: 15-20 minutes of hiring-manager time in the interview, 10-15 minutes of recruiter editing time. Compare to the status quo where the recruiter spends 60-90 minutes drafting from a 30-minute intake call, then routes back to the manager for two rounds of edits over three to five days. The skill compresses the drafting tail without removing the human review.
The compounding cost the skill avoids is downstream: a vague JD produces a vague applicant pool, which produces 2-3 extra screening rounds per hire, per recruiting funnel metrics. The skill’s per-JD cost pays back across the funnel, not just at the drafting step.
Success metric
Cycle time from “role opened” to “JD posted.” Status quo on most ops teams: 4-7 calendar days. With the skill in place: 1-2 calendar days. Track this in your ATS as req_opened_at to posting_published_at, filtered to roles where the hiring manager actually used the skill. Secondary metric: ratio of must-have requirements to nice-to-have. The skill caps must-haves at five; the metric should converge on a 5:N shape rather than the 12:0 shape that credential-laden JDs produce.
vs alternatives
Manual hiring-manager-written JDs: highest variance. A skilled manager produces a great JD; a reluctant manager produces a copy of the prior role’s JD with the title changed. The skill normalizes output regardless of manager engagement.
Textio: strong real-time bias screening, good benchmarks, weak on the structural drafting (it edits, it does not draft). Good complement, not a replacement — run the skill first, then paste into Textio for a second-pass screen.
Datapeople: similar to Textio with stronger pay-transparency guidance. Same complement pattern.
Generic Claude prompt without the skill: produces generic JDs because the brand voice, role-family scaffolds, jurisdiction matrix, and blocklist live in your reference files, not in a free prompt. The skill is the structure that makes the LLM output non-generic.
Watch-outs
Bias terms slip back in during edits. The bias-screening pass runs on the first draft; if the recruiter rewrites a section, the pass needs a 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 NY, CA, CO, WA, or IL triggers per-violation fines. Guard: when the 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 produce generic JDs. Guard: the skill requires at least one comparable JD in the comparables input and refuses to draft without it.
Length creep. JDs over 600 words get skim-read and hire-quality drops as length grows. Guard: the skill targets 400 words for individual-contributor roles and 550 for leadership, with a word-count footer that warns above the cap.
Stack
Claude Code or Claude.ai with custom Skills enabled — runs the SKILL.md interview loop and reference reads.
Your ATS — destination for the posted JD. The skill emits Markdown; the recruiter pastes into the ATS.
Your employer brand voice reference — at least one comparable JD loaded into the comparables input on every run.
Optional: Textio or Datapeople — second-pass bias screen on the draft before posting.
---
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.
