Job Application Tracker

Job Application Tracker

A skill for keeping a Notion database of job applications up to date, by cross-referencing recent Gmail messages and Google Calendar events. Designed to be usable by anyone, including someone starting from scratch (no Notion database yet, connectors not yet linked).

Step 0 — Check prerequisites (always do this first)

0.1 Connectors

Check whether you have access to Notion, Gmail, and Google Calendar tools. If one or more are missing:

• Use search_mcp_registry with relevant keywords (e.g. ["notion"], ["gmail", "email"], ["calendar"]).
• Use suggest_connectors to let the user connect them.
• Don't move to the next step until the user has at least connected Notion. Gmail and Calendar are both needed for a full scan, but if the user wants to start with just one of the two, that's fine — flag it and proceed with what's available.

0.2 Notion database

Ask the user (or search yourself) whether a dedicated job-applications page/database already exists. Try notion-search with keywords like "applications", "job tracker", "interviews", "candidature".

If no database exists: Offer to create one yourself, explain what you're about to do, and ask for confirmation before creating pages in the user's workspace. Create a page with an inline database using this minimal schema (it can be enriched if the user wants):

| Property | Type | Notes | |---|---|---| | Company | title | company or agency name | | Role | text | position applied for | | Application Status | status | options: No contact, Applied, HR Contact, Intro Call, Technical Test, Rejected, Offer Accepted | | Last Updated | date | date of the last detected status change | | Notes | text | free-form summary of what happened / next steps |

[CRITICAL ORDERING RULE]: You MUST define and inject these properties into the Notion API payload in the exact top-to-bottom sequence shown in the table above: 1. Company, 2. Role, 3. Application Status, 4. Last Updated, 5. Notes. Notion establishes the visual column order based strictly on the sequence of the creation object; do not scramble or alphabetize them.

Use notion-create-pages (or whichever database-creation tool is available) to generate it, then share the link with the user and ask for confirmation that it looks right before starting to populate it.

If a database already exists but with different column names (e.g. "Azienda" instead of "Company", "Stage" instead of "Application Status", or no Notes column at all):

• Adapt the matching to the real column names — don't assume they match the ones above. Always read the actual schema with notion-fetch on the data source before writing anything.
• If a column you need for useful information is missing (typically Notes or a last-updated date), propose adding it with notion-update-data-source (ADD COLUMN ...) asking for confirmation before modifying the schema of an existing user database.
• If the Application Status property has different or incomplete options compared to the table above, don't force the existing options: map the classification from Step 5 onto the closest available option, and if important stages are genuinely missing, propose (without imposing) adding them.

0.3 First run vs. subsequent syncs

If the database is empty or newly created, every application found will be a new row. If it already contains rows, run the matching described in Step 4 before deciding whether to create or update an entry.

Execution flow (after Step 0)

1. Read the current state of the Notion database

