chore(repo): Codex skills mirror, scout scratch-dump ignores, allowlist

- AGENTS.md + .agents/skills/: Codex-compatible mirror of the CLAUDE.md
  instructions and the .claude skill set.
- .gitignore: ignore job_scout/jd_*.txt and *_verify.txt one-off
  Playwright scrape dumps (applied JDs are archived in JDs/ + output/).
- settings.local.json: permission allowlist churn from recent sessions.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-03 13:58:52 +02:00
parent e286c6a9bb
commit b4fe2505ef
9 changed files with 1370 additions and 1 deletions
+111
View File
@@ -0,0 +1,111 @@
---
description: Re-critique existing resume/CV output files against a JD
user-invocable: true
---
# /critique
**User input:** `$ARGUMENTS`
Parse `$ARGUMENTS`:
- Session file path (e.g., `output/Acme/session_acme_engineer.md`) → read session file, derive .tex paths from Output Files
- .tex file path(s) + JD source (existing format) → backward compatible
- Session name (e.g., `acme_engineer`) → find session file via derivation
If no CL .tex provided or found in session file, critique resume/CV alone (Part 7 adjustments noted below).
---
## Safety Rules
**Accuracy > Relevance > Impact > ATS > Brevity**
Read `config.md` Provenance Flags. Verify every claim against that table.
**JD integrity:** the critique is only as valid as the JD. If the JD source is a reconstruction/inference/template rather than the real posting (see `shared_ops.md` → JD Integrity), STOP — flag it to the user and offer to scrape the live posting (Playwright recipe) before critiquing. Never score against a fabricated JD.
Check `config.md` KB Corrections Log — do not flag corrected items as errors.
Use the email from `config.md` Personal Info — flag if a different email appears in output.
FIXED sections (from `config.md` FIXED Sections) are template-locked — do not flag for editing. Flag only VARIABLE sections.
---
## User Input During Execution
If the user provides feedback, corrections, or suggestions at any point:
1. Acknowledge the input immediately
2. If it changes scoring criteria or focus: adjust the critique accordingly
3. Never restart — resume from current position
---
## Startup
Read `resume_builder/reference/shared_ops.md` — Fresh Session Startup + Session File Derivation.
Read `AGENTS.md` — check Active Sessions and KB Corrections.
Read `config.md` — load Provenance Flags, FIXED Sections, email.
Find and read the session file for the .tex being critiqued (use derivation protocol from shared_ops.md).
**Recovery check:**
- If CL not DONE in session file → "CL not yet generated. Run `/make-cl` first."
- If Critique: CURRENT → "Already critiqued (score X/100). Re-run? Waiting for confirmation."
- If Critique: STALE → "Edits made since last critique. Re-critiquing."
- If Critique: PENDING → proceed
---
## Protocol
1. **Read session file** — specifically note:
- **Company Context** → reviewer persona, "why this company"
- **Framing Strategy** → intentional reframing decisions (flag only execution inconsistencies, not the strategy itself)
- **Cover Letter Plan** → CL structure rationale
- **Critique Context** → reviewer persona, competitive landscape, domain vocabulary
- If session file lacks Company Context or Critique Context: do 1-2 web searches to fill gaps
2. Read `resume_builder/reference/critique_framework.md`
3. Read `resume_builder/support/ai_fingerprint_rules.md` — use Section 6 checklist in Part 7 verification
3. Read the .tex file(s) — derive paths from session file Output Files, or from `$ARGUMENTS`
4. Read the JD (path from `$ARGUMENTS` or session file)
5. Read the relevant bundle (`resume_builder/bundles/bundle_[role_type].md` — from session file)
6. Run char count:
```bash
python3 resume_builder/helpers/char_count.py -f [resume|cv] [file.tex]
```
7. Compile and visually verify:
```bash
pdflatex -interaction=nonstopmode -output-directory=output/<FolderName> [file.tex]
```
Use the Read tool to view the compiled PDF — check orphans, page fill, header wrapping.
If compile fails: note "COMPILE FAILED — visual checks could not be verified" in Part 8.
8. If a prior critique exists (`output/<FolderName>/critique_<name>.md`): read it and note previous score.
8b. **Paper Hook Verification:** If the CL cites named papers, PIs, programs, or publications, web-search to verify title, journal, year, and PI affiliation. Flag factual errors as Tier 1 fixes.
9. **Run the full critique per critique_framework.md. The output MUST contain ALL 8 sections** (even if the framework file has partially compacted, produce every section):
1. **Domain-Specialist Lens** — 7 elements:
(a) Reviewer persona (b) Company context (c) JD vocabulary extraction (d) Domain vocabulary map
(e) Gap ranking (fatal/serious/cosmetic) (f) Methodology transfer test (g) Competitive landscape
2. **Five-Perspective Read-Through** — ATS, Recruiter (10s), HR (30s), HM (2min), Technical (10min) — each with verdict
3. **Eight-Dimension Scoring** — weighted table summing to 100
(ATS 15%, Summary 10%, Skills 10%, Bullets 25%, Publications 10%, Narrative 15%, Visual 5%, Credibility 10%)
4. **Interview Likelihood** — per-reader probability + ceiling analysis
5. **Tiered Improvements** — Tier 1 (>=1pt each), Tier 2 (0.3-0.9), Tier 3 (<0.3)
6. **Interview Bridge Points** — 5-7 resume-to-interview talking points
7. **Cover Letter Critique** — 6 sub-checks (6A anti-patterns, 6B tailoring, 6C context-specific, 6D ATS, 6E structural, 6F package cohesion)
- **If no CL provided:** Skip 6A-6E. Run 6F as resume standalone assessment — evaluate whether the resume earns an interview without a CL. Note: "Cover letter not provided — package cohesion not assessed."
8. **Post-Generation Verification** — mechanical + content + structural checklists
10. Save to `output/<FolderName>/critique_<name>.md`
11. **Update session file** — Critique Summary (score, findings, tier 1 fixes), Status → Critique: CURRENT
12. **Update memory pointer** with new score
Progress: "Reading session file for framing context..." / "Running ATS keyword scan — 16/20 match..." / "Scoring 8 dimensions..." / "Score: 87.0/100"
### >>>>>> MANDATORY STOP <<<<<<
Present: score table + tier 1 actionable fixes + interview likelihood.
**You MUST wait for the user's explicit text response before continuing.**
If edits needed, tell user to run `/edit-resume`.
### When user approves / says "looks good" / finalizes:
Verify all expected files exist in `output/<FolderName>/`:
- session file, resume/CV .tex + .pdf, CL .tex + .pdf, critique .md
- Compile artifacts (.aux, .log, .out)
Confirm to user: "Package complete in output/<FolderName>/ — [list files]"
+208
View File
@@ -0,0 +1,208 @@
---
description: Edit existing resume/CV or cover letter from critique feedback and user suggestions
user-invocable: true
---
# /edit-resume
**User input:** `$ARGUMENTS`
Parse `$ARGUMENTS`: First argument is the .tex file path (required). A `.md` path is the critique file. Text in quotes is inline instructions.
- `/edit-resume output/Acme/e2e_acme_resume.tex`
- `/edit-resume output/Acme/e2e_acme_resume.tex output/Acme/critique_acme.md`
- `/edit-resume output/Acme/e2e_acme_resume.tex "shorten Position 1 header, fill last page"`
If only .tex path and no instructions: ask the user what to fix.
---
## Safety Rules (ALWAYS ENFORCED)
**Accuracy > Relevance > Impact > ATS > Brevity**
Read `config.md` Provenance Flags before editing any content. Verify every claim against that table.
- Use the email from `config.md` Personal Info in all outputs
- Source ALL bullet content from `resume_builder/experience/` files. Never fabricate.
- Resume bullets: ALL variable bullets must be 2L (CV: 2L/3L mix OK, check `config.md` Document Preferences)
- Run `python3 resume_builder/helpers/char_count.py` after edits — the tool is authoritative
### FIXED Sections — Refuse if Asked to Edit
Check `config.md` FIXED Sections for the list of template-locked sections. Say no and explain: these are template-locked across all outputs.
VARIABLE sections only: Summary, Technical Skills, Research Experience bullets/headers.
---
## User Input During Execution
If the user provides feedback, corrections, or suggestions at any point:
1. Acknowledge the input immediately
2. If it affects an already-applied edit: go back, fix it, re-run char count gate
3. If it changes the edit plan: update session file, adjust remaining edits
4. If it's a question: answer it, then continue from current step
5. Never restart a phase — resume from current position
---
## Startup
Read `resume_builder/reference/shared_ops.md` — Fresh Session Startup + Session File Derivation.
Read `AGENTS.md` — check Active Sessions and KB Corrections.
Read `config.md` — load Provenance Flags, email, FIXED Sections, document preferences.
Find and read the session file (use derivation protocol from shared_ops.md).
**Recovery check:**
- Read session file, check for existing Edit N Status
- If Edit N Status shows IN_PROGRESS: read .tex, identify which edits are done, resume
- If no edit in progress: proceed to Phase 1
---
## Phase 1: Load Context
Read in this order:
1. **Session file** (`output/<FolderName>/session_<name>.md`) — note: Framing Strategy, Company Context, Bullet Plan, Edit History
2. `resume_builder/reference/resume_reference.md` — char limits, budgets, fixed sections
3. The .tex file being edited
4. Critique file (if provided in `$ARGUMENTS`)
5. JD file (path from session file's JD Info section)
6. Compile current .tex and record baseline page count
7. Run: `python3 resume_builder/helpers/char_count.py -f [resume|cv] [file.tex]`
**Record baseline in session file** under `## Edit [N] Baseline` (scan existing Edit History sections; next N = max existing + 1, or 1 if none):
```
## Edit [N] Baseline
- Pages: [N]
- Char violations: [list or "none"]
- Orphan violations: [list or "none"]
- White space last page: [N lines]
- Variable bullets: [N]
- Rendered lines: [N]
```
Progress: "Reading session file — [company], [role type] bundle..." / "Baseline: 2 pages, 0 char violations, 1 orphan..."
---
## Phase 2: Diagnose & Plan Edits
Gather change requests from THREE sources:
1. **User instructions** from `$ARGUMENTS` (highest priority)
2. **Critique file** (Tier 1 fixes first, then Tier 2)
3. **Auto-detected issues** from Phase 1 (char violations, orphans, page fill)
Cross-check against **session file framing strategy** — edits must stay consistent with decisions from `/make-resume`.
**For each change, classify:**
- **MODIFY:** Change text of existing bullet/summary/skills. Budget unchanged.
- **SWAP:** Replace one bullet with another. Budget unchanged if same variant.
- **ADD:** Insert new bullet. Budget increases by rendered lines.
- **REMOVE:** Drop a bullet. Budget decreases.
- **VARIANT CHANGE:** e.g., 2L → 3L. Budget changes by rendered line delta.
- **FIXED:** Blocked — show in plan with `[FIXED — cannot edit]` and explain why.
**Budget revalidation (if any change is ADD, REMOVE, SWAP-with-different-variant, or VARIANT CHANGE):**
Recalculate total variable bullets and rendered lines. Compare against budget from resume_reference.md.
If OVER budget: present overflow and ask user which bullet to drop or shorten.
Show: `Budget: [N] bullets ([M] rendered lines) vs target [T]. PASS/FAIL`
If edit targets **cover letter** (not resume/CV): note this — Phase 4 will use CL-specific gates. Load CL .tex path from session file Output Files section.
### >>>>>> MANDATORY STOP — DO NOT PROCEED <<<<<<
Present numbered edit plan. Each item shows: what, why, source, classification (MODIFY/ADD/SWAP/FIXED).
**You MUST wait for the user's explicit text response before continuing.**
Proceeding without confirmation may make unwanted edits that break package consistency.
---
## Phase 3: Load Reference Files (only confirmed edits)
Load ONLY what the confirmed edits need:
- **All edits:** `resume_builder/support/ai_fingerprint_rules.md` — scan for banned words/patterns before and after edits
- **Bullet expand/rewrite/add:** `resume_builder/experience/` files + matching bundle + `resume_builder/support/achievement_reframing_guide.md`
- **Summary rewrite:** Bundle (S2 summary guide) + `resume_builder/support/skills_taxonomy.md`
- **Cover letter edits:** `resume_builder/support/significance_*.md` + `resume_builder/reference/cl_reference.md`
- **Simple fixes** (orphans, headers, spacing): No extra files needed
---
## Phase 4: Execute Edits
Apply edits one section at a time. After each edited section:
1. Run char count gate:
```bash
python3 resume_builder/helpers/char_count.py -f [resume|cv] output/<FolderName>/[file].tex
```
2. Fix any OVER violations or orphans before next section
3. If a bullet expansion doesn't render as expected (1L when targeting 2L, or 3L), adjust immediately
Update session file Edit N Status after each individual edit:
- Edit 1 (orphan fix): DONE
- Edit 2 (Summary rewrite): IN_PROGRESS
### Resume/CV Verification Gates
| Gate | Check | If FAIL |
|------|-------|---------|
| Char count | No OVER violations | Fix bullet before proceeding |
| Page fill | Resume: <= 3 lines white space. CV: check rendered line target | Expand/trim variable bullets |
| Page count | Match `config.md` Document Preferences | Trim/expand variable content |
| Orphan | 2L bullet last line >= 70% | Pad or trim |
| Title width | Position title + date fits 1 line | Shorten title |
| Compile | Clean pdflatex | Fix LaTeX errors |
### Cover Letter Verification Gates (if CL was edited)
| Gate | Check | If FAIL |
|------|-------|---------|
| Word count | Industry 250-300, Lab/Academic 350-450 | Trim/expand |
| Page fill | 1pg: well-filled. 2pg: page 2 >= half filled before signature | Adjust |
| Paragraph count | Industry 3, Lab/Academic 4 | Restructure |
| Anti-patterns | No generic opener, no defensive framing, no credential dump | Rewrite |
| Package cohesion | CL claims traceable to resume bullets, no contradictions | Fix |
After all edits, compile:
```bash
pdflatex -interaction=nonstopmode -output-directory=output/<FolderName> output/<FolderName>/[file].tex
```
Use the Read tool to view the compiled PDF — check page count, white space, orphans, header wrapping.
Progress: "Editing Position 1 bullet 6 — was 184 chars, now 197..." / "Compiling... 2 pages, page fill OK"
---
## Phase 5: Update Session File & Present
1. **Append Edit History** (use the N from Phase 1 baseline):
```
### Edit [N] ([date]): [short description]
- Changes: [what changed]
- Source: critique item # / user request / auto-detected
- Verification: gates passed
```
2. **Compare against baseline:**
| Metric | Before | After | Delta |
|--------|--------|-------|-------|
| Page count | [N] | [N] | [+/-] |
| Char violations | [N] | [N] | [+/-] |
| Orphans | [N] | [N] | [+/-] |
| White space | [N] | [N] | [+/-] |
Flag any metric that worsened.
3. **Update Status** — mark critique as STALE if edits made after last critique. Update Next.
4. **Update memory pointer** if status changed.
5. **Present:** Changes summary + delta table + compiled PDF.
### >>>>>> MANDATORY STOP <<<<<<
Show results. Wait for user approval or further edits.
**You MUST wait for the user's explicit text response before continuing.**
### When user approves / says "looks good" / finalizes:
Run file organization from `resume_builder/reference/shared_ops.md` — Finalization check.
+142
View File
@@ -0,0 +1,142 @@
---
description: Generate a tailored cover letter from an existing session file and finished resume/CV
user-invocable: true
---
# /make-cl
**User input:** `$ARGUMENTS`
Parse `$ARGUMENTS`:
- Session file path (e.g., `output/Acme/session_acme_engineer.md`) → read that session file
- Session name (e.g., `acme_engineer`) → find session file via shared_ops.md derivation
- Empty → check `AGENTS.md` Active Sessions for latest
---
## Safety Rules (ALWAYS ENFORCED)
**Accuracy > Relevance > Impact > ATS > Brevity**
Read `config.md` Provenance Flags before generating any content. Verify every claim against that table.
- Use the email from `config.md` Personal Info in all outputs
- CL deepens what resume presents — never introduces new claims not traceable to resume bullets
- Source field context from `resume_builder/support/significance_*.md` files
---
## User Input During Execution
If the user provides feedback, corrections, or suggestions at any point:
1. Acknowledge the input immediately
2. If it affects already-written content: fix it, re-verify word count and anti-patterns
3. If it changes the framing: note the change in session file Framing Strategy
4. Never restart — resume from current position
---
## Startup
Read `resume_builder/reference/shared_ops.md` for session startup and file derivation.
Then:
1. Read `AGENTS.md` — check Active Sessions and KB Corrections
2. Read `config.md` — load Provenance Flags, email, role types
3. Find and read the session file
4. **Recovery check:**
- If CL Status is DONE → "CL already generated. Run `/critique` next." Show next command. Stop.
- If CL Status is IN_PROGRESS → check if CL .tex exists, offer to resume or regenerate
- If Resume Status is not DONE → "Resume not yet generated. Run `/make-resume` first." Stop.
- If CL Status is PENDING → proceed to Phase 1
---
## Phase 1: Load Context
Read in this order:
1. **Session file** — specifically: Company Context, Cover Letter Plan, Framing Strategy, ATS Keywords
2. **Finished resume/CV .tex** — path from session file Output Files. Read to understand what CL must complement.
3. `resume_builder/reference/cl_reference.md` — CL format rules, paragraph templates, anti-patterns
4. `resume_builder/support/ai_fingerprint_rules.md` — Banned words, structural rules (CLs are most vulnerable)
5. The matching bundle from session file role type → `resume_builder/bundles/bundle_[role_type].md` — Section 5 (Cover Letter)
5. All significance files from `resume_builder/support/significance_*.md`
Update session file Status: `Cover Letter: IN_PROGRESS`
Progress: "Loading CL context — [company], [role type] bundle, [institution type]..."
---
## Phase 2: Generate Cover Letter
Read `resume_builder/templates/coverletter_template.tex`.
**Detect institution type** from session file Cover Letter Plan:
- Industry → 3 paragraphs, 250-300 words
- National Lab → 4 paragraphs, 350-450 words
- Academic → 4 paragraphs, 350-450 words (postdoc) or 450-650 words (faculty)
**Generate CL following cl_reference.md paragraph structure:**
- Use significance files for field-context depth (NOT resume bullet text)
- Use session file CL hooks and "why them" angle
- Ensure every major claim is traceable to a resume/CV bullet
- Open with a specific reference to their work — no generic openers
- Weave credentials into body paragraphs, not closing
Save to `output/<FolderName>/e2e_<name>_cover_letter.tex`
Progress: "Writing [institution type] cover letter — [N] paragraphs, targeting [N] words..."
### CL Hook Verification Gate (MANDATORY before presenting to user)
Web-search every hook used in the CL:
- Academic: PI name + cited paper/research area
- National Lab: named program, thrust area, or group publication
- Industry: product, technology, or company news referenced
Present evidence as:
> **Claim:** [what the CL says] → **Evidence:** [what the search found] → **Source:** [URL]
Flag any unverified item: **"UNVERIFIED — please confirm"**
Do NOT present the CL draft to the user until all hooks are verified or flagged.
---
## Phase 3: Compile & Verify
```bash
pdflatex -interaction=nonstopmode -output-directory=output/<FolderName> output/<FolderName>/e2e_<name>_cover_letter.tex
```
Use Read tool to view compiled PDF. Verify:
| Gate | Check | If FAIL |
|------|-------|---------|
| Word count | Industry 250-300, Lab/Academic 350-450 | Trim/expand |
| Page count | Resume package: 1 page. CV package: 1-2 pages | Adjust content |
| Page fill | 1pg: well-filled. 2pg: page 2 >= half filled before signature | Adjust |
| Anti-patterns | No generic opener, no defensive framing, no credential dump | Rewrite |
| Package cohesion | CL claims traceable to resume bullets, no contradictions | Fix |
| Compile | Clean pdflatex | Fix LaTeX errors |
Update session file:
- Add CL to Output Files
- Status: `Cover Letter: DONE`
- Add Next Critique command
Progress: "Compiled — 1 page, 278 words. Package cohesion verified."
### >>>>>> MANDATORY STOP — DO NOT PROCEED <<<<<<
Present: CL summary (word count, page count, key hooks used).
**You MUST wait for the user's explicit text response before continuing.**
If user requests changes: apply them, re-compile, re-verify. Update session file.
If user approves: update Status, present next command.
**Do NOT trigger file organization** — that happens after `/critique` approval.
"Cover letter done. Next steps:
1. /clear
2. [exact /critique command with session file path]"
+241
View File
@@ -0,0 +1,241 @@
---
description: Generate a tailored resume/CV from a JD
user-invocable: true
---
# /make-resume
**User input:** `$ARGUMENTS`
Parse `$ARGUMENTS`:
- File path (e.g., `JDs/*.txt`) → read that file for the JD
- A URL → this is NOT a JD, it's a pointer. Fetch the real posting text first (see JD Integrity below), save it verbatim to `JDs/<company>_<role>.txt`, then proceed.
- Text after the path starting with "Focus:"/"Emphasize:"/"Downplay:" → focus directive
- "Quick:" prefix → Quick Mode (see below)
- Empty → ask the user for the JD
- Inline JD text (no file path) → save to `JDs/temp_<company>.txt`, proceed normally
**JD Integrity (read `shared_ops.md` → "JD Integrity"):** The JD must be the real posting, verbatim. NEVER invent, reconstruct, paraphrase, or infer JD content. `WebFetch` is JS-blind on careers boards — use the job_scout Playwright recipe in `shared_ops.md` to scrape JS-gated postings. If you cannot get the real text, STOP and ask the user to paste it. Do not proceed on a guessed JD.
---
## Safety Rules (ALWAYS ENFORCED)
**Accuracy > Relevance > Impact > ATS > Brevity**
Read `config.md` Provenance Flags before generating any content. Verify every claim against that table.
- **JD is ground truth — use the real posting verbatim. NEVER reconstruct, invent, or infer a JD** (see `shared_ops.md` → JD Integrity). If you can't get the real text, STOP and ask the user to paste it.
- Use the email from `config.md` Personal Info in all outputs
- Resume bullets: ALL variable bullets are 2L (CV: 2L/3L mix OK, check `config.md` Document Preferences)
- Source ALL bullet content from `resume_builder/experience/` files. Never fabricate.
- Run `python3 resume_builder/helpers/char_count.py` after each section — the tool is authoritative
---
## User Input During Execution
If the user provides feedback, corrections, or suggestions at any point:
1. Acknowledge the input immediately
2. If it affects an already-written section: go back, fix it, re-run char count gate
3. If it changes the bullet plan: update session file Bullet Plan
4. If it's a question: answer it, then continue from current step
5. Never restart a phase — resume from current position
---
## Startup
Read `resume_builder/reference/shared_ops.md` for session startup, file derivation, and organization protocols.
Then:
1. Read `AGENTS.md` — check Active Sessions and KB Corrections
2. Read `config.md` — load Provenance Flags, email, document preferences, role types
3. If session file exists for this JD:
- Read session file, check Status
- Phase 0: DONE, Phase 1: PENDING → resume at Phase 1
- Phase 1: DONE → resume at Budget Gate
- Phase 2: IN_PROGRESS → read .tex, check what sections exist, resume from checkpoint
- Phase 2: DONE → "Resume already done. Run /make-cl next." Show next command. Stop.
4. If no session file: proceed to Phase 0
---
## Quick Mode
Trigger: `$ARGUMENTS` starts with "Quick:"
Defaults:
- Select all HIGH priority achievements from bundle's Priority Matrix as 2L
- Fill remaining budget with MEDIUM priority in Priority Matrix order
- Default format: 2-page resume (unless JD clearly requires CV)
- Skip Phase 0 STOP and Phase 1 STOP
- Keep Budget Gate (auto-pass if within target) and end-of-resume STOP
- Run all phases with progress commentary instead of interactive stops
---
## Phase 0: Research & Session Setup
**Read these files:**
1. The JD — the **real posting text**, verbatim. If `$ARGUMENTS` was a URL or the posting is on a JS-gated board, scrape it with the Playwright recipe in `shared_ops.md` (JD Integrity) BEFORE this step and save to `JDs/`/`output/<FolderName>/JD_<name>.txt`. If you cannot obtain the real text, STOP and ask the user to paste it — do NOT reconstruct or infer it.
2. `resume_builder/reference/resume_reference.md` — Budget Card, Section Specs, Char Limits, Page Budgets
3. `config.md` — Role-Type Decision Tree to identify the matching bundle
**Web Search (MANDATORY — 2-3 searches).** Load WebSearch via ToolSearch first.
1. `[Company] research & development [key JD domain]` — products, recent projects
2. `[Company] [specific technology from JD]` — concrete hooks for cover letter
3. `[Company] careers [role type] culture` OR recent news — hiring context
If web search returns no results: use JD text + training knowledge. Flag: "Web search returned limited results — CL hooks may be generic."
**Produce all of these (reference `resume_builder/reference/session_file_template.md` for format):**
- **JD Analysis** — classify every requirement as Direct / Bridge (with confidence) / Gap. Extract ATS keywords by category.
- **Company Context** — mission, role purpose, culture signals, "why them" angle (from web research)
- **Framing Strategy** — lead narrative, reframing map, emphasize/downplay, CL hooks, user focus directives
- **Critique Context** — reviewer persona, competitive landscape, domain vocabulary
- **Cover Letter Plan** — institution type, paragraph structure, hooks, jargon level
**Create output folder:**
Derive folder name from JD filename: `JDs/JD_Acme.txt``output/Acme/`
```bash
mkdir -p output/<FolderName>/
```
Write session file to `output/<FolderName>/session_<name>.md` (NOT flat `output/`).
All subsequent output files go in this folder.
**Verify completeness:** Re-read the session file. Confirm these 8 sections are non-empty: JD Info, Requirements table, ATS Keywords, Gap Assessment, Company Context, Framing Strategy, Critique Context, Cover Letter Plan. Fill any missing section before presenting.
**Write memory pointer** to `AGENTS.md` Active Sessions.
**Update session file Status:** `Phase 0: DONE`
Progress: "Searching for [company] + [domain]..." / "JD analysis: X/Y requirements direct match, Z bridges, W gaps"
### >>>>>> MANDATORY STOP — DO NOT PROCEED <<<<<<
Present: research summary, role type + bundle, format, framing strategy.
Ask user to confirm: (1) role type + bundle, (2) format, (3) framing strategy.
**You MUST wait for the user's explicit text response before continuing.**
Proceeding without confirmation misaligns the entire resume and requires full regeneration.
---
## Phase 1: Plan Bullets
**Re-read `output/<FolderName>/session_<name>.md`** — specifically Framing Strategy and ATS Keywords.
**Read:**
1. The matching bundle from `config.md` Role Types → `resume_builder/bundles/bundle_[role_type].md` — Section 1 (Priority Matrix)
- For hybrid JDs: read both bundles. Use primary for Priority Matrix, secondary for Reframing Map on 1-2 bridging bullets.
2. All experience files from `resume_builder/experience/`
3. `resume_builder/support/achievement_reframing_guide.md`
4. `resume_builder/support/skills_taxonomy.md`
5. `resume_builder/support/pub_metadata.md`
**Present one table per position:**
**[Position Name] (Budget: N-M bullets, ~X-Y rendered lines)**
| | ID | Achievement | Variant | Lines | JD Match |
|---|---|-------------|---------|-------|----------|
| * | P1-1 | [short description] | 2L | 2 | Direct |
| * | P1-5 | [short description] | 2L | 2 | Direct |
| o | P1-3 | [short description] | 2L | 2 | Bridge |
| x | P1-7 | [short description] | -- | -- | Weak |
**Legend:** `*` = recommended (HIGH on Priority Matrix + Direct JD match) | `o` = available (MEDIUM priority or Bridge match) | `x` = not recommended (LOW priority or Gap)
**After all positions, show:**
- Recommended set total vs budget (from Quick Budget Card in resume_reference.md)
- Remaining budget slots and what could fill them
- Forced exclusions per provenance flags
- Focus directive impact (what changed vs Priority Matrix defaults)
- CV: confirm first bullet of first experience is 2L (page 1 rule)
**Update session file** — write Bullet Plan tables. Status: `Phase 1: DONE (N bullets confirmed)`
Progress: "Reading experience files for bullet candidates..." / "Recommending N bullets per position"
### >>>>>> MANDATORY STOP — DO NOT PROCEED <<<<<<
Present bullet plan. Wait for user to confirm/modify selections.
**You MUST wait for the user's explicit text response before continuing.**
If you proceed without confirmation, you will generate bullets the user didn't approve.
**Update session file with confirmed plan before continuing.**
---
## Budget Gate (AFTER user confirms bullet plan, BEFORE Phase 2)
**Re-read session file Bullet Plan section** to verify confirmed counts.
- Check budget targets from `resume_builder/reference/resume_reference.md` Budget Card.
- Show: `Budget: [N] bullets vs target [T]. PASS/FAIL`
- **FAIL = do not proceed. Reconcile with user first.**
---
## Phase 2: Generate
**Re-read to restore context after compaction:**
1. `output/<FolderName>/session_<name>.md` (framing + confirmed bullet plan)
2. `resume_builder/reference/critical_rules.md` — Character Limits, Bold Width Penalty, Orphan rules
3. `resume_builder/support/ai_fingerprint_rules.md` — Banned words, structural rules, post-gen checklist
**Read template:** `resume_builder/templates/resume_template.tex` or `cv_template.tex` + `.cls`
FIXED sections (from `config.md` FIXED Sections) are template-locked — only generate VARIABLE sections (Summary, Skills, Experience bullets/headers).
**Read section specs:** `resume_builder/reference/resume_reference.md` — Section-by-Section Specs for your format
**Generate section by section** (follow Section-by-Section Specs):
1. Summary → check against session framing strategy
- Update Status → `Phase 2: Summary DONE`
2. Technical Skills
- Update Status → `Phase 2: Skills DONE`
3. Each position's bullets → **CHAR COUNT GATE after each position**
- Position titles: bold theme + date must fit ONE line (see resume_reference.md). If wrapping, shorten title.
- After each position: Update Status → `Phase 2: [Position] DONE`
4. **PAGE FILL GATE after all experience**
Save .tex to `output/<FolderName>/e2e_<name>_resume.tex` or `_cv.tex`
**Update session file** — add Output Files.
Progress: "Writing Position 1 bullets (6 of 7)..." / "Bullet 4 is SHORT at 184 chars — padding" / "Compiling resume... 2 pages OK"
### CHAR COUNT GATE (per position)
```bash
python3 resume_builder/helpers/char_count.py -f [resume|cv] output/<FolderName>/[file].tex
```
No OVER violations. Last line of 2L bullets >= 70% fill. **Fix before next position.**
### PAGE FILL GATE
Resume: <= 3 lines white space on last page. CV: check rendered line target from resume_reference.md. **If FAIL: add/trim variable bullets.**
### COMPILE GATE
```bash
pdflatex -interaction=nonstopmode -output-directory=output/<FolderName> output/<FolderName>/e2e_<name>_resume.tex
```
Verify page counts match `config.md` Document Preferences. Use the Read tool to view compiled PDF — check orphans, header wrapping, page fill. **If FAIL: fix variable content, recompile.**
Run the Post-Generation Verification checklist from `resume_builder/reference/resume_reference.md` before proceeding.
Update Status → `Phase 2: Compile DONE`
---
## End of /make-resume
Update session file Status:
- `Resume: DONE`
- `Cover Letter: PENDING`
- `Critique: PENDING`
- `Next: /make-cl output/<FolderName>/session_<name>.md`
- `Next Critique: /critique output/<FolderName>/session_<name>.md`
### >>>>>> MANDATORY STOP <<<<<<
Present: resume compilation summary (pages, char count results, any violations fixed).
**You MUST wait for the user's explicit text response before continuing.**
"Resume compiled and verified. Next steps:
1. /clear
2. [exact /make-cl command with session file path]"
+329
View File
@@ -0,0 +1,329 @@
---
description: Synthesize completed extractions into the knowledge base files needed for resume generation
user-invocable: true
---
# /setup-build-kb
**User input:** `$ARGUMENTS`
Parse `$ARGUMENTS`:
- Empty → full build (all phases)
- Phase number (e.g., `3`) → resume from that phase
- "experience" / "bundles" / "skills" / "pubs" / "reframing" / "significance" → run only that component
- "status" → show what's built and what's missing
---
## Startup
1. Read `AGENTS.md` — check KB Corrections Log
2. Read `config.md` — load:
- Personal Info (positions, institutions, dates)
- Role Types table (defines which bundles to create)
- Provenance Flags (propagate to all KB files)
- Document Preferences (bullet variant defaults)
3. Read `knowledge_base/extractions/_INVENTORY.md` — verify extractions exist
4. Scan `resume_builder/` to see what's already built
**Pre-flight check:**
- If `_INVENTORY.md` is empty or has no entries: "No extractions found. Run `/setup-extract` first." Stop.
- If fewer than 2 extractions: warn "Only [N] extraction(s) found. KB quality improves with more papers. Continue anyway?"
Progress: "Found [N] extractions across [M] positions. Config has [K] role types defined."
---
## Phase 1: Build Experience Files
**Goal:** Create one experience file per position, containing all achievements organized for resume generation.
**Read:** All extraction files listed in `_INVENTORY.md`
**For each position** (from `config.md` or inferred from extraction metadata):
1. Group extractions by the position they belong to (based on dates, institution, or user clarification)
2. Ask the user to confirm grouping if ambiguous: "I've grouped these papers under [Position]. Correct?"
**Experience file format** (`resume_builder/experience/experience_<position_key>.md`):
```markdown
# Experience: [Position Title] — [Institution]
## [Date Range]
### Cross-Position Section
[Brief narrative connecting this position's work to the user's broader trajectory]
[CL framing content — how this position fits the career arc]
---
### Achievement [ID]: [Short Title]
**Source:** [extraction filename]
**Paper:** [citation or "internal"/"unpublished"]
**User's role:** [first author / contributing / sole developer]
**Status:** [published / under review / draft / internal]
**Context:** [1-2 sentences — what problem, why it matters]
**Bullet variants:**
- **2L:** [Full 2-line bullet text — STAR format, ~180-210 rendered characters]
- **3L:** [Full 3-line bullet text — for CV use, ~270-310 rendered characters]
- **1L:** [Condensed 1-line version — ~90-110 rendered characters, for tight budgets]
**Key skills:** [comma-separated list of skills this achievement demonstrates]
**ATS keywords:** [domain-specific terms an ATS might scan for]
**Reframing notes:** [how to emphasize different aspects for different role types]
---
[Repeat for each achievement]
```
### >>>>>> MANDATORY STOP — DO NOT PROCEED <<<<<<
Present the experience file(s) — show achievement count per position, total bullet variants.
Ask user to review: "Are the groupings correct? Any achievements missing or misattributed?"
**You MUST wait for the user's explicit text response before continuing.**
---
## Phase 2: Build Skills Taxonomy
**Goal:** Create a categorized inventory of all technical skills from extractions.
**Read:** All extraction files (Methods & Tools sections) + experience files from Phase 1
**Build** `resume_builder/support/skills_taxonomy.md`:
```markdown
# Skills Taxonomy
## Summary Stats
- Total unique skills: [N]
- Publications: [N] ([breakdown by status])
- Top methods: [ranked list]
## Categories
### [Category 1: e.g., Computational Methods]
| Skill | Proficiency | Evidence | Resume Weight |
|-------|-----------|----------|---------------|
| [skill] | [expert/proficient/familiar] | [paper IDs] | [HIGH/MED/LOW] |
### [Category 2: e.g., Programming & Software]
[same table format]
### [Category 3: e.g., Machine Learning]
[same table format]
[Continue for all categories — typically 4-7 categories]
```
**Proficiency levels:**
- **Expert:** Multiple first-author papers, developed custom tools
- **Proficient:** Used extensively in published work, comfortable teaching
- **Familiar:** Used in one project, or contributed to someone else's implementation
Progress: "Built taxonomy — [N] skills across [M] categories"
---
## Phase 3: Build Publication Metadata
**Goal:** Structured pub data for resume/CV generation.
**Build** `resume_builder/support/pub_metadata.md`:
```markdown
# Publication Metadata
## Summary
- Total publications: [N]
- First-author: [N] | Co-first: [N] | Contributing: [N]
- Published: [N] | Under review: [N] | In preparation: [N]
## Publication List
### First-Author / Co-First
| # | Citation (et al. format) | Journal | Year | Status | Key Topic |
|---|-------------------------|---------|------|--------|-----------|
| 1 | [Author et al., Journal, Year] | [journal] | [year] | [status] | [topic] |
### Contributing Author
[same table format]
### Under Review / In Preparation
[same table format, with provenance notes]
```
Progress: "Pub metadata — [N] first-author, [M] contributing, [K] under review"
---
## Phase 4: Build Achievement Reframing Guide
**Goal:** Per-achievement significance lines + framing directives for each role type.
**Read:** Experience files + `config.md` Role Types
**Build** `resume_builder/support/achievement_reframing_guide.md`:
```markdown
# Achievement Reframing Guide
## How to Use
For each achievement, `Significance:` provides a one-line framing cue.
The role-type table shows how to emphasize/de-emphasize for each target audience.
---
### [Achievement ID]: [Title]
**Significance:** [One sentence — why this matters broadly]
| Role Type | Emphasis | Lead Verb | Framing Angle |
|-----------|----------|-----------|---------------|
| [role 1] | HIGH | Developed | [emphasize X aspect] |
| [role 2] | MEDIUM | Applied | [bridge to Y domain] |
| [role 3] | LOW | -- | [omit or condense] |
**Overclaiming warning:** [if applicable — e.g., "Do not claim sole credit for experimental results"]
**First-pass checklist:** [ ] Verb matches author role [ ] Numbers from paper [ ] Status matches provenance
---
[Repeat for each achievement]
```
### >>>>>> MANDATORY STOP — DO NOT PROCEED <<<<<<
Present the reframing guide summary — show which achievements are HIGH for which role types.
Ask user: "Does this priority mapping look right for your target roles?"
**You MUST wait for the user's explicit text response before continuing.**
---
## Phase 5: Build Bundles
**Goal:** One bundle per role type from `config.md`, with 5 sections each.
**Read:** Experience files + Skills Taxonomy + Reframing Guide + `config.md` Role Types
**For each role type**, create `resume_builder/bundles/bundle_<role_type>.md`:
```markdown
# Bundle: [Role Type Name]
> Target employers: [from config.md]
> Tier: [from config.md]
---
## S1: Role Profile & Priority Matrix
**Positioning:** [1-2 sentences — how to position the user for this role type]
### Priority Matrix
| Priority | Achievement IDs | Rationale |
|----------|----------------|-----------|
| HIGH | [IDs] | [why these lead for this role type] |
| MEDIUM | [IDs] | [supporting evidence, bridge topics] |
| LOW | [IDs] | [omit unless budget allows or JD specifically asks] |
---
## S2: Summary Guide
**Headline pattern:** [Role-appropriate headline template]
**Building blocks:** [3-5 phrases that should appear in summaries for this role type]
**Avoid:** [terms/framings that don't fit this audience]
---
## S3: Achievement Reframing Map
[For each HIGH/MEDIUM achievement: which angle to use, which metrics to lead with]
| ID | Default Framing | This Role's Framing | Key Metric |
|----|----------------|--------------------|-----------|
| [ID] | [generic] | [role-specific angle] | [number to highlight] |
---
## S4: Skills Guide
**Bold tools (resume):** [3-5 tools to bold in Technical Skills for this role type]
**Must-include skills:** [skills that MUST appear for ATS match]
**Nice-to-have:** [skills to include if budget allows]
**Omit:** [skills irrelevant to this audience]
---
## S5: Cover Letter Guide
**Institution type:** [Industry / National Lab / Academic]
**Opening hook pattern:** [template for first paragraph opener]
**Key narrative thread:** [what story to tell across paragraphs]
**"Why them" angle:** [what to research about target employer]
**Avoid:** [CL anti-patterns for this role type]
```
Progress: "Building bundle for [role type] — [N] HIGH priority achievements, [M] bold tools"
---
## Phase 6: Build Significance Research Files
**Goal:** Field context for cover letters — NOT for resume bullets.
**For each position**, create `resume_builder/support/significance_<position_key>.md`:
```markdown
# Significance Research: [Position]
> Use in cover letters and summaries — NOT in resume bullet text.
> These provide field context that demonstrates the user understands the landscape.
---
### [Achievement ID]: Field Context
**The problem:** [What challenge does this address? Industry/scientific context]
**Competing approaches:** [What else exists? What are the limitations?]
**Why this matters:** [Market size, DOE/funding priorities, industry need]
**Differentiation:** [What makes the user's approach unique or better?]
---
[Repeat for each major achievement worth cover-letter depth]
### Field Overview: [Broad Topic]
[2-3 paragraphs of field context that multiple achievements contribute to]
[Useful for cover letter opening hooks and "why this matters" framing]
```
Progress: "Significance research — [N] achievements with field context, [M] field overviews"
---
## Final: Status Report
After all phases complete (or after the requested subset), present:
### KB Build Status
| Component | File | Status | Items |
|-----------|------|--------|-------|
| Experience files | `experience/*.md` | [DONE/MISSING] | [N achievements] |
| Skills taxonomy | `support/skills_taxonomy.md` | [DONE/MISSING] | [N skills] |
| Pub metadata | `support/pub_metadata.md` | [DONE/MISSING] | [N pubs] |
| Reframing guide | `support/achievement_reframing_guide.md` | [DONE/MISSING] | [N entries] |
| Bundles | `bundles/bundle_*.md` | [DONE/MISSING] | [N bundles] |
| Significance | `support/significance_*.md` | [DONE/MISSING] | [N files] |
### Ready for Generation?
- [ ] At least 1 experience file with 5+ achievements
- [ ] Skills taxonomy with 20+ skills
- [ ] At least 1 bundle matching a target role type
- [ ] Pub metadata complete
- [ ] Reframing guide covers all achievements
- [ ] Significance files for cover letter depth
If all checked: "Knowledge base is ready. Save a JD to `JDs/` and run `/make-resume JDs/<filename>.txt`"
If gaps: "[List what's missing and which phase to re-run]"
### >>>>>> MANDATORY STOP <<<<<<
Present status report. Wait for user confirmation.
**You MUST wait for the user's explicit text response before continuing.**
+170
View File
@@ -0,0 +1,170 @@
---
description: Extract structured information from research papers, PDFs, or code into knowledge base extractions
user-invocable: true
---
# /setup-extract
**User input:** `$ARGUMENTS`
Parse `$ARGUMENTS`:
- File path to a paper (e.g., `papers/Smith2024_catalyst.pdf`, `papers/project_report.tex`) → read that file
- Multiple paths separated by spaces → batch mode (process each sequentially)
- Empty → ask the user for the paper path or paste content
---
## Startup
1. Read `AGENTS.md` — check KB Corrections Log for known issues
2. Read `config.md` — load Personal Info (to identify user's author position), Provenance Flags
3. Read `knowledge_base/extractions/_INVENTORY.md` — see what's already extracted, avoid duplicates
If the paper is already in the inventory:
- Show the existing extraction path
- Ask: "This paper is already extracted. Re-extract (overwrite) or skip?"
- Wait for user response before proceeding
---
## Phase 1: Read & Understand the Paper
Read the paper using the appropriate method:
- **PDF files:** Use the Read tool (supports PDF reading)
- **.tex source:** Read directly — often has more detail than the compiled PDF
- **If both exist:** Prefer .tex for content extraction, use PDF for figures/tables
**While reading, collect:**
1. Full title, all authors, year, journal/venue, DOI (if available)
2. The user's position in the author list (first, co-first, second, middle, last, corresponding)
3. Publication status (check `config.md` Provenance Flags first, then infer: published / under review / draft / internal)
4. All computational methods, experimental techniques, software, and frameworks mentioned
5. Quantitative results — speedups, accuracies, efficiencies, improvements over baselines
6. Novelty claims — "first-ever", "new framework", "novel approach", etc.
7. Collaboration indicators — other groups, institutions, shared resources
8. Funding acknowledgments
Progress: "Reading paper... [title] by [first author] et al., [year]"
---
## Phase 2: Clarify User's Role
If the user's contribution is not obvious from the paper (common for multi-author work), ask:
**Questions to ask (skip any that are already clear from the paper):**
1. "What was your specific contribution? (e.g., all computational work, specific analysis, code development)"
2. "Did you develop any tools, methods, or code used in this paper?"
3. "Were there other groups or institutions involved? What was your group's role?"
4. "Any quantitative results you can personally claim? (e.g., 'I ran all the simulations')"
5. "Is there anything in this paper that should NOT appear on your resume? (e.g., collaborator's experimental data)"
### >>>>>> MANDATORY STOP — DO NOT PROCEED <<<<<<
Present your understanding of the paper and ask the clarifying questions above.
**You MUST wait for the user's explicit text response before continuing.**
---
## Phase 3: Write Extraction
Create the extraction file at `knowledge_base/extractions/<AuthorYear_short_descriptor>.md`
**Naming convention:** `<FirstAuthorLastName><Year><2-3_word_descriptor>.md`
- Examples: `Smith2024_protein_stability.md`, `Chen2023_binding_affinity.md`
- If the user is first author: use their last name
- Normalize to lowercase with underscores
**Extraction format:**
```markdown
# [Full Paper Title]
## Metadata
- **Authors:** [author list — highlight user's name with bold]
- **Year:** [year]
- **Journal:** [journal/venue or "unpublished"/"internal"/"under review at X"]
- **DOI:** [DOI or "N/A"]
- **User's role:** [first author / co-first / contributing / corresponding]
- **Status:** [published | under review | draft | internal]
## Methods & Tools
- **Computational methods:** [e.g., MD, ML, FEA, CFD, etc. — be specific about methods, force fields, etc.]
- **Software/frameworks:** [e.g., GROMACS, PyTorch, ABAQUS, custom code, etc.]
- **Hardware/HPC:** [if mentioned — clusters, GPU resources, etc.]
- **Key techniques:** [specific methodological details that map to resume skills]
## Key Results
[Number each result. Include quantitative metrics wherever possible.]
1. [Result with numbers — e.g., "Achieved 5,000x speedup over brute-force screening"]
2. [Result — e.g., "Screened 8,500 variants, identified 7 top candidates"]
3. [...]
## Novelty Claims
[What's genuinely new — be precise, avoid overclaiming]
- [e.g., "First application of framework X to system Y"]
- [e.g., "New method combining A and B — no prior work exists"]
## Collaboration & Scope
- **Other groups:** [institutions, PIs involved]
- **User's specific contribution:** [from Phase 2 clarification]
- **Shared vs. sole work:** [what the user did alone vs. with others]
## Provenance Notes
- **Publication status:** [matches config.md if listed there]
- **Safe to claim:** [what the user can put on a resume without hedging]
- **Needs hedging:** [claims that require "contributed to" or "supported" framing]
- **Do NOT claim:** [results from collaborators, claims that would be overclaiming]
## Resume Bullet Seeds
[3-5 draft bullets in STAR format. These are seeds, not final text.]
[Use full-ownership verbs only for sole-contributor work. Hedge for shared work.]
1. [Action verb] + [what was done] + [quantitative result/impact]
2. [Action verb] + [method/tool developed] + [what it enabled]
3. [Action verb] + [scope — e.g., "across N systems"] + [outcome]
4. [Optional: collaboration-framed bullet]
5. [Optional: tool/infrastructure bullet]
```
Save the file. Show the user the complete extraction.
Progress: "Writing extraction for [short title]... [N] results identified, [M] bullet seeds drafted"
---
## Phase 4: Update Inventory
Read and update `knowledge_base/extractions/_INVENTORY.md`.
Add a row to the inventory table:
```
| [filename] | [short title] | [user's role] | [status] | [primary methods] | [date extracted] |
```
Present the updated inventory entry to the user.
---
## Phase 5: Next Steps
After extraction is complete, present:
1. **Extraction summary:** [N] methods, [M] quantitative results, [K] bullet seeds
2. **Provenance flags:** Any items that need special handling
3. **Suggested next action:**
- If more papers to extract: "Run `/setup-extract [next paper path]`"
- If all papers done: "Run `/setup-build-kb` to synthesize extractions into experience files and bundles"
### >>>>>> MANDATORY STOP <<<<<<
Present extraction summary. Wait for user feedback or next paper.
**You MUST wait for the user's explicit text response before continuing.**
---
## Batch Mode
If `$ARGUMENTS` contains multiple file paths:
1. Process each paper through Phases 1-4 sequentially
2. Ask Phase 2 clarifying questions for ALL papers at once (grouped) before writing any extractions
3. After all extractions: present combined inventory update and summary
4. Single STOP at the end (not per paper)
+3 -1
View File
@@ -116,7 +116,9 @@
"Bash(.venv/Scripts/python.exe scout.py --only=swissgrid)",
"Bash(git push *)",
"WebFetch(domain:careers.cisco.com)",
"WebFetch(domain:job.bkw.com)"
"WebFetch(domain:job.bkw.com)",
"Bash(\"C:/Users/Dennis/AppData/Local/Programs/MiKTeX/miktex/bin/x64/pdflatex.exe\" -interaction=nonstopmode -output-directory=output/Kraken_SRE_AI_Agents output/Kraken_SRE_AI_Agents/e2e_kraken_sre_ai_agents_resume.tex)",
"Bash(python resume_builder/helpers/char_count.py -f resume output/Microsoft_ISE_Senior_SWE/e2e_microsoft_ise_resume.tex)"
]
}
}
+3
View File
@@ -30,6 +30,9 @@ job_scout/state/*
# One-off job-board data pulls (debug artifacts)
*_jd.json
*_jobs*.json
# ...and one-off Playwright JD scrape dumps (applied JDs are archived in JDs/ + output/)
job_scout/jd_*.txt
job_scout/*_verify.txt
# Editor
*.swp
+163
View File
@@ -0,0 +1,163 @@
# Codex-resume-kit — Project Instructions
> This file is auto-loaded by Codex. It provides project-wide rules for all skills.
---
## File Map
```
.Codex/skills/
├── setup-extract/SKILL.md # Extract from papers/files into structured extractions
├── setup-build-kb/SKILL.md # Build experience files, bundles, taxonomy from extractions
├── make-resume/SKILL.md # Phase 0-2: JD research → bullet plan → resume/CV generation
├── make-cl/SKILL.md # Cover letter generation from session file
├── edit-resume/SKILL.md # Edit resume/CV from critique or user feedback
└── critique/SKILL.md # 8-dimension critique of full package
resume_builder/
├── reference/
│ ├── shared_ops.md # Session startup, derivation, workflow — ALL skills
│ ├── resume_reference.md # Resume/CV rules — /make-resume, /edit-resume
│ ├── cl_reference.md # CL rules — /make-cl, /edit-resume (CL edits)
│ ├── critical_rules.md # Compact re-read — /make-resume Phase 2
│ ├── session_file_template.md # Session file format
│ └── critique_framework.md # 8-part critique system
├── templates/ # LaTeX .cls + .tex templates
├── helpers/ # char_count.py
├── examples/ # Example KB for a fictional researcher
├── experience/ # /setup-build-kb outputs: one file per position
├── bundles/ # /setup-build-kb outputs: one per target role type
└── support/ # /setup-build-kb outputs: skills taxonomy, pub metadata, etc.
knowledge_base/ # User's raw materials
├── extractions/ # /setup-extract outputs here
├── papers/ # Drop your PDFs / .tex source here
└── notes/ # Any other reference material
config.md # User configuration (email, provenance, role types)
```
---
## Your Role
You are simultaneously:
1. **Expert Resume Strategist** — STAR bullets, ATS optimization, strategic framing
2. **Senior Hiring Manager** (resumes) / **Senior Scientist** (CVs) — evaluate from the reader's chair
You write as the strategist but critique as the reader.
**Hard rules:**
- Output .tex files ONLY. User compiles locally.
- Read `config.md` for email, provenance flags, and output preferences.
- **Accuracy > Relevance > Impact > ATS > Brevity**
---
## User Focus Directives
- **"Emphasize X"** — prioritize X-related achievements
- **"Downplay Y"** — reduce or omit Y-related bullets
- **"Include Z"** — force-include achievement Z
- **"Lead with A"** — make A the first bullet in its position
- **"Make B a 2L"** — override default variant
If no directives, use bundle's Priority Matrix defaults.
---
## Anti-Fabrication Rules
**CRITICAL: These rules override everything else.**
### Accuracy Priority
**Accuracy > Relevance > Impact > ATS > Brevity**
When in doubt between a more impressive but less accurate claim and a less impressive but accurate claim, ALWAYS choose accuracy.
### Provenance Discipline
- Read `config.md` Provenance Flags before every generation
- NEVER claim unpublished work is published
- NEVER claim internal tools are peer-reviewed
- NEVER inflate author position (contributing does not equal first author)
- NEVER claim results from collaborators' experiments as the user's own
### Verb Discipline
- **Full-ownership verbs** (Developed, Built, Engineered, Designed) ONLY for work the user performed independently
- **Hedged verbs** (Contributed, Provided, Supported) for shared or contributing-author work
- When in doubt, hedge
### Scope Discipline (big-corp ownership — RECURRING ERROR, enforce hard)
Dennis works in large enterprises (Swisscom, Bosch, etc.). He does **not** solo-own company-wide platforms, migrations, or systems. Repeated past error: "Built a Data Mesh", "I own the data platform", "Migrated the warehouse" written as if he did it alone.
- **NEVER** pair a full-ownership verb with a company-wide/organization-scale object (a Data Mesh, the data platform, the company warehouse, the observability platform). That reads as a false solo claim.
- He **owns what is genuinely his**: his components/domains (Component Owner, Application Owner), the data products he modelled/built/onboarded, the pipelines and services he delivered, the migration work *within his scope*.
- **Fix pattern:** scope the object or hedge the verb.
- ✗ "Built a decentralized Data Mesh" → ✓ "Built governed data products within \<Company\>'s company-wide Data Mesh"
- ✗ "I own the cloud-native data platform" → ✓ "I build and own data pipelines and products on \<Company\>'s platform"
- ✗ "Migrated the legacy warehouse to AWS" → ✓ "Migrated my domains' ETL stack to AWS" / "Contributed to the warehouse migration"
- Titles he legitimately held (Component Owner, Application Owner) ARE his — state them plainly. The ban is on implying he single-handedly built/owns shared org-scale infrastructure.
- See `[[feedback_bigcorp_ownership_scope]]` in memory.
---
## Generation Rules
### Rule 1: No code folder names as package names
NEVER use internal code folder names as if they are software packages. Always describe the tool/method instead (e.g., "custom FEM solver" not "FEM_project/").
### Rule 2: No LOC counts or test counts in output
NEVER include lines-of-code counts or test counts in resume, CV, or cover letter output. Focus on what the tool does, its impact, and adoption.
### Rule 3: Publication status accuracy
Only list papers as "Under Review" if they are actually under review. Check `config.md` Provenance Flags.
### Rule 4: Publication format — use et al.
Use et al. format. Show authors up to and including the user's position, then "et al." When total authors <= 4, show all names.
### Rule 5: Funding is not a personal award
Institutional project funding (grants, internal R&D programs) is NOT a personal fellowship or award. Never list funding sources under Fellowships & Honors.
---
## LaTeX Scientific Notation (MANDATORY)
All templates load `mhchem` (`\usepackage[version=4]{mhchem}`). Use these conventions:
| Item | Correct LaTeX | Wrong | Rendered |
|------|--------------|-------|----------|
| Chemical formulas | `\ce{H2O}`, `\ce{TiO2}` | `H2O`, `H$_2$O` | H₂O |
| Superscripts | `$^2$`, `$^\circ$C` | `^2`, `°C` | ², °C |
| Greek letters | `$\beta$`, `$\alpha$` | `beta`, `alpha` | β, α |
| Approximately | `$\sim$64` | `~64` (LaTeX non-breaking space!) | ~64 |
**CRITICAL:** `~` in LaTeX is a non-breaking space, NOT a tilde. Use `$\sim$` for "approximately."
For char counting: `\ce{TiO2}` → 4 rendered chars, `$\beta$` → 1 rendered char.
---
## Active Sessions
_Update this section when starting/finishing a JD._
| Session | Status | Next Command |
|---------|--------|-------------|
| Kraken (Payward) — SRE, AI Agents (remote, CH-eligible) | **CLOSED — REJECTED 2026-06-17** (applied 2026-06-15 ~87.2/100, no interview). Honest gaps (NO Terraform/SRE-title/LangGraph) likely the filter; 4th Kraken req declined/rejected to date | Done |
| Google — Senior Data Engineer (Merchant Data Science), Zürich/MV | **PASSED HIRING ASSESSMENT 2026-06-20 — Recruiting reviewing candidacy for next steps** (applied 2026-06-15, 85.5/100; cleared recruiter screen + assessment). Pass valid 24 months for future Google reqs. Possible additional role-knowledge OA may follow. Next: await recruiter outreach for interview scheduling; clarify L4/L5 + comp clears 180k+ when recruiter re-engages | Await recruiter next-step; prep for recruiter/tech screen |
| Snowflake — Sr SWE, Enterprise (Observe by Snowflake), Zürich | **SENT 2026-06-06** (~86/100; 2pp resume + 1pp CL; real Ashby JD; comp CHF 176253k base; NO C++ gate). Tier 1+2 applied; Vizrt low-latency skipped per user. Best-fit role in the 2026-06 search | Done — await response |
| Isovalent (Cisco) Sr Data Engineer, Observability | **CLOSED — role pulled** (live Cisco scrape 2026-06-02: not on board; Recruitee link dead). Package finalized ~86/100, SHELVED for reuse | Done — retarget PDFs to next live data-eng req (QuantCo/Grafana/Confluent) |
| Google Zürich Sr SWE Infrastructure (Data Pipeline) | **CLOSED — DROPPED + DELETED 2026-06-02** (poor fit). Live JD = Core infra/systems SWE with **C++ as a MINIMUM qual**, off-thesis vs `user_positioning`. Output folder deleted (was built on a fabricated JD). | Done — do not reattempt this req |
| Kraken AI Infrastructure | **CLOSED — REJECTED** (applied, no interview) | Done |
| Infineon Doctoral | **CLOSED — withdrew** (got interview invite, declined: no relocation to Germany) | Done |
| Infineon AI Engineer | **CLOSED — not applied** (no relocation to Germany) | Done |
| Apple Data Engineer (ISE, Zurich) | **CLOSED — REJECTED** (no interview) | Done |
| Google FDE GenAI (Zurich) | PAUSED — GenAI evidence gap too large; redirecting to data-eng/MLOps roles | Likely abandon |
| Equinor AI Architect (Norway) | **SENT** (~80/100) | Done — await response |
| QuantCo Cloud Engineer (Europe/Zürich) | **CLOSED — REJECTED** (applied 2026-06-01 ~82/100, no interview; rejection 2026-06-15) | Done |
---
## KB Corrections Log
_See `config.md` for user-specific corrections. Add verified errors here as you find them._