Job Description Writer is a Claude AI skill — requirements calibrated to what the role actually needs, not what sounds comprehensive.
You posted a senior engineer role three weeks ago. The requirements looked reasonable when you wrote them: eight years of experience, a computer science degree, proficiency in your specific stack, plus five other things that seemed important at the time. You've received 140 applications. You've screened 30. None of them feel right — technically qualified, not excited, asking salary questions in the first message. The person you were picturing when you wrote the role hasn't applied.
They saw the JD and kept scrolling. Not because they're underqualified. Because a candidate with eight years of strong engineering experience, who has built things people actually use, has learned to read job descriptions quickly. They see a requirements list that could have been generated for any engineering role at any company, with no signal about what the actual problem is or why it would be interesting to solve. They move on to the next posting — one that explains what they'd be building and why it matters — and apply there instead.
The requirements list didn't protect you. It sorted your applicant pool in the wrong direction: toward people who apply to everything that matches their credentials, and away from people who only apply when the job sounds genuinely interesting. Those are different populations, and at most stages of a startup, the second one is the only one worth hiring from.
What a Requirements List Is Actually Selecting For
A requirements list selects for two things. First, it selects for candidates who meet the requirements — which sounds useful until you realise that "meeting requirements" as listed in a generic JD correlates weakly with doing the job well and strongly with having worked somewhere long enough and credentialed enough to accumulate the right line items. Second, it selects for candidates who are currently looking — who are scrolling job boards, reading every JD, and applying to the ones where they tick the most boxes.
The best candidate for most early-stage roles is not currently scrolling job boards. They're doing a job that's interesting enough that they haven't started looking yet. They'll move for the right opportunity — one that's clearly more interesting than what they're doing — but they won't wade through a checklist to figure out if you might be that. The JD has about four seconds to convince them to read further. A requirements list fails that test reliably, because it tells them nothing about whether the work would be worth doing.
Requirements lists optimise for credential coverage and active job-seeking behaviour. Neither of those correlates with the quality of candidate most early-stage companies actually need. The filter is working — just in the wrong direction.
The degree requirement is the clearest version of this problem. At most startups, a CS degree requirement on an engineering role eliminates a significant proportion of the strongest self-taught and bootcamp-trained engineers — people who built things out of genuine interest rather than institutional trajectory, which is often exactly the profile that thrives in early-stage environments. The requirement exists because it appeared in the template, not because the hiring manager sat down and decided that a degree was necessary for this specific role at this specific company. Nobody questioned it because nobody wrote the JD from first principles.
That gap is exactly what the Job Description Writer skill for Claude was built to close.
The Three Requirements That Reliably Repel Strong Candidates
Not all requirements are equal in how much damage they do. Three categories consistently filter out the candidates most valuable to early-stage companies.
Years-of-experience requirements set to large-company norms. "5+ years of experience" for a role that genuinely needs someone who has shipped product before and can work independently means something very different depending on where those five years were spent. Five years at a 5,000-person company, executing a defined playbook, is a different preparation than three years at a 20-person company building from scratch. The years requirement selects for the former while most startup hiring managers actually need the latter. Replacing it with a capability description — "has shipped a product from 0 to users at a company smaller than 50 people" — attracts the right candidate and repels the wrong one.
Tool-specific requirements treated as non-negotiable. Listing "proficiency in HubSpot, Salesforce, Outreach, and Gong" as requirements for a sales role signals that you've confused tool familiarity with sales capability. Strong salespeople learn tools in days. The requirement filters out strong salespeople who happen to have used different tools and attracts mediocre salespeople who've used yours. For most early-stage roles, tool requirements should be framed as context — "we use X, you'll learn it quickly" — not as filters.
Generic soft skills that every candidate claims. "Strong communication skills," "ability to work independently," "collaborative team player" — every candidate reading these requirements believes they have them, which means they filter nobody and signal nothing. They take up space in the requirements section that could be used to describe something actually distinctive about what the role requires.
A requirements list that anyone could claim filters no one out — except the candidates too experienced to think a checklist is worth their time.
What Replaces the Requirements List — and Why It Works Better
The alternative to a requirements checklist isn't no requirements — it's requirements written from the actual job rather than from a template. The difference is the starting question. A checklist starts from "what qualifications should this person have?" An outcome-led description starts from "what does success in this role look like in 90 days, and what does a person need to be able to do to get there?"
That second question produces requirements that are specific to this job rather than generic to the role title. For a first sales hire at a seed-stage company, success in 90 days might mean closing the first five customers who came through the founder's network independently, building the first prospecting list from scratch, and identifying which ICP actually converts. The requirements that follow from that — "has closed without a qualified inbound pipeline before," "is comfortable with 'we don't have a sales process yet' as a starting condition," "can write their own outreach rather than waiting for marketing" — describe a specific kind of person and no other kind. Strong candidates with that background read it and apply. Everyone else reads it and correctly concludes it isn't them.
The Job Description Writer skill is built around this starting question. It asks what success looks like in the role before it asks what requirements to list — which forces the right thinking and produces a requirements section that actually describes who you need rather than who sounds appropriate for the role title.
The Pipeline Problem This Creates — and How to Diagnose It
High application volume with low signal quality. Screened candidates who technically qualify but feel flat in interviews. The person you were picturing when you wrote the role has never appeared in the pipeline. Offers accepted by people who needed more convincing than expected.
The clearest diagnostic is the gap between who you imagined when you wrote the role and who is actually applying. If the two populations feel like different people — and especially if the imagined person has never appeared at all — the JD is almost certainly the cause. That person either never saw it because the platform distribution was wrong, or saw it, read the requirements, and decided it wasn't worth their time. The second explanation is more common and easier to fix.
The fix is not to add more requirements or make the JD longer. It is to replace the requirements list with a description of the actual problem the role solves, what success looks like in the first 90 days, and what kind of person is genuinely suited to that problem at that stage. Short, honest, specific. The candidates who are right for the role read it and recognise themselves. The candidates who aren't read it and move on. That is the correct filtering behaviour — and it is the opposite of what a generic requirements list produces.
The Output That Changes Who Applies
A JD written from the Job Description Writer skill produces a requirements section that describes capability rather than credentials, outcomes rather than duties, and the honest working environment rather than aspirational culture copy. For a role at a 12-person seed company, that means something specific: the JD names the stage, names the ambiguity, and names what the person will be building — so that a candidate who thrives in that environment reads it and thinks "that's exactly the problem I want to work on," and a candidate who needs more structure reads it and correctly concludes it isn't right for them yet.
The pipeline that results from that JD is smaller and more qualified. Fewer applications, higher signal, shorter time to hire. The best early-stage candidates don't apply broadly — they apply when the job description tells them something specific enough about the role that they're confident it's worth their time. Writing that description is the work the skill does.
A requirements list that repels your best candidates isn't a minor inefficiency. It's a compounding problem: every week it runs, the people you need are applying somewhere else, and the people who don't quite fit are filling your screening calendar. The fix is not a longer list. It's a better question at the start — what does this role actually need to succeed? — and a JD that answers it honestly.
The next piece most people tackle from here is a financial model built around your actual assumptions. If you're working across the full Founder workflow, the Founder bundle covers everything in one place.
Put this to work: the Job Description Writer skill for Claude turns everything above into one guided workflow you run in a normal Claude chat. Not ready to buy? Start with a free Claude skill and see how it works first.
Related reading: The Job Description That Attracts the Hire You Actually Need