/job-application-tracker-SKILL

name: job-application-tracker
description: Automatically syncs Gmail and Google Calendar with a Notion database to keep track of the status of job applications the user has submitted. Use this skill whenever the user asks to "sync my job applications," "update my job tracker," "check where my interviews stand," or something similar — even if they don't explicitly mention Notion, Gmail, or Calendar, and even if they don't have a Notion database set up for this yet. Requires (or guides the user through setting up) the Notion, Gmail, and Google Calendar MCP connectors.

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 -1 — Ask preferred language (always do this first, before anything else)

Before doing anything else, ask the user whether they'd like your responses (status updates, reports, notes written into Notion, etc.) in **English** or **Italian**. Use whichever language they pick for the rest of the interaction, including the final report in Step 7 and any Notes written to Notion. If the user has already stated a language preference earlier in the conversation, you can skip re-asking and just confirm it briefly.

This choice also drives the language of the Notion table itself:

• If the user picks **Italian**, and you end up creating a brand-new database (Step 0.2), build it with the Italian column names and status options (see the Italian schema variant in Step 0.2).
• If the user picks **English**, use the English schema variant instead.
• If a database **already exists**, don't rename its existing columns just because of this answer — keep using whatever language/labels it already has (per Step 0.2's "different column names" case), and simply write Notes in the user's chosen language going forward.

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.
• Gmail and Calendar are both useful but not both required: if the user wants to start with just one of the two (or neither, see 0.1b below), that's fine — flag it and proceed with what's available.
• Notion is the default backend, but it is **not mandatory**: if the user doesn't want to (or can't) connect Notion, don't block — switch to the **Excel fallback** described in 0.1a instead.

0.1a Fallback when Notion isn't available (Excel mode)

If, after being offered the connector, the user says they don't have/don't want Notion:

• Tell them you'll keep the tracker as a downloadable Excel file instead, and that — unlike the Notion mode — this mode has no persistent storage on your side: they'll need to re-upload the file each time they want a sync, and download the updated version afterwards.
• **First run**: use the `xlsx` skill to create a new spreadsheet with one sheet ("Applications"/"Candidature") using the same columns as the Notion schema in Step 0.2 (EN or IT variant, matching the language chosen in Step -1): `Company / Role / Application Status / Last Updated / Notes` (or the Italian equivalents). Save it to `/mnt/user-data/outputs/` and share it with `present_files`.
• **Subsequent runs**: ask the user to upload their current tracker file (or use one already present in `/mnt/user-data/uploads/` if they've just shared it). Read it with the `xlsx` skill, then treat each row exactly as you would a Notion page for the rest of this flow:
• Step 4 (matching), Step 5 (status classification), and Step 6.5 (duplicate detection) all apply unchanged, just operating on spreadsheet rows instead of Notion pages.
• Step 6 ("Write to Notion") becomes "write to Excel": add new rows / update matching rows' cells in place, keeping the same column order.
• For 6.5 duplicate removal: since a spreadsheet has no "move out of the database" equivalent, actually delete the duplicate row from the sheet (keeping the same keep/remove logic — most recent `Last Updated`, tie-broken as described), rather than relabeling it. Mention in the final report which duplicate rows were deleted.
• Save the updated file (new filename or same name, user's preference) to `/mnt/user-data/outputs/` and share it again with `present_files` at the end of the run.
• Everything else in the flow (Gmail scan, Calendar event creation, status classification rules, final report) works the same regardless of Notion vs. Excel mode.
• If the user changes their mind later and connects Notion, offer to import the existing Excel rows into a newly created Notion database (Step 0.2) as a one-time migration.

0.1b Fallback when Gmail isn't available

Calendar-based event detection (Step 3) and manual status updates can still work without Gmail. If Gmail isn't connected and the user doesn't want to connect it:

• Check `search_mcp_registry` for other email connectors (e.g. Outlook/other providers) in case one is available as a substitute for Gmail specifically — not just generic "email" keywords — and offer it via `suggest_connectors` if found.
• If no email connector is available at all, offer a **manual-input mode** for Step 2: ask the user to paste or summarize the relevant email content directly in chat (subject + body, or just a short description of what happened: "got a rejection from Acme today", "recruiter from Beta scheduled a call for Friday 3pm"). Classify status from that pasted/described text using the same rules as Step 5, instead of running `Gmail:search_threads`.
• If Calendar is connected but Gmail isn't, still run Step 3's logic in reverse where useful: use existing calendar events as signals for status/