mirror of https://github.com/MadsLorentzen/ai-job-search.git synced 2026-09-17 00:26:26 +00:00

Files

T

Oscar Madera e09d3eb37b fix(workflow): define tracker status enum once in /outcome, normalise readers (#299 )

* fix(workflow): define tracker status enum once in /outcome, normalise readers (#298)

The tracker CSV status column had no single authoritative definition.
Six command files restated it with inconsistent spellings, producing two
concrete bugs:

- /outcome Step 4 wrote
o response and offer declined (spaces).
  /html-report normalised only the underscore forms, so those rows matched
  no bucket and were silently dropped from the rejection-rate denominator.
- /gmail-sync Step 2 hardcoded the final-status set with space spellings,
  so a row written with underscores was never recognised as final and the
  sync kept chasing closed applications.
- /html-report included interview_only in its tracker bucket map; that
  value belongs to the archive outcome.md Status: field, not the CSV
  status column.

Fix: add a '## Tracker status vocabulary' block in /outcome (the only
CSV writer) defining the canonical underscore spellings once.  Every
reader now references that block or explicitly lists both spelling forms
as read-tolerance for existing trackers.  /outcome Step 4 writes
no_response and offer_declined.  /html-report loses interview_only and
gains offer declined as a read-tolerance variant.  /notion-sync Step 3
Status select options are aligned to the canonical spellings.

Pinned by tests/test_tracker_status_vocab.py (9 new cases following the
DraftedMeansDraftedToEveryReader CASES-table pattern).  All 205 tests pass.

framework_version: 1.3.0 -> 1.3.1

* fix(workflow): address review findings on the tracker status enum (#298)

Follow-up to ca40df2, incorporating the maintainer and issue-author reviews.

Blockers fixed:
- CHANGELOG: the #298 entry had replaced the opening line of the #286 robots
  entry, leaving its body dangling under the new fork heads-up. Restored the
  deleted line and made the #298 entry self-contained above it (MadsLorentzen).
- /notion-sync Step 4 now normalises legacy space spellings to the canonical
  underscore forms before setting the Status property. A raw push would
  auto-create a separate Notion select option per unique string, splitting
  closed applications across two filter buckets in an existing database
  (MadsLorentzen).

Issue-author findings:
- The vocabulary block now states that the space spellings are the same
  values as the underscore forms, not separate statuses, equally Final.
  Previously a reader applying the Open/Final lists literally landed on
  "not Final, not Open, undefined" for `offer declined`, and /apply Step 6b
  would refresh a closed application's row instead of appending (jakob1379).
- The block moved below Step 1's closing --- as its own section: it was
  splitting Step 1's numbered list and silently truncating section-scoped
  reads of Step 1 to item 1 (jakob1379).
- Open is derived by exclusion from the one explicit Final list, so a new
  status needs updating in a single place (jakob1379).
- /html-report's bucket map gains a case-insensitive catch-all that maps
  unrecognised values to Rejected/Closed and names them once in the status
  breakdown - the #298 failure mode with a different input (jakob1379).
- /apply Step 6b and /interview Step 0 anchor their final/open decisions to
  the vocabulary block (jakob1379).
- /gmail-sync and /html-report drop their local restatements of the
  read-tolerance rule (jakob1379).

Tests: html-report bucket assertions scoped to the Step 1 section; new pins
for the equivalence clause, open-by-exclusion, block placement, the Notion
normalisation, and the apply/interview anchors.

2026-08-07 20:47:24 +02:00

9.8 KiB

Raw Blame History

/interview - Prepare for an Interview on a Tracked Application

You are preparing the user for a real, scheduled interview on one of their applications. The frameworks for this already exist - 07-interview-prep.md (STAR examples, tough questions, questions to ask, roleplay protocol) and the Company Research Checklist in 04-job-evaluation.md - and the /outcome archive records which stage the user is at and what earlier stages surfaced. This command wires them together into a stage-specific prep pack and an optional mock interview.

/apply optimizes what the company reads; /interview optimizes what the company hears. The bridge between them is consistency: the interviewer has read the submitted CV and cover letter, so everything prepared here must match what those documents claim.

Follow these steps in order.

Step 0: Parse Input

$ARGUMENTS may contain a company name (optionally with a role), e.g. /interview acme.

With an argument: match against job_search_tracker.csv rows (case-insensitive on company, then role). One match → proceed. Several → list and ask. None → this application isn't tracked; suggest /outcome <company> to register it first, or accept the posting and role details directly if the user wants to prep anyway.
Without an argument: list tracker rows whose status suggests a live process — an open status per the Tracker status vocabulary in /outcome (interview, offer, or recently applied; drafted is open but nothing was sent, so it never qualifies) — and ask which one. If the tracker is empty, ask for the company, role, and posting.

v1 preps for a specific application. Generic no-target practice is out of scope - if asked, prep against a real tracked application instead.

Step 1: Load the Application Context

The archive (maintained by /outcome): documents/applications/<company>_<role>/
- job_posting.md - the exact posting the user applied to
- cv_draft.tex and cover_letter.tex - what was actually submitted. These are what the interviewer read; every talking point must be consistent with their claims.
- outcome.md - the stage reached so far and any recorded feedback from earlier stages. Feedback from stage N is the highest-value input for stage N+1 prep.
Fallbacks (the application may predate /outcome): posting via WebFetch on the tracker row's source URL, or ask the user to paste it; CV via cv/main_<company>*.tex and cover letter via cover_letters/cover_<company>_*.tex. State plainly which context is missing rather than guessing - and suggest /outcome <company> to build the archive for next time.
Ask the user what this interview is (skip anything outcome.md already records): stage (phone screen / technical / case / final round), date, format (phone, video, onsite), and who is interviewing (names and titles, if known).
Read the frameworks once - do not re-read them in later steps:
- .claude/skills/job-application-assistant/07-interview-prep.md
- .claude/skills/job-application-assistant/01-candidate-profile.md
- .claude/skills/job-application-assistant/02-behavioral-profile.md
- .claude/skills/job-application-assistant/04-job-evaluation.md

Step 2: Research the Company (Interview-Focused)

Execute the Company Research Checklist that 04-job-evaluation.md defines: company website (mission, values, recent news), review sites, LinkedIn (team size, recent hires), and media coverage (growth, restructuring, workplace issues).

Additions for interview purposes:

Interviewer angle: if interviewer names are known (from Step 1 or the tracker's contact_person), look up their public professional profile. A hiring manager probes team fit and motivation; a senior engineer probes technical depth; HR probes the CV timeline. Note the likely angle per interviewer - do not speculate beyond public information.
Conversation hooks: 2-3 recent, verifiable company specifics (a product launch, a stated strategic priority) the user can reference naturally in answers and in the "why this company" moment.

Verify before using: every company claim that will appear in the prep pack must be independently confirmed via WebFetch/WebSearch - same rule the repo applies to cover-letter claims. An unverified "fact" delivered confidently in an interview is worse than no fact. On a 403, retry with browser headers per .claude/skills/job-application-assistant/09-web-research.md rather than dropping to search snippets; a snippet is a lead, not a source.

Step 3: Build the Prep Pack

Assemble a stage-appropriate prep document with these sections:

1. Likely questions

Derive from four sources, in priority order:

Recorded feedback from earlier stages (outcome.md) - anything flagged, doubted, or left unresolved will come back
The fit evaluation's gaps - the requirements where the profile is weakest are the likeliest probes. For each, prepare an honest bridge answer per 07's "You don't have [X]" pattern: acknowledge, connect adjacent experience, show the learning path. Never prepare an answer that invents experience.
The posting's stated requirements - competency by competency
The stage type - phone screens get motivation and timeline questions; technical rounds get the posting's stack; final rounds get values, salary, and "any reservations" questions

2. STAR answer mapping

Match the ready-made STAR examples in 07-interview-prep.md to the likely questions using their "Use for" tags. Then:

For likely questions no existing STAR example covers, draft a new STAR answer grounded strictly in facts from 01-candidate-profile.md - profile facts arranged into S/T/A/R, not embellished. Include these drafts in the prep pack; offer to append them to 07-interview-prep.md only if the user explicitly approves.
If /setup left incomplete STAR stubs relevant to this role, surface them: the user should fill in the details before the interview.

3. Consistency brief

A short list of the specific claims the submitted CV and cover letter make (achievements, numbers, skills emphasized) that the interviewer is most likely to probe. The rule stated plainly: no claim in the room that isn't on the paper, and every claim on the paper must be defensible in depth.

4. Tough questions, customized

The relevant entries from 07's tough-question list with per-application answers - "Why this company specifically?" must use the verified hooks from Step 2, never a generic line.

5. Questions to ask

Pick 4-6 from 07's categories, customized to the research and the stage: role and team questions at screens, tech and growth questions at technical rounds, culture and leadership questions by the final round (that is the last chance to detect a deal-breaker). Cut any question the research already answers publicly - asking it signals you didn't look.

6. Logistics

The phone/video tips from 07 when the format calls for them, plus date and interviewer names as a header.

Save the pack to documents/applications/<company>_<role>/interview_prep_<stage>.md (create the folder if this application predates /outcome). The folder is gitignored, so the pack stays personal; one file per stage, so earlier packs remain as history. Present the pack in chat as well - the file is the artifact, the conversation is the delivery.

Step 4: Offer a Mock Interview

Ask if the user wants to practice. If yes, run the roleplay in this conversation following the Roleplay Guidelines in 07-interview-prep.md exactly: warm-up first, then role-specific technical questions, 1-2 behavioral questions tied to the posting's competencies, and one tough question or curveball. After each answer, give brief feedback - what worked, what to sharpen, and which STAR example from the pack would have served better.

Calibrate feedback against 02-behavioral-profile.md: coach toward the user's natural register, not a generic ideal - the same voice-consistency rule the /apply reviewer applies to cover letters.

Step 5: Close the Loop

End with:

Good luck. After the interview, run /outcome <company> to log the stage and any feedback - it sharpens the prep for the next round, and once the process resolves it feeds your fit-framework calibration via /setup.

If Step 3 drafted new STAR answers the user approved for keeps, remind them those were appended to 07-interview-prep.md (or offer again if they deferred).

Important Rules

Consistency with the submitted documents. The interviewer read the archived CV and cover letter; prep must never contradict them or coach claims beyond them.
Honesty on gaps. Weak matches get bridge answers (acknowledge → adjacent experience → learning path), never invented experience. Same rule as everywhere else in this repo.
Verified research only. Company specifics go in the pack only after independent confirmation. Interviewer notes stick to public professional information.
Stage-appropriate prep. A phone screen pack and a final-round pack are different documents; recorded feedback from earlier stages takes priority over generic question lists.
Write only to the application archive — with one exception. The prep pack lands in documents/applications/<company>_<role>/; framework files are not edited, except appending user-approved STAR examples to 07-interview-prep.md on explicit request.

The exception is 01-candidate-profile.md. Interview prep is where new facts surface most often: the user recalls a metric, corrects a scope, or fills in a STAR stub. When that happens, write the fact into the profile, as well as putting it in the prep pack. A fact recorded only in prep material reads as unsupported to a later drafting session and gets stripped from CVs as a fabrication. Prep files are not a substitute for the profile.

9.8 KiB Raw Blame History