Verified against ChatGPT · 2026-08-08
Write a job description that matches the actual hiring bar instead of a wish list nobody meets
Turns a hiring manager's notes into a job description built around a true must-have vs. nice-to-have split, so the posting attracts candidates who can actually clear the bar instead of scaring off good ones with an inflated requirements list.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are drafting a job description for a specific open role, working from a hiring manager's raw notes rather than a generic template. Your job is to separate what this role genuinely requires on day one from what is aspirational, and to write a posting that reflects that split honestly.
ROLE AND TEAM CONTEXT
Senior Data Analyst, reporting to the Head of Growth, on a 5-person analytics team supporting a subscription SaaS product.
HIRING MANAGER'S RAW NOTES
Needs SQL, dbt experience, Python nice to have, 5+ years exp, needs to present to execs, familiar with Looker, should know statistics, MBA preferred, needs to manage a junior analyst eventually.
MUST-HAVE VS NICE-TO-HAVE SIGNAL
SQL and dbt are non-negotiable since the team's whole stack runs on it; the MBA and people-management line were the manager thinking out loud, not real requirements for this hire.
WHAT SUCCESS LOOKS LIKE AT 6 MONTHS
Owns the weekly growth metrics dashboard independently and has shipped one self-serve analysis that changed a pricing decision.
COMPENSATION AND LOCATION CONSTRAINTS
$110k-$135k base, hybrid 2 days/week in the Austin office, no remote option for this particular team.
RULES FOR BUILDING THE REQUIREMENTS LIST
Read the raw notes and separate every requirement into one of two buckets: things a candidate literally cannot do the job without, and things that are genuinely helpful but the manager would still interview someone missing them. If the notes list more than five items as "required," push back inside your output — note explicitly which of those you moved to preferred and why, rather than silently keeping an inflated list, since a bloated requirements section is the single biggest reason qualified candidates self-select out before applying. Do not invent a requirement that is not implied by the notes or the six-month success definition, and do not pad the list with generic filler like "strong communication skills" unless the notes point at a specific communication failure mode this role needs to avoid repeating.
WRITING RULES
Open with two sentences on what the person in this seat will actually own, not a company boilerplate paragraph. Write the day-to-day responsibilities as what the person does, tied to the six-month success definition, not a duty list copied from the last posting. Keep the tone specific enough that someone doing this exact job today would recognize it as their own role, not a generic version of the title. If compensation range or location policy is given, state it plainly and do not hedge around it.
WHAT NOT TO DO
Do not use gendered or age-coded language ("digital native," "young and energetic") or credential-inflation phrases ("rockstar," "ninja"). Do not list a degree requirement unless the notes explicitly require one for a licensing or regulatory reason.
OUTPUT FORMAT
1. The job description itself, ready to post, with sections for Role Summary, What You'll Own, Must-Have Requirements, Preferred Requirements, and Compensation/Location.
2. A short callout listing any requirement you moved from "must-have" in the notes to "preferred" in the output, and the one-line reason.Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
The core failure mode this prompt targets is well documented in hiring research: requisitions written by committee or lifted from an old posting accumulate requirements nobody actually needs, and candidates — particularly those from underrepresented groups, per widely cited internal hiring studies at large tech companies — will not apply unless they meet nearly all of them, while over-confident but under-qualified candidates apply anyway. Forcing the model to bucket every line from the raw notes into must-have or preferred, and to explicitly flag anything it demoted, creates an auditable trail the hiring manager can react to ("actually no, the MBA line really does matter because...") rather than a silent rewrite they have to reverse-engineer. Anchoring the requirements to a stated six-month success definition gives the model a concrete test for each requirement — would missing this actually block the person from hitting that outcome — instead of the vaguer instruction to "only include necessary requirements," which GPT-5.1 will otherwise satisfy by simply keeping the list roughly as-is and softening the language. The explicit ban on gendered and inflation language matters because these are exactly the phrases that survive default drafting since they read as enthusiastic rather than exclusionary on a first pass, and a model asked generically to "write an inclusive JD" will often only catch the most obvious slurs, not the subtler coded phrases. Naming a hard cap ("more than five" required items) gives the model a concrete threshold to push back against rather than an open-ended judgment call it can rationalize away.
What you get back
Role Summary: You'll own the growth team's core metrics infrastructure and be the first analytical voice in pricing and retention decisions... Must-Have Requirements: Advanced SQL, hands-on dbt experience, ability to present findings directly to execs. Preferred: Python, Looker familiarity, prior people-management exposure. Callout: Moved 'MBA preferred' and 'manage a junior analyst' from required to preferred/removed — neither is needed to hit the 6-month dashboard-ownership goal described.
Verified against
ChatGPT GPT-5.1 · 2026-08-08
Changelog
- 2026-08-08 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
