AI job search and tailored resumes — jobhunt, a Claude Code and Codex skill

Why build my own instead of using an existing tool?

The tool I started from didn’t fit the Korean job market. That tool was career-ops. I liked how it split the job search into modes, kept the tool apart from personal data, and let my own criteria build up the more I used it. I could borrow those ideas, but not the parts that collect and read Korean postings.

The postings I check every week are spread across Korean job boards like Wanted and Jumpit, plus company career sites running Korean hiring systems such as greetinghr and ninehire. The postings read differently, too. They often don’t split requirements and nice-to-haves under headings; the difference sits in the sentence ending (“we need …” versus “it’d be nice if you …”). Conditions like an all-inclusive salary that covers overtime, or a probation period, have to be filtered out before any scoring. And the resume is a two- or three-page A4 document in Korean.

I built most of it with Claude Code. All 57 commits up to the day I published this, October 8, list Claude as a co-author. So this post also covers what I handed to the AI and what I kept for myself.

Scripts compute, the agent judges

jobhunt is a set of skill documents the AI agent reads (SKILL.md, AGENTS.md) plus Python scripts. Work that needs no judgment goes to scripts; work that means reading a posting and judging it goes to the agent. The two never call each other. They read and write the same files in the data/ folder.

Installation is one line. It clones the repository, links the skill into whichever agents are installed, and sets up Chromium and the Korean fonts that the PDF build needs.

curl -fsSL https://raw.githubusercontent.com/jojaden/jobhunt/main/install.sh | bash

# clone into ~/jobhunt → scripts/setup.sh
#   link the skill: ~/.claude/skills, ~/.codex/skills (only agents you have)
#   build deps: PyYAML · Playwright Chromium · Pretendard · Noto CJK KR · poppler
# run it again and git pull updates only the tool; data/ stays as it is

After that, you just ask the agent. It finds the mode document that matches the request and follows its steps.

I settled the data layout before writing code

The first commit was a resume builder: a skill that turned a yaml file into an A4 PDF. When I wanted to add posting search and evaluation on top of it, the first thing I did wasn’t code. I wrote principles and a data layout in docs/ROADMAP.md: which files belong to the tool and which are mine, and who writes and reads each one.

Writing these down first paid off later. In a long conversation with an AI, decisions made early tend to blur, but because they lived in a document I could always come back to them. Before adding a feature I’d also ask “which folder does this belong in?”, and that kept the structure from drifting much.

data/
  profile/       target roles, salary, exclusions, first-pass brief, corrections
  experience/    evidence for experience and projects (confirmed / unconfirmed)
  search/        collection settings, priority companies, queue, seen log, judgments
  job_postings/  posting text and evaluation reports
  applications/  application tracker, cover-letter answers
  interview/     interview prep, behavioral stories, interview notes

The data layout barely changed after day one. What changed a lot was how postings got scored, and I rewrote that from scratch on day two.

Why did the first scoring scheme put every posting near 3.5?

Location and pay were 25% of the score and came out near perfect whenever the basic conditions held, and the LLM eyeballed the rest of the categories in a single pass. The first scheme looked reasonable. I gave the LLM a posting and my background together and had it score five weighted categories.

role fit 30 · requirements 30 · career story 15 · location 15 · pay 10
→ the LLM reads the posting and estimates each category at once → weighted sum, 1–5

The scores looked off once I ran it. Most postings started from roughly the same place, and postings that missed a hard requirement still climbed close to “apply”. When I went through the reasons one by one, every one of them came from the structure.

The worst part was that a wrong score had nothing I could fix. Tell the LLM “this score is too high” and next time it just gives a slightly lower number. Ask an LLM for a score and you get a number, but nothing about why it’s that number. Nothing recorded which line it had misread, and nothing guaranteed the same posting would get the same number twice.

The LLM labels, score.py computes

So on day two I replaced the scheme entirely. The LLM now reads a posting one line at a time and writes only labels into fixed slots. Whether I’ve done the duty goes in fit, and whether I meet a requirement goes in met. For an unmet requirement, gap says whether I can bridge it with related experience or lack the background entirely, and key marks a nice-to-have that is really the core of the role. It writes no numbers at all.

company: Ganada
title: Backend Engineer
gates: { location: pass, language: pass, stack: pass, years: pass, employment: pass, comp: pass }
work:                       # each duties line: have I done this?
  - { line: "Build the settlement data pipeline", fit: adjacent, why: "rewrote settlement batches" }
  - { line: "Design and run payment APIs", fit: done }
required:                   # each requirement: met? if not, what kind of gap?
  - { line: "3+ years of Go or Java server work", met: "yes" }
  - { line: "Experience running RabbitMQ", met: "no", gap: bridge, why: "explain via Kafka order events" }
preferred:                  # nice-to-haves: key = what this role uses every day
  - { line: "Running Kafka", met: partial }
  - { line: "Payments at scale", met: "no", key: true }
direction: { primary: payment_settlement, secondary: [large_scale_product] }
signals: [self_service]
note: "payment API fits; payments at scale is the gap"

