refactor: shared agent workflows (F01) and one application registry (F02)
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
This commit is contained in:
dennisthiessenandClaude Opus 5 committed
1 parent
0d999ab21b
commit
afdef7eb94
33 files changed
+1558
-1768
No files matched your search
@@ -3,60 +3,8 @@ name: critique
|
||||
description: Critique an existing resume or cover-letter package against its real job description. Use for application-fit review, truth/provenance audit, recruiter and hiring-manager evaluation, separate Evidence Fit and Document Quality scoring, channel-strength assessment, and post-edit re-critique.
|
||||
---
|
||||
|
||||
# Critique an Application Package
|
||||
# Shared project workflow
|
||||
|
||||
## Startup
|
||||
Read and follow [the critique workflow](../../../resume_builder/reference/workflows/critique.md) before doing this task. Resolve project paths from the repository root.
|
||||
|
||||
1. Read `resume_builder/reference/shared_ops.md`.
|
||||
2. Read `resume_builder/canonical/claims.json` completely.
|
||||
3. Read `config.md`, the session file, and the real verbatim JD.
|
||||
4. Stop if the JD is reconstructed, incomplete or inferred.
|
||||
5. Read `resume_builder/reference/critique_framework.md` and `resume_builder/support/ai_fingerprint_rules.md`.
|
||||
6. Read the resume and optional cover letter. Never use either as evidence; verify against canonical claims and experience files.
|
||||
|
||||
## Preflight
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
python resume_builder/helpers/validate_resume_system.py --document <resume.tex>
|
||||
```
|
||||
|
||||
Add `--document <cover_letter.tex>` when a letter exists. Any failure is Tier 1 and prevents approval.
|
||||
|
||||
Compile the documents and inspect the PDFs. Extract resume text with `pdftotext` and confirm that employer, formal title and dates appear in the expected order.
|
||||
|
||||
## Critique
|
||||
|
||||
Follow `critique_framework.md` exactly:
|
||||
|
||||
1. Hard-gate audit.
|
||||
2. Evidence Fit score, independent of writing.
|
||||
3. Document Quality score, independent of role fit.
|
||||
4. Channel Strength rating.
|
||||
5. Competitive and reader-sequence assessment.
|
||||
6. Canonical claim audit.
|
||||
7. Tiered fixes.
|
||||
8. Cover-letter decision/critique.
|
||||
9. Mechanical verification.
|
||||
|
||||
Do not issue a single overall score. Do not label a high-quality document submit-ready when Evidence Fit fails a hard gate.
|
||||
|
||||
## Cover-Letter Handling
|
||||
|
||||
If the session records `Cover Letter Decision: NO`, do not penalize absence. If a letter exists, first assess whether it should exist under `cl_reference.md`.
|
||||
|
||||
## Save and Report
|
||||
|
||||
Save `output/<Folder>/critique_<name>.md`. Update the session with:
|
||||
|
||||
- Evidence Fit score and Core/Adjacent/Stretch classification.
|
||||
- Hard-gate result.
|
||||
- Document Quality score.
|
||||
- Channel Strength.
|
||||
- Tier 1 fixes.
|
||||
- Critique status and date.
|
||||
|
||||
Present the fit verdict first, then the two scores and actionable fixes. Wait for explicit user approval before finalization or editing.
|
||||
|
||||
When approved, run the finalization checks from `shared_ops.md`. A package with a hard-gate NO-GO may be archived, but must not be described as recommended for submission.
|
||||
This shared file is the only workflow implementation for both agents. Preserve existing user authorization and resume from the application's recorded state.
|
||||
@@ -3,49 +3,8 @@ name: edit-resume
|
||||
description: Edit an existing resume or cover letter from critique or user feedback. Use to make evidence-safe content, hierarchy, format, or readability changes while preserving canonical claims, revalidating role fit, compiling LaTeX, and recording the edit.
|
||||
---
|
||||
|
||||
# Edit a Resume or Cover Letter
|
||||
# Shared project workflow
|
||||
|
||||
## Startup
|
||||
Read and follow [the edit-resume workflow](../../../resume_builder/reference/workflows/edit-resume.md) before doing this task. Resolve project paths from the repository root.
|
||||
|
||||
1. Read `shared_ops.md` and `resume_builder/canonical/claims.json` completely.
|
||||
2. Run the system validator.
|
||||
3. Read the session, real JD, target `.tex`, critique/feedback, selected profile rules and relevant experience files.
|
||||
4. Check `historical_outputs.json`. A package marked unsafe must be regenerated from canonical sources rather than lightly polished.
|
||||
5. If the package was already submitted, preserve it as history. Create a clearly named new version only when the user requests a reusable corrected document.
|
||||
|
||||
## Diagnose
|
||||
|
||||
Classify requested changes as:
|
||||
|
||||
- Truth/provenance correction.
|
||||
- Fit/framing correction.
|
||||
- Information hierarchy or readability.
|
||||
- Content selection.
|
||||
- Mechanical/LaTeX.
|
||||
- Blocked because evidence is absent.
|
||||
|
||||
Do not treat whitespace, equal bullet lengths or an exact character target as defects. Do not add filler. A critique cannot authorize an unsupported claim.
|
||||
|
||||
Present a concise edit plan and wait for explicit confirmation unless the user already approved specific edits.
|
||||
|
||||
## Execute
|
||||
|
||||
- Source every work claim from canonical IDs and experience files.
|
||||
- Keep employer/title/date hierarchy conventional.
|
||||
- Preserve natural bullet lengths and verified ownership scope.
|
||||
- Remove unsupported skills rather than replacing them with synonyms.
|
||||
- Update a cover letter only when its session decision is YES or the user explicitly requests it.
|
||||
- If edits reveal a hard fit gate, update the Evidence Fit classification; writing improvements cannot remove the gate.
|
||||
|
||||
## Verify
|
||||
|
||||
Run the validator on every edited document, compile, inspect the PDF, and verify extracted text order. Compare before/after for:
|
||||
|
||||
- validator failures;
|
||||
- page count;
|
||||
- employer/title/date visibility;
|
||||
- bullet count and relevance;
|
||||
- duplicated sections;
|
||||
- readability at normal size.
|
||||
|
||||
Update the session Edit History, Document Quality, status and next action. Mark the critique stale after material edits. Present results and wait for approval.
|
||||
This shared file is the only workflow implementation for both agents. Preserve existing user authorization and resume from the application's recorded state.
|
||||
@@ -3,43 +3,8 @@ name: make-cl
|
||||
description: Decide whether a cover letter adds value and, when justified, generate a concise evidence-first LaTeX letter from an approved session and resume. Use for requested letters, Swiss/DACH motivation letters, meaningful transitions, or employer-specific formats; skip generic optional letters.
|
||||
---
|
||||
|
||||
# Decide and Generate a Cover Letter
|
||||
# Shared project workflow
|
||||
|
||||
## Startup
|
||||
Read and follow [the make-cl workflow](../../../resume_builder/reference/workflows/make-cl.md) before doing this task. Resolve project paths from the repository root.
|
||||
|
||||
1. Read `shared_ops.md`, `resume_builder/canonical/claims.json`, `cl_reference.md`, the session, real JD and finished resume.
|
||||
2. Run the validator on the resume.
|
||||
3. Confirm that the session has a completed resume and a recorded Cover Letter Decision.
|
||||
|
||||
## Decision Gate
|
||||
|
||||
If the session says NO, explain the recorded reason and stop unless the user explicitly asks to override it. If no decision exists, apply `cl_reference.md` before writing and record YES/NO.
|
||||
|
||||
Do not generate a letter merely because an upload field exists or because older workflow expected a three-page package.
|
||||
|
||||
## Plan
|
||||
|
||||
State in one sentence what the letter adds beyond the resume. Select at most two evidence themes. Verify any named company/product/programme hook from a current primary source and save its URL in the session.
|
||||
|
||||
If the only possible content repeats resume bullets or paraphrases company news, change the decision to NO and explain why.
|
||||
|
||||
## Generate
|
||||
|
||||
- Use the selected audience profile and employer-requested language.
|
||||
- International Tech/industry: normally 200--300 words in two or three paragraphs.
|
||||
- Swiss/DACH: one A4 page, appropriate formality.
|
||||
- Employer-specific: follow the requested format or portal limit.
|
||||
- Lead with candidate-role connection.
|
||||
- Add motivation, decision context or a genuine connection.
|
||||
- Use only claims already present in both the canonical registry and resume.
|
||||
- Never introduce a new tool, metric, customer, ownership claim or result.
|
||||
|
||||
## Verify
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
python resume_builder/helpers/validate_resume_system.py --document <resume.tex> --document <cover_letter.tex>
|
||||
```
|
||||
|
||||
Compile and inspect the letter. Confirm it is readable, within the employer's limit, and materially different from the resume. Update the session and present the letter for approval. Point to `/critique` next.
|
||||
This shared file is the only workflow implementation for both agents. Preserve existing user authorization and resume from the application's recorded state.
|
||||
@@ -3,88 +3,8 @@ name: make-resume
|
||||
description: Generate a tailored evidence-first resume from a real job description. Use for new applications to assess hard qualifications and role fit before writing, select International Tech or Swiss/DACH format, plan canonical achievements, generate LaTeX, validate claims, compile, and record the application decision.
|
||||
---
|
||||
|
||||
# Generate a Resume
|
||||
# Shared project workflow
|
||||
|
||||
## Input
|
||||
Read and follow [the make-resume workflow](../../../resume_builder/reference/workflows/make-resume.md) before doing this task. Resolve project paths from the repository root.
|
||||
|
||||
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;
|
||||
- the selected cohort category is already full;
|
||||
- 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`.
|
||||
This shared file is the only workflow implementation for both agents. Preserve existing user authorization and resume from the application's recorded state.
|
||||
@@ -3,80 +3,8 @@ name: setup-build-kb
|
||||
description: Build or update the resume knowledge base from structured extractions. Use to normalize employment evidence, maintain the canonical claims registry, add achievements with ownership and metric status, update evidence-tiered skills and role bundles, propagate corrections, and validate the full resume system.
|
||||
---
|
||||
|
||||
# Build or Update the Knowledge Base
|
||||
# Shared project workflow
|
||||
|
||||
## Authority Model
|
||||
Read and follow [the setup-build-kb workflow](../../../resume_builder/reference/workflows/setup-build-kb.md) before doing this task. Resolve project paths from the repository root.
|
||||
|
||||
The pipeline is:
|
||||
|
||||
`source documents -> extractions -> canonical claims -> experience records/bundles -> generated applications`
|
||||
|
||||
Generated applications never flow backward into the KB.
|
||||
|
||||
Read `resume_builder/canonical/claims.json`, `config.md`, and all relevant extractions before changing normalized sources. Preserve raw source documents. A verified correction must update canonical claims first and then every dependent normalized file.
|
||||
|
||||
## Canonical Claim Record
|
||||
|
||||
For each employment item or achievement, record:
|
||||
|
||||
- stable ID;
|
||||
- employer, title, dates and location;
|
||||
- factual scope;
|
||||
- individual vs shared ownership;
|
||||
- allowed verbs;
|
||||
- forbidden overstatements;
|
||||
- metric/result and verification status;
|
||||
- evidence source;
|
||||
- last verified date.
|
||||
|
||||
When ownership is ambiguous, use contributing/shared scope and ask the user. Do not default to full ownership.
|
||||
|
||||
## Experience Files
|
||||
|
||||
Experience files explain facts and context. They may contain example phrasings, but those examples cannot override canonical scope and should not be optimized to fixed line counts.
|
||||
|
||||
Every achievement section must include canonical ID, source, ownership scope, status, verified result/metric state, relevant skills and role relevance.
|
||||
|
||||
## Skills Taxonomy
|
||||
|
||||
Use only these evidence levels:
|
||||
|
||||
- Production — current.
|
||||
- Production — historical.
|
||||
- Hands-on — current.
|
||||
- Project / proof of concept.
|
||||
- Certification / coursework.
|
||||
- Unverified / never used.
|
||||
|
||||
Do not assign Expert/Proficient/Familiar labels. Add a skill to canonical claims before it can appear in a generated document.
|
||||
|
||||
## Role Bundles
|
||||
|
||||
Each bundle must contain:
|
||||
|
||||
1. Defensible positioning.
|
||||
2. Good-fit roles and hard-gate cautions.
|
||||
3. Achievement priorities.
|
||||
4. Safe reframing rules.
|
||||
5. Evidence-backed skills guidance.
|
||||
6. Conditional cover-letter guidance.
|
||||
|
||||
Bundles may rank evidence; they may not broaden it. Title-defining gaps must be stated explicitly.
|
||||
|
||||
## Significance Context
|
||||
|
||||
Keep company/industry context separate from candidate impact. Mark external claims for re-verification at application time. Never attach generic scale, economics, customers or market trends to the candidate.
|
||||
|
||||
## Correction Propagation
|
||||
|
||||
After any correction, search canonical claims, config, extractions, experience files, bundles, support files, templates and active drafts. Historical submitted outputs remain unchanged but update `historical_outputs.json` when they become unsafe for reuse.
|
||||
|
||||
## Validation
|
||||
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
python resume_builder/helpers/validate_resume_system.py
|
||||
```
|
||||
|
||||
Then review the diff for dates, titles, ownership, metrics and skill evidence. Present the changed claim records and affected downstream files to the user for confirmation.
|
||||
This shared file is the only workflow implementation for both agents. Preserve existing user authorization and resume from the application's recorded state.
|
||||
@@ -3,99 +3,8 @@ name: setup-extract
|
||||
description: Extract source-grounded career evidence from papers, employment records, project documents, and notes into structured knowledge-base files without promoting inference to fact.
|
||||
---
|
||||
|
||||
# Source Evidence Extraction
|
||||
# Shared project workflow
|
||||
|
||||
Use this skill when adding new evidence to `knowledge_base/extractions/`. Extraction preserves what a source supports; it does not tailor claims to a vacancy.
|
||||
Read and follow [the setup-extract workflow](../../../resume_builder/reference/workflows/setup-extract.md) before doing this task. Resolve project paths from the repository root.
|
||||
|
||||
## Required inputs
|
||||
|
||||
1. Read `config.md` and the anti-fabrication rules in `AGENTS.md`.
|
||||
2. Read the complete source material.
|
||||
3. Check `resume_builder/canonical/claims.json` for existing facts and identifiers.
|
||||
4. Inspect related extraction files so new evidence does not create a duplicate or contradiction.
|
||||
|
||||
Generated resumes, cover letters, critiques, and session files under `output/` are never evidence sources.
|
||||
|
||||
## Extraction procedure
|
||||
|
||||
### 1. Identify the source
|
||||
|
||||
Record:
|
||||
|
||||
- source filename and type;
|
||||
- source date, if known;
|
||||
- whether it is primary evidence, user-authored notes, or a secondary description;
|
||||
- the person, employer, project, or publication it concerns.
|
||||
|
||||
### 2. Separate evidence from inference
|
||||
|
||||
For every potentially reusable fact, record:
|
||||
|
||||
- the source-supported statement;
|
||||
- the exact supporting passage or precise location;
|
||||
- any interpretation separately as `Inference`;
|
||||
- confidence: `verified`, `user-confirmed`, `needs verification`, or `do not use`.
|
||||
|
||||
Never silently convert an inference into a verified claim.
|
||||
|
||||
### 3. Capture career facts precisely
|
||||
|
||||
When applicable, extract:
|
||||
|
||||
- exact employer, formal title, location, and start/end dates;
|
||||
- ownership scope and collaborators;
|
||||
- work performed, method, technology, and domain;
|
||||
- outcome and beneficiary;
|
||||
- metrics with units, baseline, period, and attribution;
|
||||
- publication status, authorship position, and venue;
|
||||
- current versus historical skill use;
|
||||
- certification versus practical experience.
|
||||
|
||||
For large-company work, describe only the user's component, domain, pipeline, service, or contribution. Do not infer ownership of organization-wide platforms or transformations.
|
||||
|
||||
### 4. Record claim controls
|
||||
|
||||
For each major claim, include where useful:
|
||||
|
||||
- allowed verbs;
|
||||
- verbs or framings that would overstate ownership;
|
||||
- safe resume wording;
|
||||
- known contradictions requiring resolution;
|
||||
- whether a metric is verified, qualitative only, or still missing.
|
||||
|
||||
### 5. Write the extraction
|
||||
|
||||
Create or update a focused Markdown file in `knowledge_base/extractions/`. Use a clear structure such as:
|
||||
|
||||
```markdown
|
||||
# Subject
|
||||
|
||||
## Source
|
||||
## Verified facts
|
||||
## Ownership and attribution
|
||||
## Outcomes and metrics
|
||||
## Skills and recency
|
||||
## Safe claim seeds
|
||||
## Inferences / open questions
|
||||
## Conflicts with existing KB
|
||||
```
|
||||
|
||||
Claim seeds are factual building blocks, not polished resume bullets. Do not add unsupported impact language for relevance.
|
||||
|
||||
## Publication rules
|
||||
|
||||
- Never infer `published`, `accepted`, or `under review` from a manuscript file.
|
||||
- Preserve the user's author position.
|
||||
- Institutional funding is not a personal award.
|
||||
- Follow `config.md` provenance flags.
|
||||
|
||||
## Completion
|
||||
|
||||
Report:
|
||||
|
||||
- files created or updated;
|
||||
- newly verified facts;
|
||||
- unresolved contradictions or missing metrics;
|
||||
- suggested next command: use `setup-build-kb` to promote reviewed evidence into the canonical registry, experience files, bundles, and support files.
|
||||
|
||||
Do not update canonical claims from an unreviewed extraction.
|
||||
This shared file is the only workflow implementation for both agents. Preserve existing user authorization and resume from the application's recorded state.
|
||||
Reference in new issue
Block a user