Job-description drafting

Write a job posting to a structure a recruiter can act on, not one flat maximal wall of requirements. Handed "write a JD for X", base models produce a role blurb, a bullet list of duties, and a single "Requirements" block that mixes essentials with wish-list items and pads it with inflated "5+ years" and "Bachelor's required" bars. That posting screens out qualified applicants before anyone reads a resume.

This skill drafts to four parts, in order, every time:

1. Role summary — one short paragraph: what the role is, who it reports to or works with, and the outcome it owns.
2. Responsibilities scoped to the level — day-to-day work, framed to match the named seniority (see below).
3. Must-have requirements — the short list of things a candidate genuinely cannot do the job without.
4. Nice-to-have requirements — everything that would help but is not essential, in a clearly separate labeled group.

When to use / when NOT

• USE when asked to write, draft, or create a job description, job posting, careers-page listing, or hiring ad from scratch.
• Do NOT use to review, proof, or de-bias an existing posting — that is inclusive-jd-review. Do NOT use for candidate screening, interview scorecards, or rejection/offer emails.

Scope responsibilities to the level

Match the verbs to the seniority named in the request. Do not hand a junior role leadership duties or a senior role only ticket-execution duties.

| Level | Responsibilities read as | |---|---| | Junior / entry | Execute defined tasks, learn the stack, contribute under guidance, grow toward independence. | | Mid | Own defined pieces of work end-to-end, deliver without close supervision, collaborate across a team. | | Senior | Lead projects, set technical or functional direction, mentor others, own ambiguous problems. | | Staff / principal / lead | Drive strategy across teams, set standards, multiply others' output, own the hardest problems. |

If the request gives no level, default to mid and say so.

The must-have vs nice-to-have split (the discipline)

Two labeled groups, always. Everything not essential to day-one success goes under nice-to-have.

Keep must-have lean and honest:

• Cap it. Aim for roughly 4–6 hard requirements. Each extra line loses candidates who self-select out.
• No inflated years. Set experience to the level, not above it. Entry: 0–2 yrs (or "or equivalent project work"). Mid: 2–4. Senior: 5+. Never put "7+ years" on an entry or mid role.
• No blanket degree gate. Only require a degree when the role legally or practically needs one. Otherwise write "Bachelor's degree OR equivalent practical experience," or drop it entirely.
• State skills as capabilities, not credentials. "Can write production SQL" beats "expert-level SQL certification."
• No duplicates. Do not list the same skill twice under different names.

Nice-to-have absorbs the wish list: specific tools, domain familiarity, bonus languages, "experience at a startup," advanced degrees — anything that would help but is not required.

Worked example — mid-level backend engineer

Role summary: We're hiring a Backend Engineer to build and maintain the services behind our payments platform. You'll work on a small team and own features end-to-end, from design through production.

What you'll do: Own defined services and ship them to production; collaborate with product and frontend on API design; write tested, observable code; participate in on-call and incident response.

Must-have: 2–4 years building production backend services; strong in one server-side language (e.g. Python, Go, or Java); comfortable with relational databases and SQL; can design and consume REST or gRPC APIs.

Nice-to-have: experience with payments or fintech; Kubernetes or Terraform; event streaming (Kafka); a CS degree (not required — equivalent experience is fine).

Note what did NOT happen: no "7+ years," no hard degree line, no 12-item required-skills wall. Kafka and Kubernetes went to nice-to-have, not required.

Do / Don't

• DO produce both a must-have and a nice-to-have group, clearly labeled, even if the user only says "list the requirements."
• DO push borderline items down to nice-to-have when in doubt — a shorter must-have list widens the funnel.
• DON'T inflate the experience floor above the stated level, and don't add a degree requirement the role doesn't need.
• DON'T invent responsibilities the user didn't imply; keep the summary and duties grounded in the role they described.

Common mistakes (the base's defaults this corrects)

• Emitting one flat "Requirements" list with essentials and wish-list items jumbled together.
• Padding with "5+ years" and "Bachelor's required" regardless of the role's actual level.
• Giving every level the same generic duties instead of scoping them to junior vs senior.