Feed this file to score.py and a score comes out. The math uses only the constants and rules inside the script. The script prints its labels in Korean: 지원 고려 means “consider applying”, 등급 is the band, and 필수 1줄 못 채움 means “one required line unmet”.

$ python3 scripts/score.py data/search/judgments/ganada_backend.yaml
| 회사 | 포지션 | 점수 | 판정 | 항목별 | 근거 |
|---|---|---|---|---|---|
| Ganada | Backend Engineer | 3.7/5 | 지원 고려 | 업무 4.2 · 필수 3.8 · 우대 2.0 · 방향 5.0 · 신호 +0.2 · 등급 C 1.0–3.9: 필수 1줄 못 채움 | payment API fits; payments at scale is the gap |

The 등급 C 1.0–3.9: 필수 1줄 못 채움 at the end is my favorite part of this design. The same labels always produce the same score, and the line that cost points is printed right next to it. So when a score looks wrong, I can point at the exact line to fix, as in “the RabbitMQ line should be partial”.

$ python3 scripts/score.py ganada_backend.yaml   # original
3.7/5  지원 고려  등급 C 1.0–3.9: 필수 1줄 못 채움

$ python3 scripts/score.py v2.yaml              # RabbitMQ line no → partial
3.7/5  지원 고려  등급 C 1.0–3.9: 포지션 핵심 우대 못 채움: Payments at scale

$ python3 scripts/score.py v3.yaml              # + payments at scale no → yes
4.7/5  지원 권장  등급 A 4.5–4.8: 필수 충족 + 핵심 우대 충족

$ python3 scripts/score.py v4.yaml              # + domain_new: "LLM serving"
3.9/5  지원 고려  등급 A 4.5–4.8 … · 핵심 도메인 처음 (LLM serving) → 상한 3.9

I can’t review every label by hand, so I made a golden set (examples/golden): ten fictional postings, each holding one edge case for one rule, with the correct judgments. Have an agent label them without looking at the answers, run eval_golden.py on the result, and you get line-level agreement plus the lines that disagree. I built it to measure how much judgments shift when I change a labeling rule.

Bands are shared criteria, order is my preference

Once the score was computed, the next thing I ran into was my own taste. I’d rather work on systems where the money has to add up, like payments and settlement, and on consumer services with lots of users. I wanted that preference in the score, without letting taste override hard requirements. So I split the score into two layers.

The shared criteria are constants in score.py. How many required and preferred lines are met decides the band first, and that’s the same for anyone who uses it. Personal preferences live in targets.yaml and only change the order within a band.

scoring:                    # personal preferences only; shared criteria live in scripts/score.py
  prefer_work:              # work I want; judgment files use these keys in direction
    payment_settlement: "systems where the money has to add up"
    large_scale_product: "APIs and domains of consumer services with many users"
  avoid_work:               # work that lowers the score
    admin_only: "mostly APIs for admin and back-office screens"
  avoid_cap: 3.4            # if the main work is avoid_work, cap at hold
  signals:                  # only keys listed in a judgment file's signals are added
    b2c: 0.3
    self_service: 0.2       # a team that keeps improving its own product
    crunch: -0.2            # all-inclusive pay + hints of overtime
  priority_bonus: 0.2       # bonus for priority companies (no automatic pass)

The last line, priority_bonus, has a story. At first, a priority company passed no matter its score. On the evening of day one I narrowed that rule to my target roles, and on day two, when scoring changed, I dropped it and replaced it with a 0.2 bonus. Postings that didn’t fit me kept landing at the top just because I liked the company. Now shared rules decide whether I qualify, and my preferences decide which posting to apply to first. Mix the two into one number and you can no longer tell why a score moved.

The rules came from fixing wrong judgments

Most rules weren’t there from the start. They appeared as I went through postings whose judgments felt wrong. Each time, I first asked whether the label was wrong or the rule was. A wrong label means fixing one line in the judgment file. When the labels were right but the score still looked off, I split it further: a matter of my taste (targets.yaml) or a rule that should hold for everyone (score.py).

I kept the fixes in files, not just in the conversation. An AI agent forgets earlier conversations when a new one starts, but it reads calibration.md every time. The mode documents tell it to label a new posting the same way when it resembles a case recorded there.

| Date | Posting | Before | My call | New score | Lesson |
|---|---|---|---|---|---|
| 2026-10-01 | Ganada Backend (partner admin) | PASS 4.0 | unsure | 3.2 hold | Even if requirements fit, cut direction when the daily work is admin-screen APIs |
| 2026-10-01 | Ramaba Pay Server Engineer (settlement) | MARGINAL 3.3 | better fit | 4.0 apply | When settlement is the main work, treat tech gaps like Kafka as bridge |

When a rule changes, score.py recomputes every judgment file so far, and only postings whose ranking flipped are shown. Because I could see right away which postings a rule change affected, changing rules didn’t feel risky.

Discover a company once, collect postings weekly

