These are build-and-ship jobs. So why do they demand a Computer Science degree?

---
name: rewrite-job-requirements
description: >-
  Rewrites a bloated, buzzword-heavy, or credential-gated job posting into a
  clear posting built around what the role actually needs to get done. Use this
  whenever someone shares a job description, a requirements list, a "must-haves"
  bullet list, or a JD and wants help fixing it, tightening it, or making it
  attract the right people. Trigger it even when they do not say the word
  "rewrite" - phrases like "does this job post look right?", "help me write
  requirements for this role", "why aren't we getting good candidates",
  "clean up this JD", "what should this role actually require", or pasting a
  posting with a vague ask all count. Especially use it when the posting leans
  on a degree requirement, a long laundry list of tools, or "X years of
  [buzzword]", because that is exactly the problem this skill fixes.
---

# Rewrite Job Requirements

## What this skill is for

Most job postings are written by pasting together every tool, credential, and
buzzword anyone in the room has ever heard of. The result is a wish list for a
person who does not exist, screened by an automated filter that rejects the
people who could actually do the work. The classic tells: a required degree
that has nothing to do with the daily job, "8+ years of [framework that is 6
years old]", and thirty bullet points that describe an entire department rather
than one role.

Your job is to turn that into a posting built around one question: **what does
this person actually need to accomplish, and what is real evidence they can do
it?** You strip the proxies (degree, years, tool-name bingo) and replace them
with the real thing (the problems to solve, the outcomes, and the kind of track
record that predicts success).

The guiding belief, and it is worth saying out loud to the user if it helps:
the world is changing fast enough that everyone is a bit of an amateur now. The
best hire is usually someone with a track record of learning and adapting, not
someone who collected the right credentials a decade ago. Write the posting to
find that person.

## The method

Work in this order. Do not jump straight to prose.

### 1. Figure out what the job actually is

You cannot write real requirements from a buzzword list, because the buzzword
list does not tell you what the person will do on a Tuesday. Read what the user
gave you and extract, or ask for, these things:

- The 3 to 5 problems this role exists to solve, or outcomes it owns.
- What a normal week actually looks like (what they build, decide, ship, or fix).
- Who they work with and what "good" looks like after 6 to 12 months.
- The hard constraints that are genuinely non-negotiable and why.

If the posting is all buzzwords and you cannot tell what the job is, do not
invent it. Ask the user a few pointed questions first: "What will this person
actually spend most of their time doing?" and "If they nail this role, what is
different in a year?" A short, honest set of answers beats a beautiful posting
built on guesses. Never fabricate specifics about the team, salary, stack, or
mission that the user did not give you.

### 2. Separate real requirements from proxies

A **real requirement** is something the person must be able to do on day one or
learn very fast, tied directly to the work. A **proxy** is a stand-in someone
reached for because it felt safer to filter on. Proxies are where good
candidates get thrown out by a machine before a human ever reads them.

Challenge these hard. For each one, either cut it or convert it into the real
signal underneath:

- **Degree requirements.** Unless a license or accreditation is legally
  required (nurse, PE, CPA, etc.), a degree is almost always a proxy for "can
  think, learn, and do the work." Cut "Bachelor's in Computer Science required"
  and replace it with the actual capability and how a candidate can show it
  (shipped projects, a portfolio, a track record). If the user insists a degree
  matters, push once and ask what it is really standing in for, then capture
  that instead.
- **"X years of [tool/skill]."** Years are a weak proxy for competence and a
  hard gate that filters out fast learners and career-changers. Replace "5+
  years of React" with the outcome ("comfortable owning a production frontend
  and shipping features independently"). Keep a seniority signal only where it
  genuinely matters (for example, "has led a team through a real migration"),
  and phrase it as the experience, not the stopwatch.
- **Tool laundry lists.** Ten named technologies usually means nobody decided
  which ones matter. Keep the two or three that are actually load-bearing, and
  fold the rest into "or similar" so you are hiring for the underlying skill,
  not the exact logo.