• notion-fetch on the page URL/ID to find the inline database and its data-source-url (collection://...).
• notion-fetch on the data source to read the exact schema (property names, available status options) — never assume the names, always read them.
• Try reading existing rows with notion-query-database-view or notion-query-data-sources (SQL). Note: both tools require a Notion Business+ plan with Notion AI: if they fail with validation_error, use notion-search with data_source_url set to the data source to retrieve existing pages, or proceed by browsing the database view directly.

2. Scan Gmail (if connected)

Search with Gmail:search_threads, a query like:

newer_than:7d (application OR interview OR screening OR "intro call" OR "technical assessment" OR recruiter OR position OR offer OR hiring)

Adapt the keywords to whatever language(s) the user receives emails in (e.g. add Italian terms like "candidatura", "colloquio", "prova tecnica" if they're also applying to companies in Italy, or other languages as needed).

Default window "7d", or since the last sync date if known. For ambiguous threads, use Gmail:get_thread or Gmail:get_message to read the full body before classifying — don't rely on the snippet alone.

Discard clearly promotional/irrelevant emails (newsletters, generic platform alerts with no specific application behind them).

3. Scan Google Calendar (if connected)

Google Calendar:list_events for the current month (startTime/endTime first-to-last day of the month), including both past and future events. Look for interviews, calls, and screenings in the title/description/attendees.

4. Company ↔ Email/Event matching algorithm

For every email or event found:

1. Extract the sender's domain (name@company.com → company), strip TLDs (.com, .io, .co...) and common corporate suffixes (inc, ltd, llc, group, srl, spa...).
2. Compare the cleaned name against the "company" column of the database (whatever its real name is): match if one contains the other (case-insensitive).
3. Recruiting platforms/agencies (LinkedIn, Teamtailor, Greenhouse, Lever, Indeed, staffing agencies like Randstad/Adecco/Robert Half/Akkodis...): the sender's domain is NOT the company. Extract the real company name from the subject or body (e.g. "your application for [Role] at [Company]", or the client name mentioned in the text). If the agency doesn't name a specific client (a general/spontaneous application to the agency itself), use the agency name as the Company and note this in the Notes field.
4. If no matching row is found → this is a new application to create.
5. If a matching row is found → evaluate whether the status or notes need updating (see Step 5).

5. Status classification (rules)

Read the full subject + body of the email (or the calendar event description) and classify it according to these rules, from most recent/advanced. The labels below are the "standard" ones proposed in Step 0.2: if the user's database uses different labels, map onto the closest concept.

| "Standard" status | Typical signals | |---|---| | Rejected | "we've decided not to move forward", "not the right fit at this time", explicit negative outcome | | Offer Accepted | signed/accepted job offer, confirmed contract | | Technical Test | technical assessment, live coding, HackerRank/Codility, "test completed", interview with the engineering team | | Intro Call | invitation/confirmation of a call or interview (Teams/Meet/Zoom) with a recruiter or hiring manager, "intro chat", "first round" | | HR Contact | a recruiter has replied/written but without a call scheduled yet, request for more information, discussion about work mode/location | | Applied | automatic confirmation of application receipt ("thank you for applying", "we've received your resume"), no human contact yet | | No Contact | application planned but not yet submitted (rarely used in this flow) |

Priority rules:

• If a thread contains multiple stages (e.g. application → then test → then call), always use the latest stage reached, not the first one.
• In case of genuine ambiguity between two adjacent statuses, prefer the one supported by the most recent, concrete signal (e.g. a calendar invite beats a vague mention in text).
• If the Notion schema doesn't have a status that accurately represents the situation, use the closest available status and add the detail in Notes instead of forcing a new status option into the schema, unless the user explicitly asks to expand the options.

6. Write to Notion

• New application → notion-create-pages with the data_source_id as parent. You MUST populate the page properties strictly respecting the established column order in the schema array/object:

1. Company
2. Role
3. Application Status
4. Last Updated
5. Notes

Never omit a property from the creation payload if it belongs to the standard schema, even if empty, to preserve the structural visual order.- Existing application with a changed status → notion-update-page (command: update_properties) on the matching page, updating status, notes, and date.

• Don't touch existing applications if there's no new signal from email/calendar.

6.5 Duplicate detection and removal

Before producing the final report, check the full set of rows read in Step 1 (plus anything just created/updated in Step 6) for duplicates: two or more rows referring to the same company (same cleaned name per the matching rules in Step 4).

• For each group of duplicate rows for the same company, keep only the row with the most recent "Last Updated" date and treat all the others as duplicates to remove.
• If two duplicate rows are tied on "Last Updated" (same date), use the underlying page's actual last-edited timestamp (visible in notion-search results, or by comparing which row was just written in this run) as a tiebreaker, and keep the more recently edited one.
• Removal mechanism: this integration has no tool to permanently delete a Notion page. To "remove" a duplicate:

1. Rename its title to prefix it clearly, e.g. [DUPLICATO - da eliminare] (adapt the language to the user's), so it's unambiguous and easy to find later.
2. Use notion-move-pages to move it out of the database, to {"type": "workspace"} (private page at workspace level). This removes it from the tracked database/view without touching the row you're keeping.

• Never guess which row to keep based on content length or how detailed the notes look — always use the "Last Updated" date (with the edit-timestamp tiebreaker above) as the deciding factor.
• Do this automatically, without asking for confirmation first, since the action is reversible (the page still exists, just moved and relabeled, not deleted) and the criteria are deterministic. Still, always tell the user clearly in the final report which duplicates were found and that they were removed/moved (see Step 7), and mention that true permanent deletion isn't available via this integration — the person can delete the relabeled pages themselves from Notion's trash/sidebar if they want them gone for good.

7. Final report

Present the user with a text summary (a markdown table is fine) including:

• Applications added (company, role, status, brief reason)
• Applications updated (previous status → new, reason)
• Duplicates found and removed/moved (company, which row was kept vs. removed and why, i.e. the "Last Updated" dates compared), explicitly telling the user the duplicate records were removed/moved out of the database
• Any emails excluded as irrelevant (brief mention, no need to list them all)
• Any issues encountered (e.g. Notion tools unavailable on the current plan, missing connector, database created from scratch)

Notes for first-time users

• You don't need everything set up in advance: if the database, connector, or a column is missing, the skill walks you through creating them step by step, asking for confirmation before making any change to your Notion workspace.
• If you're not sure what column names or statuses you want to use, the standard schema proposed in Step 0.2 works fine — you can always rename or expand it later, directly in Notion.
• If you also receive applications/interviews in other languages, mention it: the email search keywords in Step 2 should be adapted accordingly.

Known limitations

• This skill doesn't run on its own: in a normal chat it needs to be triggered manually ("sync my job applications"). To run it automatically every N hours, you need Claude Cowork with a scheduled task (/schedule), pasting these instructions in.
• notion-query-database-view and notion-query-data-sources require a Notion Business+ plan with Notion AI: if the workspace doesn't support it, matching against existing rows has to be done via notion-search or by browsing, with a higher margin of error.
• Generic alert emails (job alerts, newsletters from learning platforms) should never be treated as job applications.
• There's no tool available to permanently delete a Notion page. Duplicate rows (see Step 6.5) are relabeled and moved out of the database rather than deleted outright; the user can permanently delete them from Notion's own trash/sidebar if they want.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: daliaabbruciati
• Source: daliaabbruciati/job-application-tracker-SKILL
• License: MIT

Install and usage instructions live in the source repository linked above.