vijaydr29/ai-job-search-to

1. This repository is an AI-assisted job application workflow, not a conventional app. The orchestration layer lives in Claude Code: user-facing slash commands under .claude/commands/ drive the main flows, and reusable skill content under .claude/skills/ stores the rules, prompts, and structured profile data Claude uses.

2. The core domain model is the candidate profile. It is persisted primarily in CLAUDE.md plus the structured skill files in .claude/skills/job-application-assistant/:

- candidate profile and experience

- behavioral/writing style preferences

- job evaluation rubric

- CV and cover-letter templates

- interview preparation content

These files are the authoritative source for tailoring all outputs.

3. The main workflow boundary is split into four user actions: /setup, /scrape, /apply, and /expand, with /upskill as a planning/reporting extension and /reset as cleanup. /setup establishes the profile; /scrape searches jobs; /apply generates a tailored application; /expand enriches the profile from public sources; /upskill computes skill gaps and learning plans.

4. Job discovery is implemented as separate portal-specific CLI tools in .agents/skills/. There are four independent Danish-market integrations: Jobbank, Jobdanmark, Jobindex, and Jobnet. Each has its own cli/ package with TypeScript source, helpers, tests, and a Bun-based runtime. This makes portal scraping an isolated subsystem rather than embedded in the Claude prompts.

5. The job search flow is: Claude’s /scrape command delegates to those portal CLIs, collects postings, deduplicates them, and ranks them by fit using the profile and evaluation criteria. The output is a shortlist of matches for the user to pick from, and those job records can feed directly into /apply or be tracked for /upskill.

6. The application generation flow is a drafter-reviewer pipeline. /apply takes either a job URL or pasted description, parses it, scores fit, drafts tailored materials, then spawns a second reviewer agent that critiques the application from a fresh context. The drafter revises based on that feedback, so the architecture intentionally separates creation from review.

7. A major technical boundary is document production. The CV and cover letter are generated as LaTeX, not plain text:

- cv/ contains the CV template, based on moderncv

- cover_letters/ contains a custom cover.cls and bundled fonts

The workflow compiles PDFs and inspects the rendered output, so layout correctness is part of the system design, not an afterthought.

8. The PDF verification loop is central to the repo’s architecture. The system recompiles until the CV is exactly two pages and the cover letter exactly one page, checking for layout issues like orphaned headings, font mismatches, and overflow. This means the output layer is a real feedback loop between generated LaTeX and rendered PDFs.

9. Several filesystem areas act as stateful inputs/outputs for the workflows:

- documents/ holds source material for onboarding and enrichment

- job_scraper/ stores scraper state such as seen jobs

- job_search_tracker.csv tracks applications

- upskill/ stores learning-plan reports

- salary_lookup.py and tools/ support optional compensation benchmarking

These are not runtime services; they are persistent working directories and artifacts.

10. The repository has a clear separation between framework rules and user-specific content. Framework behavior lives in command files, skill definitions, and setup instructions. User-specific career data is meant to be filled into CLAUDE.md, the skill markdown files, and the documents/ folder, which keeps the system portable across candidates.

11. External dependencies materially shape the architecture: Claude Code provides the agent runtime and command surface, Bun runs the Danish job-search CLIs, Python supports salary conversion/lookup tooling, and LaTeX with lualatex/xelatex is required for final document generation. The job portal integrations and salary data are intentionally pluggable rather than hard-coded to one provider.

12. Overall, the system is best diagrammed as an agent-driven pipeline with three layers: profile knowledge, job discovery, and application production. Profile data feeds both search ranking and application tailoring; job postings flow from portal CLIs into evaluation and drafting; final artifacts flow out as PDFs, tracked applications, and optional salary or upskilling reports.