--- name: setup-extract description: Extract source-grounded career evidence from papers, employment records, project documents, and notes into structured knowledge-base files without promoting inference to fact. --- # Source Evidence Extraction 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. ## Required inputs 1. Read `config.md` and the anti-fabrication rules in `AGENTS.md`. 2. Read the complete source material. 3. Check `resume_builder/canonical/claims.json` for existing facts and identifiers. 4. Inspect related extraction files so new evidence does not create a duplicate or contradiction. Generated resumes, cover letters, critiques, and session files under `output/` are never evidence sources. ## Extraction procedure ### 1. Identify the source Record: - source filename and type; - source date, if known; - whether it is primary evidence, user-authored notes, or a secondary description; - the person, employer, project, or publication it concerns. ### 2. Separate evidence from inference For every potentially reusable fact, record: - the source-supported statement; - the exact supporting passage or precise location; - any interpretation separately as `Inference`; - confidence: `verified`, `user-confirmed`, `needs verification`, or `do not use`. Never silently convert an inference into a verified claim. ### 3. Capture career facts precisely When applicable, extract: - exact employer, formal title, location, and start/end dates; - ownership scope and collaborators; - work performed, method, technology, and domain; - outcome and beneficiary; - metrics with units, baseline, period, and attribution; - publication status, authorship position, and venue; - current versus historical skill use; - certification versus practical experience. For large-company work, describe only the user's component, domain, pipeline, service, or contribution. Do not infer ownership of organization-wide platforms or transformations. ### 4. Record claim controls For each major claim, include where useful: - allowed verbs; - verbs or framings that would overstate ownership; - safe resume wording; - known contradictions requiring resolution; - whether a metric is verified, qualitative only, or still missing. ### 5. Write the extraction Create or update a focused Markdown file in `knowledge_base/extractions/`. Use a clear structure such as: ```markdown # Subject ## Source ## Verified facts ## Ownership and attribution ## Outcomes and metrics ## Skills and recency ## Safe claim seeds ## Inferences / open questions ## Conflicts with existing KB ``` Claim seeds are factual building blocks, not polished resume bullets. Do not add unsupported impact language for relevance. ## Publication rules - Never infer `published`, `accepted`, or `under review` from a manuscript file. - Preserve the user's author position. - Institutional funding is not a personal award. - Follow `config.md` provenance flags. ## Completion Report: - files created or updated; - newly verified facts; - unresolved contradictions or missing metrics; - suggested next command: use `setup-build-kb` to promote reviewed evidence into the canonical registry, experience files, bundles, and support files. Do not update canonical claims from an unreviewed extraction.