Good postings often appear on a company’s own career site before the job boards, or only there. But every company’s career site is different. Some don’t list postings on the first screen and only render them with a script after you click a tab or button; some block bots. Sweeping those with a browser every week is slow, costs money, and breaks often.

So I separated finding a company the first time from collecting every week. The first pass can take a while; the weekly run has to stay light. discover.py probe identifies the hiring system from the company homepage, and if that fails, it uses a headless browser to find the list API the page calls. If that request works the same way without a browser, it gets written into a config file. From then on, the weekly run sends only standard-library requests.

companies:
  - name: Ganada Lab
    careers_url: https://careers.ganadalab.example/jobs
    jsonapi:                                  # list API found once during discovery
      list: https://careers.ganadalab.example/api/jobs?status=OPEN
      items: data.list                        # where the posting list sits
      id: jobId
      title: name
      url: 'https://careers.ganadalab.example/jobs/{jobId}'
      detail: 'https://careers.ganadalab.example/api/jobs/{jobId}'
      total: page.total                       # ShapeError if fewer items arrive

One thing happened here with an AI tool. I read a browser-only company through a web scraping service’s JSON extraction feature, and it invented postings. The results mixed in example.com URLs, deadlines already past, and real posting IDs paired with other postings’ titles. Since then, anything that passed through an LLM stays a candidate until I check it against the source. The guidance now says: “don’t use JSON extraction for lists; fetch markdown, then open each posting URL and compare its title.”

Running the same steps outside Claude Code

One AGENTS.md for every agent

At first it only worked in Claude Code. The guidance lived in CLAUDE.md and the skill in ~/.claude/skills. Once it was built, though, almost nothing in it needed a Claude-only feature. Reading files, running commands, and writing judgments to files are things any agent does. So I moved the source of the guidance into a single AGENTS.md and reduced CLAUDE.md to importing it.

# CLAUDE.md

@AGENTS.md

`AGENTS.md` is the single source of project guidance for every agent; edit it, not this file.
Claude Code specifics only: the posting report can be published as an Artifact (`--fragment`, keep the same artifact URL), and the skill is linked into `~/.claude/skills` by `scripts/setup.sh`.

SKILL.md became a router. It takes a request or a mode name and sends it to one document under modes/. Features that differ between agents, such as web search or publishing HTML, became optional: use them if they exist, and otherwise give the file path or report the item as not collected.

I split the languages too. The guidance agents read is in English; output people read, the data, and the resume are in Korean. Korean status values and headings that scripts match character for character stayed untranslated even inside the English guidance. That’s when I learned guidance documents can’t be edited casually either, any more than code.

That’s why installation uses a clone instead of a marketplace. This skill is only worth using if my criteria accumulate, and there’s no point if one update wipes them. Being able to fork the tool, adapt it, and merge upstream updates is a bonus.

Collectors are tested without a network

Working with an AI was genuinely fast. On some days I added several collectors in one go. They broke just as often. A collector depends on someone else’s response format, so when a site changes, it can return zero postings without any error. I made every collector follow the same contract and raise ShapeError when a response doesn’t look as expected, which gets reported as “response format changed”.

"""Posting sources. Every module defines the same functions.

  collect(cfg) -> List[Job]        list (with bodies when possible)
  detail(job)  -> str              body (requirements, nice-to-haves, duties)
  alive(url)   -> Optional[bool]   True open / False closed / None unknown
  handles(url) -> bool             whether alive can judge this URL

If the format changes, raise ShapeError and report "response format changed".
"""

I didn’t leave that contract in a document; I turned it into tests. Each collector gets a fixture with the same structure as a real response but a fictional company and postings, and the tests check the list, the body, closing detection, and format changes without a network. If any collector lacks a fixture, the tests fail.

$ python3 -W ignore -m unittest discover -s tests > /dev/null
..........................................................
----------------------------------------------------------------------
Ran 58 tests in 1.689s

OK

The more code I handed to the AI, the more I had to set up the alarms that tell me right away when something is wrong. With the tests in place, I could trust code the AI wrote. The guidance also tells agents never to skip the privacy hook with --no-verify.

How I use it now, and what’s still missing

The weekly chores from the top of this post are now split like this.

The limits are real. Endpoints like the Wanted, Jumpit, and LinkedIn guest APIs are unofficial and can change shape at any time. Sites that block bots aren’t worked around; they’re left for a person to read. Sites whose robots.txt blocks crawlers aren’t used. The score is only an opinion. The resume and cover letter still need a fact check before submission, and I’m the one who presses the apply button.

What changed most while building this was how I decide what to hand to an AI. At first I kept asking “can the AI do this too?”; by the end I was mostly asking “should the AI do this?” Now the LLM reads and labels posting lines, a script does the math, and I decide whether to apply. Once those boundaries were written down in files, the AI handled the rest far better than I expected.

The repository is github.com/jojaden/jobhunt. It’s MIT-licensed and runs on Python 3.9+ on macOS, Linux, and Windows (WSL2). The README has previews of the posting tracker, an evaluation report, and three resume designs. If you try it and get a judgment that looks wrong, I’d like to hear about it in an issue.