- **Culture-fit and vague adjectives.** "Rockstar", "ninja", "works well under
  pressure", "self-starter" screen for nothing and quietly filter for bias.
  Replace with a concrete behavior tied to the work ("comfortable making calls
  with incomplete information and adjusting as you learn").

The point is not to lower the bar. It is to move the bar to something real, so
the filter keeps the people who can do the job instead of the people who happen
to match keywords.

### 3. Prioritize evidence of a track record

Because the strongest predictor of thriving amid change is having done it
before, ask explicitly for evidence, not credentials. Invite candidates to
point at things they have built, shipped, fixed, or figured out - a repo, a
portfolio, a project write-up, a story of a hard problem they owned. Make it
clear that self-taught, career-changer, and non-traditional paths are welcome
if the track record is there. This is the single change that most widens the
pool toward people who actually deliver.

### 4. Write the reworked posting

Now write it, using the template below. Keep it tight. A shorter posting that
is honest about the work will out-recruit a long one full of hedges.

## Output template

Produce a full reworked job post in this shape. Adapt headings to fit the role,
but keep the spirit: lead with the work, make must-haves real and few, and make
the application path welcoming to non-traditional backgrounds.

```
# [Role title]

## What you'll actually do
2 to 4 sentences on the real work and the problems this role owns. Concrete,
not aspirational. A candidate should picture their Tuesday.

## What success looks like
3 to 5 bullets describing outcomes in the first 6 to 12 months. Written as
results, not activities.

## What you need to be able to do
The real must-haves - capabilities tied to the work, kept short (aim for 4 to
6). No degrees-as-gates, no year counts unless they genuinely matter, no tool
bingo. Phrase each as a demonstrable ability.

## Nice to have
Things that would help but are not gates. This is where "familiarity with X"
and bonus experience live, so they never block a strong candidate.

## How to show us you're a fit
Invite evidence of a track record: projects, a portfolio, a repo, a short note
on a hard problem they solved. Explicitly welcome self-taught and
non-traditional paths.

## [Optional: about the team / logistics]
Only include facts the user actually provided (comp, location, stack, mission).
Do not invent these.
```

## Before / after example

**Before (what the user pastes in):**

> Senior Software Engineer
> - Bachelor's degree in Computer Science or related field required
> - 8+ years of professional software development experience
> - 5+ years of React, 5+ years of Node.js, experience with AWS, Docker,
>   Kubernetes, GraphQL, PostgreSQL, Redis, Kafka, Terraform
> - Strong communication skills and ability to work in a fast-paced environment
> - Self-starter who can wear many hats
> - Rockstar engineer who thrives under pressure

**After:**

> ## Senior Software Engineer
>
> ### What you'll actually do
> Own major features on our customer-facing web app end to end, from a rough
> idea to something running in production. You will make real architecture
> calls, keep the system reliable as we grow, and help newer engineers level
> up.
>
> ### What success looks like
> - In 6 months, you have shipped at least one significant feature that you
>   scoped, built, and are now maintaining.
> - You are the person the team trusts to untangle a gnarly production issue.
> - Your reviews and decisions have made the codebase easier for everyone.
>
> ### What you need to be able to do
> - Ship production web features independently, front to back.
> - Reason about a live system: performance, reliability, and what breaks at
>   scale.
> - Work comfortably in a JavaScript/TypeScript stack (we use React and Node;
>   related experience transfers fine).
> - Communicate a technical tradeoff clearly enough that a teammate can act on it.
> - Make good calls with incomplete information and adjust as you learn.
>
> ### Nice to have
> Experience with cloud infrastructure (we run on AWS), containerized
> deployments, or GraphQL. Helpful, not required - you can pick these up here.
>
> ### How to show us you're a fit
> Point us at something you have built or shipped: a repo, a portfolio, a
> project, or a short note on a hard problem you owned and how you worked
> through it. We care about your track record, not your diploma. Self-taught
> and non-traditional paths are genuinely welcome.

Notice what changed: the degree gate is gone, the year counts became
capabilities, nine tools collapsed into "the stack plus related experience
transfers", and the empty adjectives became one concrete behavior. The bar did
not drop. It moved onto the actual work.

## Guardrails

- **Do not invent facts.** Never make up salary, location, benefits, team size,
  or mission. If the user did not provide it, either leave a clearly marked
  placeholder or ask.
- **Keep legally required credentials.** Some roles genuinely require a license,
  clearance, or accreditation. Keep those. The target is fake proxies, not real
  legal requirements.
- **Push, then respect the user's call.** If the user insists on keeping a
  degree requirement or a specific year count, challenge it once by asking what
  it is really standing in for, then defer to them. It is their hire.
- **Match their voice and constraints.** If the user has a house style, comp
  band, or format they must use, work within it. The goal is a better version
  of their posting, not a different company's posting.
- **Bias awareness.** Flag language that tends to narrow the pool without adding
  signal (gendered terms, "culture fit", age-coded phrases like "digital
  native", unnecessary physical requirements) and offer neutral replacements.