dennisthiessenandClaude Opus 5
afdef7eb94
Checkpoint for the 2026-09-11 project review remediation. Work by a previous agent that ran out of context; committed unchanged as a rollback point before the remaining findings land on top of it. F01 — the two agent directories had drifted into different processes - Six shared workflows under `resume_builder/reference/workflows/`; both `.agents/skills/` and `.claude/skills/` are now thin entrypoints that route to the same file instead of carrying full copies. - The `.claude` copies were the stale side: fixed bullet line variants and character budgets that the newer process had already dropped. Removing them is the point of the change, not collateral. - Parity/link regression test added; corrected the top-level file map, which pointed at a directory that does not exist. F02 — application status was stored in four places and disagreed - New registry `job_scout/state/applications.json` (26 records) with `application_records.py` (schema, validation, transactional write) and `application_tracker.py` (add/update, no quota). - AGENTS.md and CLAUDE.md no longer keep their own status tables; both point at `current_applications.md`, generated from the registry. - Interview-reached is now independent of outcome, so a withdrawal after an interview can record both facts. The old tables are preserved verbatim in `job_scout/state/history/application_status_before_2026-09-11.json`. Verification: `python -m unittest discover -s tests -v` — 18/18 pass. Spot-checked that the detailed SBB and Kdo Cy notes survived the migration into the registry rather than being flattened. Known unresolved, deliberately not invented (see FIX_PROGRESS.md): Aker BP's application date and its Adjacent-despite-79 classification. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qej5SBvhcbGXHwLqNWiskM
87 lines
3.4 KiB
Markdown
87 lines
3.4 KiB
Markdown
<!-- Shared workflow version: 2026-09-11 -->
|
|
|
|
# Generate a Resume
|
|
|
|
## Input
|
|
|
|
Accept a JD file, pasted JD, or URL. Obtain the real posting text before analysis. If it cannot be retrieved, ask the user to paste it; never reconstruct it.
|
|
|
|
## Phase 0 — Canonical and JD Preflight
|
|
|
|
1. Read `resume_builder/reference/shared_ops.md`.
|
|
2. Read `resume_builder/canonical/claims.json` completely.
|
|
3. Read `config.md`, `AGENTS.md`, `application_strategy.md`, `resume_reference.md`, and `critique_framework.md`.
|
|
4. Run `python resume_builder/helpers/validate_resume_system.py`.
|
|
5. Verify and save the verbatim JD; record source/date/status.
|
|
6. Create the output folder and session from `session_file_template.md`.
|
|
|
|
## Phase 1 — Fit Gate Before Writing
|
|
|
|
Build a requirement table with Required/Preferred and Direct/Adjacent/Gap/Constraint classifications. Cite canonical claim IDs for every Direct or Adjacent match.
|
|
|
|
Compute Evidence Fit and identify hard gates using `critique_framework.md`. Then assign:
|
|
|
|
- Core.
|
|
- Adjacent.
|
|
- Stretch.
|
|
- No-go.
|
|
|
|
Record Channel Strength and a warm-channel action for Core roles.
|
|
|
|
Stop and present the fit decision before resume planning when:
|
|
|
|
- a hard gate fails;
|
|
- the role is Stretch;
|
|
- a practical constraint is unresolved.
|
|
|
|
Proceed on a no-go only after the user explicitly overrides the stated reason. An override does not change the fit classification.
|
|
|
|
## Phase 2 — Audience and Content Plan
|
|
|
|
Select International Tech by default. Use Swiss/DACH or Employer-specific format only when the employer/context supports it.
|
|
|
|
Read the matching role bundle, `skills_taxonomy.md`, `achievement_reframing_guide.md`, and only the experience files needed for selected claims.
|
|
|
|
Plan:
|
|
|
|
- Optional 2--3 line summary.
|
|
- Four to six evidence-backed skills lines.
|
|
- Swisscom 4--5 bullets.
|
|
- Bosch 3--4 bullets.
|
|
- Zero or one bullet for each older role.
|
|
- Normally 11--14 bullets total, with no page-fill quota.
|
|
|
|
For each proposed bullet show canonical ID, evidence type, scope, and why it belongs. Identify any impact metric that still needs user confirmation.
|
|
|
|
Apply `cl_reference.md` and propose `Cover Letter Decision: YES/NO` with one reason.
|
|
|
|
Present the plan and wait for explicit user confirmation before generation.
|
|
|
|
## Phase 3 — Generate
|
|
|
|
Copy `resume.cls` and `resume_template.tex` into the output folder. For a Swiss/DACH audience, also read `resume_template_dach.tex` as an audience-policy overlay; it is not a standalone document. Write fresh content from canonical claims and experience records; never copy a historical output.
|
|
|
|
Rules:
|
|
|
|
- Employer, formal/transparent title, dates and location come first.
|
|
- Do not use tailored themes as job titles.
|
|
- Mix natural bullet lengths.
|
|
- Use only verified metrics and outcomes.
|
|
- Preserve allowed verbs and ownership scope.
|
|
- Never add a skill to mirror the JD.
|
|
- Certifications appear once.
|
|
|
|
## Phase 4 — Validate and Inspect
|
|
|
|
Run:
|
|
|
|
```powershell
|
|
python resume_builder/helpers/validate_resume_system.py --document <resume.tex>
|
|
```
|
|
|
|
Fix every failure. Compile the LaTeX, inspect both pages, and run `pdftotext` to verify parsing and information order. Do not add filler to reduce whitespace.
|
|
|
|
Update the session with the as-built content, validation results, page count, cover-letter decision, and next action.
|
|
|
|
Present the finished resume and the original Evidence Fit classification. Wait for approval. If the cover-letter decision is YES, point to `/make-cl`; otherwise point directly to `/critique`.
|