Feed it a resume and wait — that's not how this works. It reads the job ad, asks you pointed questions about the gaps, and won't write a word until you've confirmed every claim. Then it went and started skipping its own rules anyway, which is honestly the better story here.
Status: in active use for my own job search.
This started small — tailoring my own resume for one application, going back and forth until it felt right. But I kept saying the same things over and over: don't make up numbers, don't use a title I can't defend, don't list something I only saw once in a course. So I stopped repeating myself. Turned it into an actual process built around the thing that made the first attempt work in the first place — it asks something, I answer, and it checks that answer against everything else before moving on.
None of the rules were just guesses, either. Most resume advice floating around online is folklore that's been repeated so many times it sounds like fact — "the ATS bot will auto-reject you" is the big one everyone's heard. Before I wrote that part of the tool I actually looked into how recruiters at big companies use their hiring software day to day, instead of trusting the myth. Turns out nothing auto-rejects you. A human looks, always. The actual risk is being invisible in a search, not getting bounced by a robot. That's more or less the standard for every rule in here — check what's true first, write the rule after.
It checks everything it already has — your saved profile, the job ad, and anything you've answered so far — together, before deciding what's actually missing.
For whatever's still unclear after that, it asks — one specific question at a time, not a vague "tell me about yourself." It keeps going until nothing's left open.
Once it has enough to work with, it shows you what it's planning to use and waits for a yes before writing a single word.
Only then does it write the resume, along with a scorecard — calculated, not a gut feeling dressed up as a percentage.
Then I actually used it on real applications, and it fell apart in a way I didn't see coming. Not the writing — the process itself. It would skip a step and just not say anything. Answer its own confirmation question instead of waiting for mine. Ask something I'd already shut down two messages earlier, like the conversation hadn't happened at all.
The whole time, it kept cheerfully telling me it had followed every step. It hadn't. I couldn't trust its own word on its own homework.
So I stopped writing polite paragraphs asking it to please behave and rebuilt the process around forced checkpoints instead — every step has to output a specific, visible line before the next one's even allowed to start. That fixed the exact thing that broke. Felt pretty clever about it, honestly. Not for long.
Then I tested a different application and audited the whole session against its own rulebook — and the brand-new checkpoint had already failed too. Differently, and somehow more annoying: instead of quietly skipping the gate, it just answered the gate itself and moved on. Like a kid writing "yes I read chapter 4" without opening the book. That's the moment it actually clicked for me — a "hard gate" written into a prompt isn't hard at all. It's a suggestion wearing a badge.
Which was the real thing I learned: a checkpoint only means something if there's actually someone checking the answer, and there wasn't. So the fix wasn't more checkpoints. It was pulling enforcement out of the prompt completely and putting it into code, where an outside program runs the sequence and a step just can't fire until the one before it genuinely passes. Not asked nicely this time, rather enforced.
Past the resume itself, it also builds the final document, creates a folder for each application, uploads it, and logs everything into a tracking spreadsheet on its own — a real pipeline, not just something that spits out paragraphs.
The actual output isn't just the resume, either. Every single bullet comes with a short note attached: what it claims, what real experience backs it up, and a prompt like "if this comes up in the interview, talk about the specific redesign you did." The point is that you should never look at your own resume and think, wait, how do I explain this if they ask. There's already an answer ready for every line, before you've even sent it.
The checkpoint story above is the interesting failure. Here's a sample of the actual rules underneath that back-and-forth — not the full list, just enough to show how it thinks.
Not keyword-matching. It takes a real requirement from the ad, checks whether real experience actually supports it, and if it's not obvious, it asks — then proposes the connection out loud instead of assuming.
Job ad: Operations Coordinator. Requirement: "process improvement."
It asks: "Have you ever changed how a recurring task was done to make it faster or more reliable?"
You answer: "Yeah, I redesigned how our team logged issues so nothing got missed."
It proposes: "That's a real example of process improvement — want me to phrase it that way on the resume?"
If a number's shaky, it doesn't stay specific. And if a claim can't be backed up at all, it gets cut, not just softened.
It asks: "Do you have a real number for how much that redesign cut down missed issues?"
You answer: "Not exactly — just noticeably fewer, no percentage I tracked."
It writes: "significantly reduced missed issues" — true and solid, instead of a made-up percentage that could fall apart under a follow-up question.
A title only changes if it's more accurate, not just more impressive — and it has to survive being questioned.
Job ad title: Operations Coordinator.
Your official title: "Assistant" — but the actual work is scheduling, tracking tasks, and the issue-logging redesign from above.
Reframe: "Assistant" → "Coordinator" is fair, since the real work matches. → "Manager" would be a stretch nothing in the work backs up, so it's rejected.
Used on the job, used as a hobby, or just seen in a tutorial — those don't get listed the same way. This filter runs before anything reaches the resume, protecting the honesty score from claims that would be shaky in an interview.
You tracked the issue-logging redesign in a spreadsheet, used daily → goes straight into Skills.
You also mention trying Notion once, on a personal project → framed as exploration, not listed as a professional skill.
Each rating comes from comparing the resume against the job ad directly — how many required terms actually appear, how many bullets have a real number behind them, whether the role level lines up. Nothing here is a gut-feel grade.
ATS Alignment: 72% — 13 of 18 required terms matched, including "process improvement."
Metrics Coverage: 40% vs a 50–70% target — the issue-logging bullet has no hard number, so it counts against this one.
The common myth is that a robot scans for keywords and auto-rejects you if one's missing — so people cram every possible term in, which actually backfires: over-stuffed resumes read as AI-generated, and human reviewers are trained to spot it. What's actually true: recruiters search the applicant pool by keyword, and ranking tools push better-matched resumes to the top of the list — so the real term still needs to be there, just written naturally, capped at 2-3 uses, inside a bullet that's actually true. Not stuffed in to trick anything, just present enough to be found.
A recruiter searches their applicant list for "process improvement" to shortlist people faster. The phrase gets included naturally, once, inside a real bullet — not repeated five times to game a score that doesn't exist.
At the end of every session, it compares what came up against the saved profile. If anything new surfaced, it asks before adding it — nothing gets saved silently.
It checks: was the issue-logging redesign already saved in the profile from a past session? No.
It asks: "That issue-logging redesign wasn't in your saved profile before today — want me to add it, so it's ready to use next time without re-explaining it?"
Every rule in this skill read airtight. The truncated read, the self-answered gate — both only broke once I ran it on a real application, and the tool still confidently told me it had followed every step. Now I don't trust a rule, or an AI's word that it followed one, until I've tried to make it fail myself.
The ATS myth is the clearest example — repeated everywhere, mostly wrong. I got in the habit of checking what's actually true before writing a rule around it, instead of building on top of advice nobody's verified.
I kept adding more careful instructions before realizing the actual problem was structural — no amount of better wording was going to fix it. Moving to code was the harder call, but the right one.