The Problem

CV maintenance is manual drudgery: copying bullet points, reformatting layouts, and guessing at ATS alignment. Version tracking happens by accident, not design. A coding agent subscription sits idle on problems it could actually solve—structured text editing, layout preservation, keyword optimization—but the CV format makes that value hard to access.

What This Does

This repo treats the CV as LaTeX source controlled by Git, with prompt templates that coding agents can edit. The core artifact is v1/master.tex—the source-of-truth CV file. Job-specific variants live in subfolders like v1/canva/, with main.tex and job_desc.md paired alongside the base template. Prompt logic lives in prompts/job_desc_match.md, designed to feed a job description into an agent and get tailored bullet points back.

The .devcontainer/devcontainer.json provisions a full TeX Live environment so the project compiles out of the box in a container—no local LaTeX install required. A demo.mp4 in the root demonstrates the workflow, though it's a 6.8MB binary that the analysis flags as needing LFS tracking.

How It Is Wired

There is no compiled runtime, server, or framework here. The "wiring" is a three-step manual loop:

  1. Source editing: User edits v1/master.tex (the base CV). Saving inside the dev container triggers automatic PDF compilation via the LaTeX Workshop toolchain.
  2. Variant creation: To tailor for a role, a user copies the structure into a job-specific subfolder (e.g., v1/lottiefiles/), creates a main.tex variant, and populates job_desc.md with the target posting.
  3. Agent prompting: The prompts/job_desc_match.md template is fed to a coding agent along with the job description and the current master.tex. The agent returns revised bullet points or a revised main.tex.

The entry point is v1/master.tex; everything else branches from it. The call graph is simple: edit .tex → compile PDF → optionally invoke agent with prompts/job_desc_match.md. There are no hidden services, no database writes, no network calls inside the repo itself.

How To Use It

Setup (Dev Container) — prerequisites: Docker Desktop and the VS Code Dev Containers extension.

# 1. Fork the repo, then clone your fork
git clone https://github.com/moses-y/vibe-cv-resume
cd vibe-cv-resume

# 2. Open in VS Code and reopen in container
# (Click "Reopen in Container" when prompted)

# 3. Edit v1/master.tex and save — PDF renders automatically

Setup (Manual) — install the LaTeX Workshop extension for VS Code and a TeX distribution (MiKTeX, MacTeX, or TeX Live). No Docker required.

Configuration — no environment variables or API keys are required. The only config files are .gitignore, devcontainer.json, and the prompt markdown in prompts/.

Running it — the workflow is manual by design: edit the .tex source, compile, and/or feed prompts to your preferred coding agent. There is no main.py, no CLI entry point, no build command beyond pdflatex v1/master.tex (run inside the container).

Real-World Use

You're a job seeker running Claude or Cursor. You have a target role with a job description. You:

  1. Open prompts/job_desc_match.md and read the template structure.
  2. Paste the job description and your current v1/master.tex content into the agent context.
  3. Ask the agent to "revise the bullet points in master.tex to align with this job description's keywords and quantified achievements."
  4. The agent returns revised text. You paste it back into master.tex, compile, and have a tailored PDF in under a minute.

Alternatively, you create v1/lottiefiles/ for a specific application, drop a job_desc.md in that folder, and keep a parallel variant without touching the master source.

Code Health & Issues

The static analysis found these repository-wide conditions:

  • [MEDIUM] Large binary tracked in Git: demo.mp4 (6.8MB). Every clone and checkout transfers this data. Track with Git LFS or move to object storage.
  • No test files detected — untested code paths repository-wide.
  • No CI/CD pipeline detected — no automated build or test gate (no .github/workflows or equivalent).
  • No LICENSE file — unclear usage and redistribution rights.

Beyond the measured findings: the repo has no lockfile, no committed secrets, and no Dockerfile at the root (the dev container config handles the build environment).

The Bottom Line

This is a focused LaTeX CV project that repurposes coding agents for text-level editing rather than code generation. The structure is clean: a master source, prompt templates, and folder-based variant hosting. The main trade-off is the absence of automation—no CI, no tests, no license, and a large binary checked in—that makes it better suited for individual or small-team use than organizational adoption. If you want a Docker-teamed LaTeX CV you can hand to an agent to tailor per application, it works; if you need pipeline rigor or legal clearance on the code, those gaps need closing first.