Jobsworth

What it does

Jobsworth is my personal job application workbench, forked from the open-source tracker JobSync. Its central idea is that evidence, not the CV, is the source of truth. Career achievements live in an evidence bank, each with its own provenance, and every document in an application is drafted from that evidence rather than invented fresh. It works for any application; Civil Service Success Profiles and Behaviours are an optional layer for the vacancies that use them.

An application now runs as one flow. I capture an advert (from the browser extension, or from Job Scout), and Jobsworth breaks it into requirements, matches evidence against each one, and proposes a drafting plan across every part of the application. Once I approve the plan, it drafts the CV, personal statement, cover letter, Behaviour statements and application questions, reviews the application as a whole, and makes one revision. I then edit and approve each part.

How it works

The work is split into small, single-purpose model calls rather than one prompt holding a whole career: scoring evidence against requirements, planning, drafting, and an independent check. Each call site has its own route in settings, so every task runs on whichever model did best at it in a blind comparison, and the claim check runs on a model from a different lab from the one that drafted the text.

The rules that matter are in code, not prompts. Code selects which evidence is used and says why; a requirement with nothing behind it shows as a gap, which is shown to me and never written into the application; and my own rules for describing a piece of work (the figures, the scope, the dates) are checked in code in every document. The claim check warns rather than blocks: I decide, with the warnings in front of me.

Since forking, the codebase has also gained encrypted backups with guarded import, PDF export with a server-side check that the CV fits its page budget, embeddings for search by meaning, a library of Behaviour statements that improve over time against their grade, a mobile capture flow, and an agent-chat layer whose write actions wait for my approval.

The interesting problem

Knowing whether a change made the drafts better. Reading outputs and deciding they look good doesn’t survive more than a few changes, so the later phases are driven by evaluations against my own past applications. A benchmark of five real applications compares each new version’s drafts with the documents I actually submitted. One round of changes took the overlap between drafted CVs and my final versions from 40% to 63%, and cut code-detectable defects in statements from nine to none.

The same approach settles model choices. Where two models or two drafting flows are close, I compare their outputs blind on real applications and route the task to the one I picked, then record the decision. It is slower than going with a benchmark leaderboard, but it measures the thing I care about, which is how close the draft is to what I’d submit.

Stack and why

SQLite and a local-first architecture keep the evidence bank, which necessarily holds detailed personal and career history, under my control; it is reachable only over my tailnet, and evidence marked local-only never reaches a cloud model. Routing every call through OpenRouter with a per-task model setting means a better or cheaper model is a settings change, not a code change. The MCP server lets any MCP-capable assistant query the evidence bank directly, without a bespoke chat interface.

What I would do differently

JobSync contains many features I simply won’t use as part of my workflow. Designing this project again, I would choose a more feature-light project to fork (there are several similar projects available) to avoid uneccessary bloat and maintenance overhead to my own repo.