fix(tracker): persist the application deadline end to end (#319) (#324)

The deadline is written at every moment it is provably in hand and survives
every write that follows: seen_jobs.json base field, /rank stored-value urgency
+ expiry sweep with Step 4 persistence, tracker 14th column with header-line-only
migration for existing files, /scrape-path extraction (assistant SKILL.md 1.3.2
-> 1.3.3), preserve-unparsed-fields in /outcome and /gmail-sync, notion-sync
deadline precedence. Design, scope analysis, and the folded refinements by
jakob1379 (#319, #328).

Co-authored-by: Jakob Stender Guldberg <17257805+jakob1379@users.noreply.github.com>
This commit is contained in:
Oscar Madera
2026-08-16 19:56:45 +02:00
committed by GitHub
co-authored by Jakob Stender Guldberg
parent 5c6ffe8aa7
commit c855e11d22
12 changed files with 247 additions and 16 deletions
@@ -5,7 +5,7 @@ description: >
and preparing for interviews. Triggers on keywords like: job posting, job application, CV,
cover letter, resume, interview prep, job fit, career, application, apply, ansøgning, stilling
allowed-tools: Read, Glob, Grep, WebFetch, WebSearch, Bash, Edit, Write, AskUserQuestion
framework_version: 1.3.2
framework_version: 1.3.3
---
# Job Application Assistant
@@ -40,7 +40,7 @@ When the user provides a job posting (URL or text), follow this workflow:
### Step 3b: Record the Application
- Run this once both documents exist. A CV or cover letter drafted alone is not yet an application.
- Follow **`/apply` Step 6b** (`.claude/commands/apply.md`) exactly: same header, same match-then-update rule, same `drafted` row, same posting archive, same prohibition on touching `job_scraper/seen_jobs.json`. It is stated there once so the two paths cannot drift. Three of its values are named in `/apply`'s own terms: `cv_file`/`cover_letter_file` are the paths written in Steps 2 and 3 here, `source` is the posting URL from Step 1, and the posting text item 7 archives is the one Step 1 read.
- Follow **`/apply` Step 6b** (`.claude/commands/apply.md`) exactly: same header, same match-then-update rule, same `drafted` row, same posting archive, same prohibition on touching `job_scraper/seen_jobs.json`. It is stated there once so the two paths cannot drift. Four of its values are named in `/apply`'s own terms: `cv_file`/`cover_letter_file` are the paths written in Steps 2 and 3 here, `source` is the posting URL from Step 1, `deadline` is the application deadline from the posting text Step 1 keeps verbatim (empty when the posting states none - never guess one), and the posting text item 7 archives is the one Step 1 read.
- This step exists here because `/scrape` Step 5 routes straight into this skill. Without it, that path writes two documents and records nothing.
### Step 4: Interview Preparation
+3
View File
@@ -135,6 +135,7 @@ For each new job, do a rapid fit check (NOT the full evaluation from `04-job-eva
"company": "...",
"url": "...",
"first_seen": "YYYY-MM-DD",
"deadline": "YYYY-MM-DD" | null,
"fit": "high/medium/low",
"status": "new/skipped/ranked/expired",
"portal": "<source portal skill, e.g. jobindex-search>"
@@ -147,6 +148,8 @@ The `portal` field records which CLI skill produced the job (results are already
`/rank` extends this schema additively: ranked entries also carry `rank_score` (0100 overall score), `rank_verdict` (fit band, e.g. "strong fit"), `rank_date` (ISO date of ranking), and `strengths`/`gaps` (1-3 verbatim bullets each, copied from the scoring agent's findings). The `status` field is set to `"ranked"`. Do not drop any of these fields when re-writing entries. Entries ranked before `strengths`/`gaps` existed simply lack them; readers tolerate their absence and never backfill by guessing.
`deadline` is a base field rather than a `/rank` extension: Step 2's detail fetch already extracts the application deadline, so it is written when the job is first seen and refreshed by `/rank` Step 4 when a scoring agent returns a different value. `null` means the posting states no deadline; a missing key means the entry predates this field - **never infer a deadline** from either, and never backfill by guessing.
2. Only present jobs NOT already in the seen list or tracker.
### Step 4.5: Generate Referral Contact Links (High & Medium Fit Only)
+1 -1
View File
@@ -35,7 +35,7 @@ In targeted mode, derive a slug from the job title and company for the report fi
### Aggregate mode
1. Read `job_search_tracker.csv`. Extract all rows. The columns are:
`date, company, sector, role, role_type, channel, status, contact_person, fit_rating, notes, cv_file, cover_letter_file, source`
`date, company, sector, role, role_type, channel, status, contact_person, fit_rating, notes, cv_file, cover_letter_file, source, deadline`
2. For each row, note the `role`, `company`, and `fit_rating`. The `fit_rating` column is a 0100 score where 100 = perfect fit. You will use it to weight gaps — a lower fit rating means the role exposed more gaps.
3. Read `job_scraper/seen_jobs.json`. Keep entries with `"status": "ranked"` and `rank_score >= 45` — the Moderate Fit floor from `04-job-evaluation.md` (below that, a job is Weak/Poor Fit and would otherwise dominate the heatmap with jobs the user shouldn't chase). For each kept entry, note its `title`, `company`, `rank_score`, and — when present — its recorded `gaps`. An entry with no `gaps` field (ranked before gap persistence existed) is skipped, counted, and reported once in the terminal: *"N ranked jobs were scored before gap persistence and contribute nothing; `/rank --all` re-scores them."* Never back-fill a missing `gaps` field by guessing from the title.
4. Read `.claude/skills/job-application-assistant/01-candidate-profile.md` to get the candidate's current skills and experience.