chenxiang6663635/job-workbench

The loop — JD parsing → eligibility gate → resume versions → application tracking → interviews and offers. The gate runs before any scoring and can end the evaluation right there (fail, or “awaiting profile facts” — neither is scored); only an eligible job goes on to be scored. The image above is the same flow; this line is the readable version on narrow screens.

Why job-workbench

Job hunting means sensitive personal data (resumes, phone numbers, employer history) — and AI outputs that can quietly fabricate facts. This project is built around four answers:

• Local-first privacy. Everything lives on your disk as plain text — git-diffable, Excel-friendly, no telemetry, and no cloud server (the desktop app starts a local backend that listens on 127.0.0.1 only). Where the data sits depends on how you run it: the desktop app keeps a fresh install under %APPDATA%\job-workbench\data\ (or wherever jobws data-root set points it), while a repo clone uses the git-ignored personal/ workspace. Either way the repository itself ships zero real data.
• Auditable AI, not black-box automation. Your own AI CLI (BYOK models) does the semantic judgment — reading the JD, scoring fit. Python scripts do everything deterministic: eligibility gates, score validation, PDF generation, tracker I/O — and every automated verdict (application health, CSV import diffs, failure clustering) comes with explicit, human-checkable reasons, never a bare score.