> ## Documentation Index
> Fetch the complete documentation index at: https://hired-claude-google-calendar-gmail-integration-bi7nna.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# The pipeline
> Ten stages including four different endings, an activity timeline, tasks, follow-up dates that set themselves, saved views, and a read-only link for whoever is helping you.
An application is one job you are chasing at one company. It carries the posting, a
stage, a timeline of everything that happened, and the dates that decide what you do next.
## The ten stages
Six are positions on the path. Four are endings, and the difference between them is the
whole point.
| Stage | Label | Means |
| ----------- | ------------ | --------------------------------- |
| `WISHLIST` | Wishlist | Interested, nothing sent. |
| `APPLIED` | Applied | Sent. |
| `SCREEN` | Screening | Recruiter conversation under way. |
| `INTERVIEW` | Interviewing | In the loop. |
| `FINAL` | Final round | Last stage before a decision. |
| `OFFER` | Offer | They made one. |
| `ACCEPTED` | Accepted | Signed. |
| `REJECTED` | Rejected | They said no. |
| `WITHDRAWN` | Withdrawn | You pulled out. |
| `GHOSTED` | Ghosted | Nobody ever replied. |
The first six are the board columns. The four endings get their own view.
```mermaid theme={null}
flowchart LR
W[Wishlist] --> A[Applied] --> S[Screening] --> I[Interviewing] --> F[Final round] --> O[Offer]
O --> AC[Accepted]
A -.-> G[Ghosted]
S -.-> G
I -.-> G
A -.-> R[Rejected]
S -.-> R
I -.-> R
F -.-> R
W -.-> WD[Withdrawn]
O -.-> WD
```
Solid arrows are progress; dotted ones are the endings, and an application can reach any
of them from anywhere. Nothing enforces the order — you can move a card straight from the
wishlist to an offer if that is what happened.
**File silence as `GHOSTED`, not `REJECTED`.** Silence is the most common ending in any
search, and calling it a rejection makes the funnel lie about what went wrong. A
rejection is a decision against you; a ghosting is a non-response — and the advice that
falls out of those two is completely different.
Colour carries the same information: hue rotates in one direction as an application
advances — steel, blue, violet, pink, then gold at the offer — so two chips read as
"further along" without you knowing which label is which. The endings sit outside that
rotation, because they mean something other than progress.
### An ending is not a deletion
`REJECTED`, `GHOSTED` and `WITHDRAWN` close an application and keep it: it drops off the
board, stays in the funnel, and `list_applications` returns it with `includeClosed`. That is
what you want for almost everything that ends, because a rejection you cannot count is a
rejection you cannot learn from.
Deleting is the other thing, and it is reversible. `delete_application` puts the row in the
[archive](/tools/archive), where it leaves every list, board, picker, filter and count and
waits — thirty days by default — before it is deleted for good. `restore_records` brings it
back. If you want it out of the way but still counted, close it; if you want it gone, delete
it and the archive holds the door open.
## Capturing something
`capture_job_posting` fetches the page server-side, reads the structured posting data
most job boards publish, and creates the application in one move — company matched or
created with its own website, role title, full description, location, compensation
and where it came from, starting on the wishlist.
`create_application` needs only `company` and `roleTitle`. The company is created
automatically if it does not exist yet.
When a page does not state the employer or the role readably, `capture_job_posting`
returns `captured: false` with whatever it *did* parse and creates nothing — deliberately,
because an employer guessed from a URL is worse than an employer you were asked about.
Paste the **whole** posting into `jobDescription`. It is what a resume gets tailored
against later, and postings disappear from the web the moment the role is filled.
### A listing is optional
A role you are chasing through a LinkedIn DM with no posting at all is still an
application. Track it with just company and role title, put `Cold outreach` in `tags`,
and attach the person you messaged as a contact.
### Tags
`tags` is a list, because a job board posting, a referral and a LinkedIn message are often
the same job. It is where an application came from, and anything else you want to file it
under.
Tags are records you own, not free text: each one is a name and a colour, and `list_tags`,
`create_tag`, `update_tag` and `delete_tag` manage them. The same table holds the labels on
companies and people — `kind` says which list a tag belongs to, so a location called
`Remote` never collides with a way of working called `Remote`. Deleting a tag takes it off
everything that carried it and leaves those records otherwise untouched — and unlike a
company, a person or an application, a tag really is gone rather than going to the archive.
A label is not a record with a history: what wore it is untouched apart from no longer
wearing it, and a label you cannot remove is worse than one you delete by mistake.
Write them by `tagIds` when you have them, or by name in `tags`. Names are matched
case-insensitively against what exists — `linkedin` lands on your existing `LinkedIn` — and
a tag is created only when nothing matches. Call `list_tags` first either way.
Both `tagIds` and `tags` REPLACE the whole set on an application, like every other array
in this API. Read the current one with `get_application` before writing it back.
`sources`, `sourceIds` and `source` still work: tags were called sources until they grew
to cover companies and people too. `tags` wins wherever both are passed.
A new workspace is offered LinkedIn, Job board, Company site, Referral, Recruiter reached
out and Cold outreach as a one-click start. They are a seed, not a fixture: accept them and
they are your rows, to rename, recolour or throw away.
## The timeline
Every application has one, and everything that happened goes on it. Twelve activity types:
`NOTE` · `STAGE_CHANGE` · `EMAIL_SENT` · `EMAIL_RECEIVED` · `CALL` · `INTERVIEW` ·
`FOLLOW_UP` · `APPLIED` · `OFFER` · `REJECTION` · `REFERRAL` · `OUTREACH`
`OUTREACH` is for a message you sent first — a DM to a hiring manager, a cold email.
Half of some searches happen there, before or instead of a formal application.
Moving a stage writes its own timeline entry and resets the follow-up date, so
`move_application_stage` is one call rather than two. Do not also log the change by hand.
Write the entry the way you said it. "Recruiter said the team is six people and they
want someone to own billing end to end" is worth far more in three months than "had a
call" — and it is what makes a follow-up message refer to something real.
## Follow-ups that set themselves
Changing stage schedules the next nudge automatically, for 9am on the day it falls:
| Entering | Nudge after |
| ----------- | ----------- |
| `APPLIED` | 7 days |
| `SCREEN` | 4 days |
| `INTERVIEW` | 4 days |
| `FINAL` | 3 days |
| `OFFER` | 2 days |
Moving to `WISHLIST` schedules nothing. Moving to one of the four endings **clears** any
follow-up date the application had and stamps it closed — a finished application should not
keep nagging you. Override any of it by hand: `nextFollowUpAt` on the application, or the
cell in the table.
Moving out of `WISHLIST` for the first time also stamps the applied date, if it was not
already set.
Contacts have their own version: `nextFollowUpAt` on a person is where "ping Sarah in two
weeks" lives. In the app, both land on **Tasks**.
### Three ways to ask what is due
What is already due, or due within N days. Returns two lists: applications whose date
has arrived, and contacts whose ping has. Both are work.
Everything dated between two dates, merged and sorted: follow-ups, task deadlines and
activity already logged. The right call for "what does my week look like".
To-dos, with or without a due date, and about at most one thing: an application, a
company, a person, a resume, a role in Me, a note — or nothing at all. `update_task`
moves one, `complete_task` ticks it off, `delete_task` removes it.
## Reading the search
`pipeline_stats` gives you the counts: by stage, active, sent this week, interviews,
offers, open tasks, follow-ups due, response rate.
`diagnose_search` gives you the answer. It returns a one-sentence verdict naming which
step of the funnel is losing people — no responses at all is a resume or targeting
problem, responses that die at the phone screen is a story problem, interviews that do
not convert is something else again — plus per-step conversion, median days in each
stage, weekly volume for the last six weeks, applications that have gone quiet, and the
response rate of each resume so you can see which one is working.
Progress is measured by the furthest stage an application ever reached, so a rejection
after a final round counts as having got that far. When there is not enough data yet, it
says so plainly rather than inventing a trend.
Reach for `diagnose_search` before giving or taking advice about a search. It is the
difference between "send more applications" and "stop sending, the resume is the
problem".
## Views and cuts
The pipeline toolbar picks the view — a drag-and-drop **board**, a sortable **table**, or
a month **calendar** of everything with a date on it — plus a filter and a search.
Filters combine — all of them, with each other. "Screening and interviewing" is one view
rather than two trips, and so are "screening but only the overdue ones" and "closed, but
only the ghostings".
Everything lives behind the **Filter** button beside the search: the stage, its tags, the
company, which resume went out, how long it has sat still, and how much you want it. It
opens on the dimensions rather than on every value at once — click **Stage** and you get the
stages, click **Company** and you get companies — and typing searches across all of them
together, saying which dimension each match came from. Every count you see is counted
against the rows the other filters left, so a row never claims twelve when the search has
left one.
Two chips stay above the board: **Everything**, and **Needs a nudge**. The stages used to sit
beside them as a row you scrolled sideways, above a board whose columns are the stages;
they are a dimension like any other and they live in the menu now. What is overdue is not —
the front page is built around it and the bell counts it, so it stays one click from
anywhere.
Location and work mode are free text and stay that way — "Remote (US, PST overlap)" is a
real answer no list survives — but the field offers what you have already used, most-used
first, so a workspace does not end up with three spellings of Remote. `list_field_values`
is the same list over MCP, and it is the call to make before writing either field.
The table edits in place: stage, follow-up, salary and location are the cells themselves,
and selecting rows closes a batch out in one action. Two columns count days: **Waiting** is
days in the current stage, **Quiet** is days since anything was logged. A call you noted
yesterday resets Quiet and leaves Waiting alone, which is why chasing is decided on the
second one — `qd` filters on it and `sort=quiet` orders by it.
A cut worth keeping gets saved under a name. A saved view stores the pipeline URL's own
parameters:
```
view=list&f=APPLIED,SCREEN&sort=waiting&dir=desc
```
| Parameter | Values |
| ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `view` | `board`, `list`, `calendar` |
| `f` | Comma-separated stages, plus `overdue` as a flag. `closed` expands to the four endings. |
| `src` | Comma-separated tag ids. Spelled `src` because tags were called sources when saved views started storing them, and renaming it would break every view already saved. |
| `co` | Comma-separated company ids |
| `cv` | Comma-separated resume ids, or `none` for the ones with no resume attached |
| `w` | Minimum days sitting in the current stage |
| `sort`, `dir` | Column and direction |
| `q` | Search text — company, role, notes, location, work mode, the posting, and tag names |
| `month` | `YYYY-MM`, for the calendar view |
Saving under a name that already exists replaces that view, which is how you edit one.
Anything outside those parameters is dropped, and they are always written in that order —
so the same view saved twice is the same string.
`co` and `cv` hold ids, which survive a rename but not a delete. A saved view naming a
company you later merged away simply stops matching it; nothing breaks, and clearing that
filter fixes it.
## Sharing the board
`share_pipeline` mints a read-only link at `/p/` for a friend, a coach or a former
manager who is helping you review the search. What a viewer sees is deliberately narrow:
Company, role, stage, location, how long each has been sitting, and when a follow-up
is due. Optionally the closed applications too.
Notes, job descriptions, salary, contacts, or the activity timeline.
Calling it twice returns the same link rather than a second one. `unshare_pipeline`
**destroys** the address rather than pausing it — sharing again later mints a completely
different URL — because the reason to revoke is usually that a link reached someone it
should not have, and a pause you can undo does not fix that.
## In the app
**Today** — the front page — leads with what is due, and the bell in the top bar carries
the count of it on every other screen. Its second tab, **Analytics**, is where the numbers
went: the funnel drawn as a flow chart, the diagnosis, the response rate, and a **Share
chart** button that hands you the flow chart as a PNG or an SVG with no company or role
name anywhere on it. **Pipeline** is the board, table and calendar. Opening an application slides it in from the right, so you keep your
place on the board — posting, timeline, contacts, tasks and the resume you attached, all
on one panel.
Every view also decides how much it shows before you open anything. The **Fields** button
picks per view — a board card, a table row and a calendar chip have nothing in common except
that all three can be too busy — and the choice follows you between devices rather than
living in the URL, because a saved view is a cut of the data and this is not. The same is
true of how wide each column of the table is: drag the divider between two headings and the
width is saved to your profile, so it is the same on your laptop and your phone. The company
column takes whatever the rest leave, which is why widening one narrows it rather than
pushing the table off the side. `get_column_widths` and `set_column_widths` are the same
thing over MCP.
On the board
and in the table, the company, the role title and the stage are never in the list: a card
without them is not shorter, it is unreadable, and in the table the stage cell is the editor
the table exists for. The calendar is the exception, and only for stage — a chip is one line
of an entry's own title, so the stage is genuinely extra there, and it is off by default.
**Today** is the page you clear the list from, and it is what `/` opens to — the numbers
used to sit there and now sit one tab over, because you open this app to do the next thing
rather than to read your own statistics. Two columns, deliberately not merged: the things you wrote down, grouped by overdue,
today, the next seven days, later and undated — each one rewordable, re-datable and
attachable to a role in place — and beside them the chase list, the follow-ups and pings
whose dates have come round, where the verbs are "logged it" and "push it out three days".
Ticking a task and logging a chase mean different things, so they do not share a column.
Scheduling a new ping lives there too.
Everything here is reachable by conversation — see [the pipeline tools](/tools/pipeline).