Skill

job-tracker

This skill should be used when the user runs /check-apps or asks to check job applications, scan Gmail for application updates, update the job tracker, sync application status, check for interview invitations, look for rejection emails, or ask about the status of their applications. It provides email classification rules, entity extraction logic, stage progression constraints, and sheet update constraints for the aerion job application tracking workflow.

From aerion
Install
1
Run in your terminal
$
npx claudepluginhub luqmannurhakimbazman/ashford --plugin aerion
Tool Access

This skill uses the workspace's default tool permissions.

Supporting Assets
View in Repository
references/email-patterns.md
Skill Content

Job Application Tracker

Track job application status by scanning Gmail and updating the Google Sheets "Job Tracker" in the hojicha Drive folder.

Target Email

lluqmannurhakim@gmail.com

Sheet Schema

The Job Tracker sheet has these columns (in order):

ColumnTypeValues
A: CompanyTextCompany name
B: RoleTextRole/position title
C: StageDropdownApplied, Phone Screen, Online Assessment, Behavioral Interview, Onsite Interview, Rejected, Ghosted, Offered
D: Last Contact DateDateYYYY-MM-DD format
E: NotesTextAppend-only summary notes

Sheet tab name: job-tracker. Always use list_sheets to confirm if unsure.

Email Classification

Classify each email into a Stage using signals from the subject line, body, and sender. Refer to references/email-patterns.md for the full pattern catalog.

Stage mapping priority: If an email matches multiple stages, use the most advanced stage. For example, an email mentioning both "application received" and "online assessment link" maps to Online Assessment.

Stage Progression Rules

Stages have a natural forward order:

Applied → Phone Screen → Online Assessment → Behavioral Interview → Onsite Interview → Offered
(Rejected/Ghosted can override any stage — they are terminal states)

Rules:

  1. A stage update can only move forward in the progression above.
  2. Rejected and Ghosted can override any stage (they are terminal states).
  3. Never regress a stage (e.g., if currently at Onsite Interview, ignore an old "application received" email).
  4. Ghosted is only suggested when there is no email activity for >30 days since the Last Contact Date. Always ask the user for confirmation before marking Ghosted.

Entity Extraction

For each email, extract:

  • Company — the hiring company name
  • Role — the position title
  • Stage — inferred from email classification
  • Date — the email's sent date (for Last Contact Date)
  • Note — a one-line summary of the email content (e.g., "Received OA link via HackerRank", "Rejection — position filled")

Use the fallback order in references/email-patterns.md for entity extraction when company/role are not obvious.

Matching Rules

Match emails to existing sheet rows by Company + Role (case-insensitive, fuzzy). Examples:

  • "Citadel Securities" matches "Citadel" — same company
  • "Software Engineer, Infrastructure" matches "SWE Infra" — use judgment on abbreviations

When in doubt, flag as ambiguous. If you are not confident that a company or role name refers to an existing row, do not silently create a duplicate — present it as ambiguous and let the user confirm the match or create a new row.

If no match is found and the email indicates a new application, create a new row with Stage = Applied.

Update Rules

  1. Existing row, stage change: Update Stage column. Update Last Contact Date. Append to Notes.
  2. Existing row, no stage change: Update Last Contact Date. Append to Notes.
  3. New application: Add row with Company, Role, Stage = Applied, Last Contact Date = email date, Notes = summary.
  4. Ambiguous email: Cannot determine company, role, or stage — flag for user with email subject, sender, and a snippet. Never skip silently.

Notes Column

  • Append, never overwrite. Add new notes on a new line prefixed with the date.
  • Format: YYYY-MM-DD: <summary>
  • Example: 2026-02-26: Received OA link via CodeSignal

Output Format

After scanning, present results to the user in this format:

Updates (existing rows)

| Company | Role | Old Stage | New Stage | Note |
|---------|------|-----------|-----------|------|
| Citadel | Quant Researcher | Applied | Online Assessment | Received OA link |

New Applications

| Company | Role | Note |
|---------|------|------|
| Jane Street | SWE Intern | Application confirmation email |

Ambiguous (needs your input)

- Email from recruiter@google.com (subject: "Quick question") — cannot determine role. Skip or provide details?

No Changes

If no relevant emails found, say so.

After presenting: Ask the user to confirm before writing any changes to the sheet.

Write Safety Rules

NEVER use add_rows to append data

The add_rows tool inserts blank rows at the TOP of the sheet by default (when start_row is omitted), which shifts all existing data down and corrupts pre-calculated cell ranges. Instead:

  1. To append new applications: Use update_cells targeting the first empty row. If the last data row is row 32, write to range A33:E33.
  2. To update existing rows: Use update_cells with the exact cell range (e.g., C5 to update a stage).
  3. add_rows is banned unless the sheet grid physically has no empty rows left. If you must use it, you MUST set start_row to the last row index so rows are added at the bottom, never the top.

Pre-write snapshot

Immediately before ANY write operation, re-read the full sheet with get_sheet_data. This fresh snapshot is your baseline — do not rely on earlier reads (data may have changed).

Important: Tell the user not to edit the sheet until writes are complete. There is a short window between reading the snapshot and writing where manual edits could be overwritten.

Calculate all target cell ranges from this snapshot. For appends, find the last occupied row and target the next row.

Post-write verification (new rows only)

After appending new rows, re-read the sheet and verify:

  • All pre-existing rows from the snapshot are unchanged (same values, same positions)
  • New rows appear at the expected positions with correct values

On verification failure

If any mismatch is detected:

  1. Stop immediately — do not attempt further writes
  2. Present the mismatch — show expected vs actual values, which rows shifted or were overwritten
  3. Propose a recovery plan — list specific update_cells calls that would restore the original data from the cached snapshot
  4. Wait for user confirmation — do NOT execute recovery automatically

Tool Reference

Tool name prefixes vary by environment. On local Claude Code they use mcp__plugin_aerion_gmail__ and mcp__plugin_aerion_google-sheets__. On Cowork they may use different prefixes (e.g., connector names or UUIDs). Look up available tools by function name, not prefix.

ActionFunction name to look for
Search emailsgmail_search_messages or Search Gmail Emails
Read emailgmail_read_message or Read Gmail Email
Read email threadgmail_read_thread or Read Gmail Thread
List spreadsheetslist_spreadsheets
List sheet tabslist_sheets
Read sheet dataget_sheet_data
Update cellsupdate_cells
Add rowsadd_rows
Similar Skills
cache-components

Expert guidance for Next.js Cache Components and Partial Prerendering (PPR). **PROACTIVE ACTIVATION**: Use this skill automatically when working in Next.js projects that have `cacheComponents: true` in their next.config.ts/next.config.js. When this config is detected, proactively apply Cache Components patterns and best practices to all React Server Component implementations. **DETECTION**: At the start of a session in a Next.js project, check for `cacheComponents: true` in next.config. If enabled, this skill's patterns should guide all component authoring, data fetching, and caching decisions. **USE CASES**: Implementing 'use cache' directive, configuring cache lifetimes with cacheLife(), tagging cached data with cacheTag(), invalidating caches with updateTag()/revalidateTag(), optimizing static vs dynamic content boundaries, debugging cache issues, and reviewing Cache Component implementations.

138.5k
Stats
Parent Repo Stars0
Parent Repo Forks0
Last CommitMar 14, 2026