Job Search Tracker

A workflow for running a job search like a small, honest database. The agent sources roles, compares each job description (JD) against evidence the candidate can actually back up, records every role once under a stable identity, and keeps an append-only history of what happened. The point is twofold: never research or apply to the same posting twice by accident, and never let a recommendation or an application answer claim more than the candidate's records support.

Requirements

• A tracking store the agent can read and write. The recommended layout is a folder of JSON files (see record-keeping), ideally in a private git repository so changes are reviewable. A spreadsheet or a database works if it can hold the same fields. If the user already has a store, adapt to its layout and schema instead of creating a parallel one.
• The candidate's background: a profile (education, experience claims, work authorization, location and role preferences) and at least one résumé or CV.
• Web access for job boards and employer applicant-tracking-system (ATS) pages. A browser tool that reads the DOM or accessibility tree helps for pages that need interaction or a login.
• Optional: a validation script that checks records against schemas and rebuilds lookup indexes. If the store has one, run it after every write.

Configuration to read first

Before acting, find these in the user's store or ask once and save the answer:

Setting	Example	Why it matters
Store location	/path/to/career-db	Where records live.
Repository rules file	AGENTS.md or README.md in the store	Local rules override this skill's defaults.
Search categories, in priority order	new-grad-2027, campus-jobs, internship-spring	Every role belongs to exactly one category; search order follows priority.
Default search scope	Only the first two categories unless asked	Prevents sourcing roles the user has paused.
Screening criteria	"Skip roles that explicitly refuse visa sponsorship"	The only grounds the agent may use to skip a role on its own.
Conversation and file languages	Reply in the user's language; write files in English	Keep stored records consistent.
Time zone	America/New_York	Dates of user actions.
Confidentiality limits	"Employer X work: only approved claims"	Some past work must stay at a fixed level of abstraction.
Name rules	Preferred name vs. legal name	Which to use in which form field.

Treat these as the user's decisions. Do not invent a screening criterion from a hunch, a past rejection, or a weak keyword match.

Workflow

1. Read context and lessons

Read the store's rules file, the relevant schema, and the candidate's profile. If the store keeps retrospective notes on past applications (rejections, what went wrong), read the index and any case that matches the employer, role family, or failure mode. Lessons inform judgment; they are not new exclusion rules, and a hypothesis about why a rejection happened is not a fact.

2. Choose research tools

Prefer search and direct page-text or structured-data retrieval for discovering roles and reading postings. For pages that need interaction or a login, prefer a browser tool that exposes page structure; fall back to screenshots only when structure is unavailable or ambiguous. Always keep the evidence URL and note any page you could not access. Do not claim a page was checked if it was not.

3. Refresh pending roles

For each never-submitted pending role (prospect, draft_in_progress, ready_for_review), recheck the official posting.

• Confirmed closed, filled, or past deadline → move to not_applying in its original category, with a typed event recording the reason, evidence URL, check date, actor, and the user rule that applies. Keep the record so it still deduplicates.
• Page unreachable → leave it pending and report the gap. Inaccessible is not the same as closed.
• Already submitted → never apply this transition. A posting disappearing does not mean the application ended.

4. Source new roles

Search categories in the user's priority order and only within the default scope unless the user widens it for this search. Widening scope for one search does not change the default or reopen earlier skip decisions.

• Refresh to the actual execution date. When a job board sorts by posting date, rescan every listing dated today on each run (roles get added later in the day), then continue backward until you reach the date boundary already covered.
• Advance any saved search cursor only through coverage you actually completed.

5. Deduplicate before researching

Search all categories by exact employer job/requisition ID, provider, and canonical application URL before spending time on a role. Never deduplicate by title, title + company, or title + location: different requisition IDs are different jobs even if every visible field matches. If an existing record is not_applying, skip it unless the user asks to reconsider or new evidence resolves the recorded reason. Full identity rules are in record-keeping.

6. Assess fit

For each new candidate role, follow JD matching before recommending or screening it. Compare actual requirements with documented evidence, classify each as direct / transferable / unverified / confirmed gap, and assess eligibility (degree window, start date, location, work authorization, sponsorship) separately from technical fit. Never output an invented match percentage or hiring probability.

When a user-confirmed screening criterion is triggered by official employer wording, record the never-submitted role directly as not_applying with the quoted wording, URL, date, actor, and criterion. Missing information or a weak match alone is not a reason to skip.

7. Record

Create or update one record per distinct job, append timeline events (never erase history), keep status in sync with the latest status-changing event, then run the store's validator and review the diff. See record-keeping.

8. Report

Summarize, grouped by category priority and stamped with an as-of date: remaining pending roles, newly skipped roles with reasons, newly found roles with fit assessments, and any sources you could not reach.

Other jobs this skill handles

• Single JD fit check: run only step 6 on the supplied JD. Do not start a broad search, and do not create a record with a guessed job ID.
• Recruiting milestones (OA, phone screen, interview, offer, rejection): append the matching typed event; see the event table in record-keeping.
• Reusable answers: before writing a new long-form answer, adapt an existing one with the same purpose. Every claim must trace back to the profile or a résumé version. Log each use against the exact application ID as drafted or submitted.
• Remembered form fields: check stable profile facts, then remembered field choices, before pausing on a recurring application question. Rules are in record-keeping.
• Profile, project, skill, and bullet maintenance: only when the user asks for it. Follow evidence maintenance. An ordinary fit check never rewrites background facts.
• Résumé/CV versions: treat each version as an immutable snapshot with an ID and checksum; add new versions rather than editing old ones, and keep "current résumé" pointers aimed at files that exist.

Boundaries

• Research, drafting, and record-keeping are in scope. Submitting an application, accepting legal terms, opting into communications, or sending email each needs the user's explicit approval for that specific action. For email, show the exact recipients, subject, body, and attachments and get approval for that version.
• Mark a role submitted only when the user confirms it or you observe an authoritative confirmation.
• Never store passwords, tokens, government ID numbers, financial-account details, medical information, or identity documents. Store demographic answers only when the user supplied them.
• Never copy employer or lab source code, internal identifiers, internal metrics, or coworker names into the store. Anything recorded about proprietary work must be safe to say in an interview.
• Keep measurable details exact. Do not inflate scope, ownership, titles, impact, or technologies to match a JD.

Inputs and outputs

Inputs: a request (search, fit check, status update, maintenance), the tracking store, and optionally a JD or posting URL.

Outputs: updated records with appended history and provenance; a short report in the user's language listing what changed, what was checked and when, assessments with cited evidence, and open gaps or questions needing the user.

Examples

"Organize my job search and look for new roles." Read the store rules and profile → recheck four pending roles (one confirmed filled → not_applying with evidence; one page unreachable → stays pending, reported) → search the default categories through today → deduplicate eleven results by requisition ID (three already recorded, one previously skipped) → assess the seven new roles → record them → validate → report by category as of today.

"Does this JD fit me?" (pasted text for "Backend Engineer, Acme Corp") → label the source as pasted text and do not claim it is still open → table of requirements vs. evidence → "Reasonable application: direct evidence for Python APIs and PostgreSQL; transferable evidence for Kubernetes; graduation window unverified." No record is written unless the user asks.

"I got a rejection from Example Labs." → find the exact record → append rejection_received (status becomes rejected) with date, actor user, and source → validate.

License

MIT. Adapt freely.