A friend of mine, an engineer, was losing hours every day to her job search, and most of it wasn't deciding anything. It was checking: the inbox for job alerts, careers pages for anything new, her own notes for what she had applied to and when. Then the weekends went to reshaping her resume for whichever roles survived all that checking.
That is exactly the work an AI agent is good at. It is also exactly the work where an agent can quietly hurt you. A resume line that claims a skill you don't have gets you an interview you then fail. An agent that helpfully emails a recruiter, archives a rejection or marks an application dead because a careers page went down has made a decision that was hers to make, and she finds out last.
So I built her foundry-kit, and I built it paranoid. It is open source under MIT as foundry-kit-open.
What it does
She keeps one folder of plain files on her own Windows machine and works through twelve slash commands in Claude Code (or OpenCode). /start interviews her once and builds a facts bank from her documents, a fact at a time, each one confirmed by her. /sweep ranks the new roles, /check runs a deep fit check against her own search rules, and /tailor writes a resume for one job. /applied and /update track applications, /grill runs a timed mock interview, /prep covers a job's gaps, /refer handles referral asks and /today tells her what needs her.
A scheduled task reads the careers sites and her alerts every morning without any AI at all, so the model only ranks what is already waiting. Hours of checking became minutes.
That part was easy. The rest of this post is about the part that wasn't.
Rule one: it never invents anything about her
Every line the kit writes for her cites a fact she confirmed. Two independent checks refuse any line that doesn't trace back, and rendering refuses until the resume passes. The tailoring loop also checks the job description's exact spellings, a keyword score and her page limit, and it never lets the headline borrow a job title she has never held. Models love promoting you. Interviewers love asking about it.
The fair objection: a strict truth rule makes a thinner resume when the facts bank is thin. It does. That is why /start asks for one long master resume with no page limit, because ten pages of rough notes beat one polished page when the kit can only use what she wrote down. I would still take a thinner true resume over a stronger one she can't defend across a table.
Rule two: it never acts for her
/refer is a referral pipeline: contacts per company, one contact per role, a daily cap on asks and one nudge, then nothing. It drafts the connection note and the ask within their limits (under 220 characters and under 85 words). It never sends either. She copies, she sends, she tells the kit what happened, and a contact's stage changes only on her word.
The tracker follows the same rule. When a posting disappears from its board for two sweeps, or its posting page answers 404 or 410, the kit flags it in /today for her to confirm. It never closes the application, and a 403 alone isn't enough to flag it, because a careers site having a bad day is not a rejection.
Rule three: it touches as little as possible
Gmail is optional. Turned on, the kit reads one label in read-only mode and never changes a message. There is a test that fails if the Gmail module ever contains a write command, because I don't trust myself to remember that rule in six months.
It never fetches LinkedIn or Naukri or logs into them: she sets up their alerts herself and pastes a posting when she needs to. Careers sites are read by the kit's own fetcher, which checks robots.txt before it reads a careers page. API keys and app passwords live in Windows Credential Manager, never in a file. On OpenCode, every request goes through OpenRouter and asks only for endpoints that keep no data and don't train on it. Free models are never used.
Rule four: the repo can't leak her either
She was the first user, so her real situation shaped the design, and none of it is in the public repo. Every commit is scanned against a deny list kept outside the repo, and the commit is refused on any hit. The release build runs the same scan and refuses too. Test fixtures use invented people whose phone numbers and emails are assembled at runtime, so even the scanner's own tests stay clean.
Paranoia has a price
All of this is slower to build than a demo. Most of these rules have a test behind them and a line in the docs. The last check is still a person: the kit shows her every resume and waits for her to call it final. I left that one manual on purpose. The automation earns its trust by being boring and checkable, and the final read is where she catches the thing nobody wrote a rule for.
If you're building one
Decide what your agent must never do before you decide what it should do, and write those limits as code and tests, not as lines in a prompt. A prompt is a request; a test is a wall. Keep the human on the irreversible steps (sending, closing, submitting) and let the agent do the reading and the drafting. Then make every claim it produces traceable to something a person confirmed.
If you want a starting point, foundry-kit-open ships a software-engineering pack (levels, role families, a starter list of companies, interview questions) and a general pack for any other field. Fork it, break it, and tell me which rule you'd add.
