82 lines
4.8 KiB
Markdown
82 lines
4.8 KiB
Markdown
# AGENTS.md — CharlesNWybleResume
|
||
|
||
Purpose: Give future agents a fast, reliable way to orient, make safe edits, and build outputs for this repository.
|
||
|
||
Scope: This file applies to the entire repo at this root.
|
||
|
||
## Project Summary
|
||
- Converts Markdown resume(s) into PDF and DOCX via Pandoc running in a Docker container.
|
||
- Source of truth lives in `resumes/input/*.md`.
|
||
- Outputs are written to `output/` (git-ignored).
|
||
|
||
## Layout
|
||
- `README.md` — short description and usage.
|
||
- `bin/resume-build` — shell wrapper that runs Pandoc in Docker.
|
||
- `templates/` — Pandoc assets:
|
||
- `resume-template.tex` (LaTeX template for PDF)
|
||
- `resume-reference.docx` (reference DOCX for styling)
|
||
- `resumes/input/` — Markdown sources, one file per resume variant.
|
||
- `output/` — compiled artifacts (`*.pdf`, `*.docx`).
|
||
|
||
## Build Instructions (Container-Only)
|
||
Prereqs: Docker only. No Compose, no Make.
|
||
|
||
- Build all PDFs and DOCXs (single container run): `bin/resume-build`
|
||
|
||
Notes:
|
||
- Repo is mounted at `/data` inside the container; pass paths relative to repo root.
|
||
- Override paths via env: `INPUT_DIR`, `OUTPUT_DIR`, `TEMPLATE`, `REFDOC`, `PDF_ENGINE`, `PANDOC_IMAGE` (default `danteev/texlive:latest`).
|
||
|
||
## Naming & Conventions
|
||
- File naming: prefer `CharlesNWyble-YYYY-Resume.md` (e.g., `CharlesNWyble-2025-Resume.md`). If multiple variants exist in a year, append a short suffix, e.g., `-Infra`, `-Mgmt`.
|
||
- Keep a single source file per target persona; avoid duplicating identical content.
|
||
- Use standard Markdown; do not rely on non‑portable LaTeX unless template requires it.
|
||
- Dates: Use absolute month/year ranges (e.g., `Jan 2025 – Present`). Today’s date is Oct 6, 2025; verify “Present” entries against this when updating.
|
||
|
||
## Editing Guidelines
|
||
- Before editing, skim: `templates/resume-template.tex` and the target file in `resumes/input/`.
|
||
- Keep bullets concise and outcome‑oriented; lead with impact, then tools.
|
||
- Maintain consistent section order: Summary → Key Skills → Professional Experience → Additional Tools (or as currently structured).
|
||
- Respect confidentiality: this resume is proprietary; avoid adding PII beyond what the user approves.
|
||
- When asked to add roles or adjust dates, update the active year’s Markdown file and regenerate outputs via `bin/resume-build`.
|
||
|
||
## Templates
|
||
- PDF styling comes from `templates/resume-template.tex`. Keep it minimal; changes impact all PDFs.
|
||
- DOCX styling comes from `templates/resume-reference.docx`. Update only with user approval.
|
||
- If you rename templates, update env vars `TEMPLATE`/`REFDOC` at run time or adjust `bin/resume-build` defaults if they should change.
|
||
|
||
## Common Tasks for Agents
|
||
- Add a new role:
|
||
1) Edit the relevant `resumes/input/*.md` file.
|
||
2) Update dates for previous “Present” roles if needed.
|
||
3) Run `bin/resume-build` and verify outputs appear under `output/` with no Pandoc errors.
|
||
- Create a new variant (same year): copy the most recent file in `resumes/input/`, adjust content and name using the conventions above, then run `bin/resume-build`.
|
||
- Tighten phrasing: keep bullets to a single line where possible; quantify results when available.
|
||
|
||
## Validation & Troubleshooting
|
||
- Run `bin/resume-build` to compile all sources. If a specific file fails, use the single-file build: `bin/resume-build file resumes/input/<name>.md both` to see explicit Pandoc errors.
|
||
- Path errors: remember the container’s working directory is `/data` (the repo root). Use relative repo paths or update env vars.
|
||
- LaTeX failures: the `pandoc/latex` image includes a LaTeX engine; check for malformed Markdown/LaTeX or adjust `PDF_ENGINE`.
|
||
|
||
## Safety & Performance Notes
|
||
- The TeX Live + Pandoc image is large; first pull may take several minutes.
|
||
- No host-side compilers/tools are required beyond Docker.
|
||
- Do not add third‑party assets without user approval.
|
||
|
||
## Ownership & Permissions
|
||
- The wrapper runs the container as the invoking host user via `docker run -u $(id -u):$(id -g)`.
|
||
- If outputs ever appear as `root:root`, ensure you’re running the script from a user with write access to `output/`.
|
||
|
||
## Decision Rules (Important)
|
||
- Prefer the `resume-build` container entrypoint over ad‑hoc pandoc calls to keep behavior consistent.
|
||
- When unsure about wording, prioritize clarity and measurable outcomes over tool lists.
|
||
- Preserve existing section order and formatting unless the user requests a change.
|
||
- If instructions in this AGENTS.md conflict with direct user instructions, follow the user and update this file afterward.
|
||
|
||
## Quick Orientation Checklist
|
||
1) Read `resumes/` to identify the active source file(s).
|
||
2) Confirm dates use absolute month/year and are current as of Oct 6, 2025.
|
||
3) Make requested edits in Markdown only; avoid template changes unless asked.
|
||
4) Build with `bin/resume-build`, verify PDFs/DOCXs generate in `output/`.
|
||
5) Update this AGENTS.md if you change commands, naming, or process.
|