# 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):

1. Which project is this? A few plain sentences.
2. What did you personally own or build on it?
3. Which architecture or design decisions did you make — which
   alternatives did you reject, and why?
4. What scale did it run at? (users, requests/sec, data size, team
   size — real numbers)
5. What measurably changed because of it? (latency cut, cost saved,
   hours saved, adoption)
6. 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.