Inclusive job-description review

Review a job posting on two axes and return concrete fixes, not vibes:

1. Exclusionary wording — gender-coded, age-coded, and ableist phrasing. Flag each hit and give a neutral replacement.
2. Requirement inflation — must-have lists that screen out qualified applicants. Challenge every requirement that is not essential to doing the job.

Apply BOTH axes to every posting. A JD with clean language but a 12-item must-have wall still fails; a JD with a short requirement list but "rockstar ninja" still fails.

When to use / when NOT

• USE when the user hands you a JD, job posting, careers-page blurb, or recruiting ad to review, edit, or proof before publishing.
• Do NOT use for screening candidates against a rubric, writing rejection/offer emails, or reviewing prose that is not a job posting.

Axis 1 — flag exclusionary wording, suggest a neutral swap

For each flagged term, name WHY it excludes and give a drop-in replacement. Do not just delete — replace, so the JD still reads.

Gender-coded (masculine-coded terms suppress applications from women): | Flag | Neutral replacement | |---|---| | rockstar, ninja, guru, wizard | skilled, experienced, strong | | aggressive | proactive, results-oriented | | dominant, competitive | motivated, driven-to-deliver | | fearless, kill it, crush it | confident, high-performing | | "he/his" as the default applicant | they / the candidate |

Age-coded (screens out older — or occasionally younger — applicants): | Flag | Neutral replacement | |---|---| | digital native | comfortable with modern digital tools | | young, youthful, energetic team | collaborative, fast-moving team | | recent graduate (when not a true entry pipeline) | early-career | | "no more than 5 years experience", "nearing retirement" | remove the ceiling entirely |

Ableist (excludes disabled applicants, or uses disability as a slur): | Flag | Neutral replacement | |---|---| | able-bodied | remove — describe the actual task instead | | "must stand/lift/see/hear …" when not essential | list only genuinely essential physical requirements, and add "with or without reasonable accommodation" | | sanity check | double-check, confirm | | crazy/insane hours, OCD about detail, tone-deaf | intense hours, detail-oriented, out-of-touch |

The full catalog (many more terms, all three categories) is in references/coded-terms-catalog.md — consult it when a term looks suspect but is not listed above.

Axis 2 — challenge inflated must-have requirements

Long must-have lists deter qualified applicants who self-select out unless they meet nearly every line. Cut the list to what the job actually requires.

Rules:

• Split must-have vs nice-to-have. Move anything not essential to day-one success into a clearly labeled "Preferred / nice-to-have" section.
• Challenge years-of-experience floors that exceed the role level (e.g. "7+ years" on an entry or mid role). Recommend a range or removal.
• Challenge degree requirements when skills or experience can substitute. Suggest "Bachelor's degree OR equivalent practical experience."
• Cap the must-have list. If there are more than ~6–8 hard requirements, recommend trimming; each extra line loses candidates.
• Flag redundant requirements (the same skill listed twice under different names).

Worked examples

BEFORE: "We need a coding rockstar — an aggressive, digital native who will crush it." AFTER (flag + replace): rockstar → "skilled engineer"; aggressive → "results-oriented"; digital native → "comfortable with modern tools"; crush it → "deliver strong results". Rewrite: "We need a skilled, results-oriented engineer who is comfortable with modern tools and delivers strong results."

BEFORE (requirements, entry-level analyst): "Required: Bachelor's in CS; 7+ years SQL; 7+ years Python; expert in Tableau; PhD preferred." AFTER: "7+ years" on an entry role is inflated — lower to "1–2 years or equivalent project work." Degree → "Bachelor's OR equivalent experience." Move "expert in Tableau" and "PhD" to Preferred. Net: 4 hard requirements become 2 must-haves + a preferred list.

Edge cases

• Term is genuinely essential. If a physical requirement is truly core (e.g. a commercial driver must have a valid license and adequate vision), keep it but state it as a job task, not a trait, and note accommodation where lawful.
• Already clean. If the posting has no coded terms and a lean, justified requirement list, say so — do not manufacture problems. Over-flagging is a failure too.
• Deliberately entry-level. "Recent graduate" is fine in a stated new-grad program; flag it only when it gates a general role.

Do / Don't

• DO give a concrete replacement for every flagged term, not just a deletion.
• DO apply both axes even when the user only asks about "wording."
• DON'T rewrite the whole JD's meaning or invent requirements — review, don't rebuild.
• DON'T flag neutral role words ("senior", "lead", "full-time") as coded.

Common mistakes (the base's defaults this corrects)

• Giving generic "looks good, maybe tighten it up" feedback instead of naming each coded term.
• Treating the stated requirements as fixed and never questioning inflated years/degree bars.
• Flagging language but ignoring the must-have wall (or vice-versa).