---
name: job-description-drafting
source: https://app.decimal.ai/s/job-description-drafting@1/SKILL.md
source_sha256: bd7956e31223
---

# 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.