feat: rebuild evidence-first application workflow
This commit is contained in:
@@ -1,111 +1,62 @@
|
||||
---
|
||||
description: Re-critique existing resume/CV output files against a JD
|
||||
user-invocable: true
|
||||
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
|
||||
|
||||
**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
|
||||
|
||||
---
|
||||
# Critique an Application Package
|
||||
|
||||
## 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).
|
||||
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.
|
||||
|
||||
**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
|
||||
## Preflight
|
||||
|
||||
---
|
||||
Run:
|
||||
|
||||
## Protocol
|
||||
```powershell
|
||||
python resume_builder/helpers/validate_resume_system.py --document <resume.tex>
|
||||
```
|
||||
|
||||
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.
|
||||
Add `--document <cover_letter.tex>` when a letter exists. Any failure is Tier 1 and prevents approval.
|
||||
|
||||
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):
|
||||
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.
|
||||
|
||||
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
|
||||
## Critique
|
||||
|
||||
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
|
||||
Follow `critique_framework.md` exactly:
|
||||
|
||||
Progress: "Reading session file for framing context..." / "Running ATS keyword scan — 16/20 match..." / "Scoring 8 dimensions..." / "Score: 87.0/100"
|
||||
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.
|
||||
|
||||
### >>>>>> 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`.
|
||||
Do not issue a single overall score. Do not label a high-quality document submit-ready when Evidence Fit fails a hard gate.
|
||||
|
||||
### 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]"
|
||||
## 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.
|
||||
|
||||
@@ -1,208 +1,51 @@
|
||||
---
|
||||
description: Edit existing resume/CV or cover letter from critique feedback and user suggestions
|
||||
user-invocable: true
|
||||
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-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
|
||||
|
||||
---
|
||||
# Edit a Resume or Cover Letter
|
||||
|
||||
## 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).
|
||||
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.
|
||||
|
||||
**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
|
||||
## Diagnose
|
||||
|
||||
---
|
||||
Classify requested changes as:
|
||||
|
||||
## Phase 1: Load Context
|
||||
- Truth/provenance correction.
|
||||
- Fit/framing correction.
|
||||
- Information hierarchy or readability.
|
||||
- Content selection.
|
||||
- Mechanical/LaTeX.
|
||||
- Blocked because evidence is absent.
|
||||
|
||||
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]`
|
||||
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.
|
||||
|
||||
**Record baseline in session file** under `## Edit [N] Baseline` (scan existing Edit History sections; next N = max existing + 1, or 1 if none):
|
||||
Present a concise edit plan and wait for explicit confirmation unless the user already approved specific edits.
|
||||
|
||||
```
|
||||
## 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]
|
||||
```
|
||||
## Execute
|
||||
|
||||
Progress: "Reading session file — [company], [role type] bundle..." / "Baseline: 2 pages, 0 char violations, 1 orphan..."
|
||||
- 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
|
||||
|
||||
## Phase 2: Diagnose & Plan Edits
|
||||
Run the validator on every edited document, compile, inspect the PDF, and verify extracted text order. Compare before/after for:
|
||||
|
||||
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)
|
||||
- validator failures;
|
||||
- page count;
|
||||
- employer/title/date visibility;
|
||||
- bullet count and relevance;
|
||||
- duplicated sections;
|
||||
- readability at normal size.
|
||||
|
||||
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.
|
||||
Update the session Edit History, Document Quality, status and next action. Mark the critique stale after material edits. Present results and wait for approval.
|
||||
|
||||
+26
-123
@@ -1,142 +1,45 @@
|
||||
---
|
||||
description: Generate a tailored cover letter from an existing session file and finished resume/CV
|
||||
user-invocable: true
|
||||
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.
|
||||
---
|
||||
|
||||
# /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
|
||||
|
||||
---
|
||||
# Decide and Generate a Cover Letter
|
||||
|
||||
## Startup
|
||||
|
||||
Read `resume_builder/reference/shared_ops.md` for session startup and file derivation.
|
||||
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.
|
||||
|
||||
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
|
||||
## 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.
|
||||
|
||||
## Phase 1: Load Context
|
||||
Do not generate a letter merely because an upload field exists or because older workflow expected a three-page package.
|
||||
|
||||
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`
|
||||
## Plan
|
||||
|
||||
Update session file Status: `Cover Letter: IN_PROGRESS`
|
||||
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.
|
||||
|
||||
Progress: "Loading CL context — [company], [role type] bundle, [institution type]..."
|
||||
If the only possible content repeats resume bullets or paraphrases company news, change the decision to NO and explain why.
|
||||
|
||||
---
|
||||
## Generate
|
||||
|
||||
## Phase 2: Generate Cover Letter
|
||||
- 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.
|
||||
|
||||
Read `resume_builder/templates/coverletter_template.tex`.
|
||||
## Verify
|
||||
|
||||
**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)
|
||||
Run:
|
||||
|
||||
**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
|
||||
```powershell
|
||||
python resume_builder/helpers/validate_resume_system.py --document <resume.tex> --document <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]"
|
||||
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.
|
||||
|
||||
@@ -1,241 +1,90 @@
|
||||
---
|
||||
description: Generate a tailored resume/CV from a JD
|
||||
user-invocable: true
|
||||
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.
|
||||
---
|
||||
|
||||
# /make-resume
|
||||
# Generate a Resume
|
||||
|
||||
**User input:** `$ARGUMENTS`
|
||||
## Input
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
**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.
|
||||
## 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`.
|
||||
|
||||
## Safety Rules (ALWAYS ENFORCED)
|
||||
## Phase 1 — Fit Gate Before Writing
|
||||
|
||||
**Accuracy > Relevance > Impact > ATS > Brevity**
|
||||
Build a requirement table with Required/Preferred and Direct/Adjacent/Gap/Constraint classifications. Cite canonical claim IDs for every Direct or Adjacent match.
|
||||
|
||||
Read `config.md` Provenance Flags before generating any content. Verify every claim against that table.
|
||||
Compute Evidence Fit and identify hard gates using `critique_framework.md`. Then assign:
|
||||
|
||||
- **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
|
||||
- Core.
|
||||
- Adjacent.
|
||||
- Stretch.
|
||||
- No-go.
|
||||
|
||||
---
|
||||
Record Channel Strength and a warm-channel action for Core roles.
|
||||
|
||||
## User Input During Execution
|
||||
Stop and present the fit decision before resume planning when:
|
||||
|
||||
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
|
||||
- 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.
|
||||
|
||||
## Startup
|
||||
## Phase 2 — Audience and Content Plan
|
||||
|
||||
Read `resume_builder/reference/shared_ops.md` for session startup, file derivation, and organization protocols.
|
||||
Select International Tech by default. Use Swiss/DACH or Employer-specific format only when the employer/context supports it.
|
||||
|
||||
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
|
||||
Read the matching role bundle, `skills_taxonomy.md`, `achievement_reframing_guide.md`, and only the experience files needed for selected claims.
|
||||
|
||||
---
|
||||
Plan:
|
||||
|
||||
## Quick Mode
|
||||
- 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.
|
||||
|
||||
Trigger: `$ARGUMENTS` starts with "Quick:"
|
||||
For each proposed bullet show canonical ID, evidence type, scope, and why it belongs. Identify any impact metric that still needs user confirmation.
|
||||
|
||||
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
|
||||
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 0: Research & Session Setup
|
||||
## Phase 3 — Generate
|
||||
|
||||
**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
|
||||
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.
|
||||
|
||||
**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
|
||||
Rules:
|
||||
|
||||
If web search returns no results: use JD text + training knowledge. Flag: "Web search returned limited results — CL hooks may be generic."
|
||||
- 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.
|
||||
|
||||
**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
|
||||
## Phase 4 — Validate and Inspect
|
||||
|
||||
**Create output folder:**
|
||||
Derive folder name from JD filename: `JDs/JD_Acme.txt` → `output/Acme/`
|
||||
```bash
|
||||
mkdir -p output/<FolderName>/
|
||||
Run:
|
||||
|
||||
```powershell
|
||||
python resume_builder/helpers/validate_resume_system.py --document <resume.tex>
|
||||
```
|
||||
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.
|
||||
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.
|
||||
|
||||
**Write memory pointer** to `AGENTS.md` Active Sessions.
|
||||
Update the session with the as-built content, validation results, page count, cover-letter decision, and next action.
|
||||
|
||||
**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]"
|
||||
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`.
|
||||
|
||||
@@ -1,329 +1,82 @@
|
||||
---
|
||||
description: Synthesize completed extractions into the knowledge base files needed for resume generation
|
||||
user-invocable: true
|
||||
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.
|
||||
---
|
||||
|
||||
# /setup-build-kb
|
||||
# Build or Update the Knowledge Base
|
||||
|
||||
**User input:** `$ARGUMENTS`
|
||||
## Authority Model
|
||||
|
||||
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
|
||||
The pipeline is:
|
||||
|
||||
---
|
||||
`source documents -> extractions -> canonical claims -> experience records/bundles -> generated applications`
|
||||
|
||||
## Startup
|
||||
Generated applications never flow backward into the KB.
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
**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?"
|
||||
## Canonical Claim Record
|
||||
|
||||
Progress: "Found [N] extractions across [M] positions. Config has [K] role types defined."
|
||||
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.
|
||||
|
||||
## Phase 1: Build Experience Files
|
||||
When ownership is ambiguous, use contributing/shared scope and ask the user. Do not default to full ownership.
|
||||
|
||||
**Goal:** Create one experience file per position, containing all achievements organized for resume generation.
|
||||
## Experience Files
|
||||
|
||||
**Read:** All extraction files listed in `_INVENTORY.md`
|
||||
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.
|
||||
|
||||
**For each position** (from `config.md` or inferred from extraction metadata):
|
||||
Every achievement section must include canonical ID, source, ownership scope, status, verified result/metric state, relevant skills and role relevance.
|
||||
|
||||
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?"
|
||||
## Skills Taxonomy
|
||||
|
||||
**Experience file format** (`resume_builder/experience/experience_<position_key>.md`):
|
||||
Use only these evidence levels:
|
||||
|
||||
```markdown
|
||||
# Experience: [Position Title] — [Institution]
|
||||
## [Date Range]
|
||||
- Production — current.
|
||||
- Production — historical.
|
||||
- Hands-on — current.
|
||||
- Project / proof of concept.
|
||||
- Certification / coursework.
|
||||
- Unverified / never used.
|
||||
|
||||
### 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]
|
||||
Do not assign Expert/Proficient/Familiar labels. Add a skill to canonical claims before it can appear in a generated document.
|
||||
|
||||
---
|
||||
## Role Bundles
|
||||
|
||||
### 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]
|
||||
Each bundle must contain:
|
||||
|
||||
**Context:** [1-2 sentences — what problem, why it matters]
|
||||
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.
|
||||
|
||||
**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]
|
||||
Bundles may rank evidence; they may not broaden it. Title-defining gaps must be stated explicitly.
|
||||
|
||||
**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]
|
||||
## Significance Context
|
||||
|
||||
---
|
||||
[Repeat for each achievement]
|
||||
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
|
||||
```
|
||||
|
||||
### >>>>>> 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.**
|
||||
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.
|
||||
|
||||
@@ -1,170 +1,101 @@
|
||||
---
|
||||
description: Extract structured information from research papers, PDFs, or code into knowledge base extractions
|
||||
user-invocable: true
|
||||
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.
|
||||
---
|
||||
|
||||
# /setup-extract
|
||||
# Source Evidence Extraction
|
||||
|
||||
**User input:** `$ARGUMENTS`
|
||||
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.
|
||||
|
||||
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
|
||||
## 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.
|
||||
|
||||
## Startup
|
||||
Generated resumes, cover letters, critiques, and session files under `output/` are never evidence sources.
|
||||
|
||||
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
|
||||
## Extraction procedure
|
||||
|
||||
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
|
||||
### 1. Identify the source
|
||||
|
||||
---
|
||||
Record:
|
||||
|
||||
## Phase 1: Read & Understand the Paper
|
||||
- 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.
|
||||
|
||||
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
|
||||
### 2. Separate evidence from inference
|
||||
|
||||
**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
|
||||
For every potentially reusable fact, record:
|
||||
|
||||
Progress: "Reading paper... [title] by [first author] et al., [year]"
|
||||
- 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.
|
||||
|
||||
## Phase 2: Clarify User's Role
|
||||
### 3. Capture career facts precisely
|
||||
|
||||
If the user's contribution is not obvious from the paper (common for multi-author work), ask:
|
||||
When applicable, extract:
|
||||
|
||||
**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)"
|
||||
- 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.
|
||||
|
||||
### >>>>>> 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.**
|
||||
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
|
||||
|
||||
## Phase 3: Write Extraction
|
||||
For each major claim, include where useful:
|
||||
|
||||
Create the extraction file at `knowledge_base/extractions/<AuthorYear_short_descriptor>.md`
|
||||
- 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.
|
||||
|
||||
**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
|
||||
### 5. Write the extraction
|
||||
|
||||
**Extraction format:**
|
||||
Create or update a focused Markdown file in `knowledge_base/extractions/`. Use a clear structure such as:
|
||||
|
||||
```markdown
|
||||
# [Full Paper Title]
|
||||
# Subject
|
||||
|
||||
## 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]
|
||||
## Source
|
||||
## Verified facts
|
||||
## Ownership and attribution
|
||||
## Outcomes and metrics
|
||||
## Skills and recency
|
||||
## Safe claim seeds
|
||||
## Inferences / open questions
|
||||
## Conflicts with existing KB
|
||||
```
|
||||
|
||||
Save the file. Show the user the complete extraction.
|
||||
Claim seeds are factual building blocks, not polished resume bullets. Do not add unsupported impact language for relevance.
|
||||
|
||||
Progress: "Writing extraction for [short title]... [N] results identified, [M] bullet seeds drafted"
|
||||
## 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.
|
||||
|
||||
## Phase 4: Update Inventory
|
||||
## Completion
|
||||
|
||||
Read and update `knowledge_base/extractions/_INVENTORY.md`.
|
||||
Report:
|
||||
|
||||
Add a row to the inventory table:
|
||||
- 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.
|
||||
|
||||
```
|
||||
| [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)
|
||||
Do not update canonical claims from an unreviewed extraction.
|
||||
|
||||
Reference in New Issue
Block a user