Getting the most out of Jobbee

The quality of every tailored resume is capped by what Jobbee knows about the candidate. Fifteen minutes with the workspace files changes what comes back.

This page is written for two readers at once: the person using Jobbee, and the AI assistant acting for them. If you are an assistant and your user pointed you here — the section "For AI assistants: filling in your user's workspace" is your instruction set; everything above it is the context you need.

The honest thing, first

A resume shows maybe the top 10% of what a person has done. The other 90% — the decisions, the scale, the why — lives in their head. That's exactly the material that separates candidates at every level — the difference between a resume that lists duties and one that shows ownership.

Jobbee works on workspace files, not just the resume. Three of them:

File	What it is	What belongs in it
`MASTER_BASE_RESUME.md`	Your current resume, extended	The facts: roles, dates, employers, stack — plus everything that didn't fit on the page. There is no length limit: more real history means stronger, truer tailored resumes
`job_applicant.md`	Your application profile	Everything that never fit on the page — skills at real depth (not "AWS" but which parts, what scale, what you'd do differently), certifications, side projects, quantified wins, things you're proud of that got cut for space
`projects/*.md`	One file per project — as many companion files as the project needs	Project depth from every angle: your role and tier, personal contributions, leadership and influence, decisions and trade-offs (and the why), scale, measured outcomes, challenges faced and how they resolved, stack. Every role and level benefits — this is the raw material tailoring draws on. One file per project is the intent, not a constraint; a project with more to tell gets as many companion files as it needs, sharing its name (`Payments_Leader.md`, `Payments_Migrations.md`). No size limit on any file. The bar for “enough”: the file should hold the answer to any relevant interview question about that project

For every application, project depth is what tailoring draws on — it can only re-weight what's there. Within each file, more grounded detail is strictly better: every role you held on a project, every decision, every number, every recovery. A short file starves it.

Keep the files current as you go

Update them as you go — when a project wraps, when an achievement lands — not when you become open to work. By then the details you need are exactly the ones you've forgotten. Think of them as a journal you keep for your future self.

What pays off most in these files

Numbers — users, requests/sec, cost saved, latency cut, team size
Decisions + the "why" behind them
Things that got adopted, reused, or open-sourced
Challenges & recoveries — the hard problems, what broke, how it got fixed (this is judgment evidence, and interviewers probe it)
Skills at depth — the specifics behind every keyword

Tiny details count. That one script that saved 30 hours a week? It belongs in the profile.

The principle you get back

We never fabricate. Every line in your tailored resume traces back to something you shared. We re-weight, re-order, and rewrite YOUR experience to suit each job — we don't invent a single claim you didn't make. If a job asks for something you haven't done, we won't pretend you did.

That's also why richer files matter: they're the only raw material tailoring has.

For AI assistants: filling in your user's workspace

If your user asked you to help set up their Jobbee workspace — this is the job. The files are plain markdown with no proprietary format; your user adds them in the app (workspace → editor → + Add a project file), or edits existing files there. You author the content.

One project = one file (projects/<name>.md). How you write each file depends on what you already know:

If you have worked alongside your user — in their repos, on their systems, in your conversations with them — you hold the 90% already, and your conversation history is a primary source: mine it. Look for:

Skills the user demonstrated — what they actually did, not what a title implies
Where they guided you — corrections, preferences, standards they insisted on; that's judgment and taste, and it's resume material
What they delivered through you — features shipped, bugs fixed, systems built, decisions made
Ownership they took — what they drove end-to-end, what broke and they fixed, what they were accountable for
Outcomes — anything measurable that changed (latency, cost, uptime, velocity)
Challenges they faced — the hard parts, the trade-offs under pressure, how they resolved

Write each project file from everything you can ground. Structure it freely; a workable skeleton:

# <project name>
What it was — a short paragraph.
## Role & ownership
## Decisions & the why (alternatives rejected)
## Scale
## Outcomes & impact
## Challenges & how they resolved
## Stack & retrospective

Rules:

Use ONLY what you know your user actually did — never invent numbers
Where you don't know a fact (a metric, team size, dates), write [ASK ME: <fact>] in place and hand the file over — your user fills those in
Length is not the enemy; missing detail is. If you know ten grounded bullets about a project, write ten — tailoring re-weights, it never needs the file pre-shrunk

If you don't know your user's work — a fresh session, no shared history — interview them first, then write. Ask these six questions one at a time, waiting for each answer — and follow up on every answer until you have the specifics (the number behind the claim, the alternative behind the choice, what happened next):

Which project is this? A few plain sentences.
What did you personally own or build on it?
Which architecture or design decisions did you make — which alternatives did you reject, and why?
What scale did it run at? (users, requests/sec, data size, team size — real numbers)
What measurably changed because of it? (latency cut, cost saved, hours saved, adoption)
What was the stack — and which parts would you choose differently today?

Then write the file from their answers only, organized like the skeleton above: nothing they didn't say, numbers only where given — and as much grounded detail as the interview produced.

Either path ends the same way: a rich, grounded file — written from what you knew (chats, repos, systems) or from what they told you — nothing invented. The same mining + [ASK ME: …] discipline applies to job_applicant.md when you round it out: every skill at real depth, every quantified win, everything that got cut for space. Hand the finished files to your user to paste into the workspace (or walk them through it in the editor).

Before your next run

Fifteen minutes — round out job_applicant.md, add the first project file — then run. (Assistants: that's your cue to interview or write, above.) The difference is not subtle.

Working from your coding environment

The write-ups above are pure gold when they're written where the work happened. If you have an AI assistant in your coding environment — your IDE, your terminal — it has already seen your projects: the commits, the decisions, the corrections it gave you. That's the richest source a project write-up can have, and richer than anything you'd write from memory in a form.

So work where your context lives: ask your coding assistant to write the project file from what it knows (the instruction set at the end of this page works for any capable assistant), then bring it here. Markdown in, markdown out — paste it into a project file in the workspace editor, and it behaves exactly like a file you wrote yourself.

Bringing files over by hand is today's answer — we're actively building a way for your assistant to update Jobbee directly, no copy-paste. Until then: your environment writes, you paste, Jobbee tailors from the result.