feat: rebuild evidence-first application workflow
This commit is contained in:
@@ -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