How It Works

The resume agent is a staged workflow, not one long prompt. It reads candidate truth from candidate-profile, pulls evidence from the pool, processes one JD at a time, and writes only at the stages that are supposed to persist state.

For live runs, treat resume-pipeline-orchestrator as the operational source of truth for control flow. In the current repo contract, JDs are fetched in a batch, then processed sequentially; JDs that are disqualified, fail the binary gate, or score below 40 are skipped, and JDs at 40+ continue downstream one at a time.

End-to-end flow

1. Run profile-bootstrap locally for a new candidate to replace the repository placeholders with real candidate and runtime values.
2. Confirm candidate-profile/SKILL.md is filled with the current candidate's real facts, not template content.
3. Only after that, add the remaining resume skills to Hermes.
4. Add evidence into the pool with pool-intake, which takes the user's markdown files and places them into the right runtime location and format.
5. Fetch unprocessed JDs through resume-pipeline-orchestrator.
6. Run jd-prefilter to skip obvious non-fits quickly.
7. Run jd-extraction on passing JDs.
8. Run project-selection against masters.md to choose 3 supporting projects or OSS items.
9. Run point-repointing to tailor selected projects plus all work experience.
10. Run latex-assembly to produce the final .tex.
11. Run the orchestrator self-review gate.
12. Push the resume, mark the JD processed, and log the run.

Write boundaries

• Read-only stages: candidate-profile, jd-prefilter, jd-extraction, project-selection
• Pool-writing stage: point-repointing
• Resume-writing stage: latex-assembly plus local .tex save
• Dashboard API stage: resume-pipeline-orchestrator

Operator flow

For a new operator, the flow starts with candidate setup, then evidence intake, then orchestration.

• profile-bootstrap is the first setup action.
• candidate-profile must be real before the other skills are treated as usable.
• pool-intake prepares evidence by placing user files in the right runtime location and creating the initialization files the pipeline needs.

Internal orchestration

Inside the orchestrator, the run becomes a stage-by-stage execution flow with API side effects and structured candidate inputs.

• candidate-profile provides candidate-specific truth.
• Pool evidence supports selection and tailoring.
• API calls happen at fetch, push, status update, and logging boundaries.

What writes where

Stage	Writes files?	Calls dashboard APIs?	Output
candidate-profile	No	No	Candidate truth
pool-intake	Yes	No	raw.md, idx.md, versions/, optionally masters.md
jd-prefilter	No	No	Pass/skip decision and score
jd-extraction	No	No	JD extraction artifact
project-selection	No	No	3 selected projects/OSS items
point-repointing	Yes	No	New version files and updated idx.md
latex-assembly	No pool writes; produces .tex content for save	No	Resume LaTeX
resume-pipeline-orchestrator	Saves .tex locally	Yes	Resume push, PATCH /use, workflow logs

Continue to Setup Guide for the first-time operator path. That setup page should be read before this one by a new operator.

If you want the actual skills and file contracts behind this flow, use the public source repository.

hermes-autonomous-resume on GitHub