dennisthiessenandClaude Opus 5
afdef7eb94
Checkpoint for the 2026-09-11 project review remediation. Work by a previous agent that ran out of context; committed unchanged as a rollback point before the remaining findings land on top of it. F01 — the two agent directories had drifted into different processes - Six shared workflows under `resume_builder/reference/workflows/`; both `.agents/skills/` and `.claude/skills/` are now thin entrypoints that route to the same file instead of carrying full copies. - The `.claude` copies were the stale side: fixed bullet line variants and character budgets that the newer process had already dropped. Removing them is the point of the change, not collateral. - Parity/link regression test added; corrected the top-level file map, which pointed at a directory that does not exist. F02 — application status was stored in four places and disagreed - New registry `job_scout/state/applications.json` (26 records) with `application_records.py` (schema, validation, transactional write) and `application_tracker.py` (add/update, no quota). - AGENTS.md and CLAUDE.md no longer keep their own status tables; both point at `current_applications.md`, generated from the registry. - Interview-reached is now independent of outcome, so a withdrawal after an interview can record both facts. The old tables are preserved verbatim in `job_scout/state/history/application_status_before_2026-09-11.json`. Verification: `python -m unittest discover -s tests -v` — 18/18 pass. Spot-checked that the detailed SBB and Kdo Cy notes survived the migration into the registry rather than being flattened. Known unresolved, deliberately not invented (see FIX_PROGRESS.md): Aker BP's application date and its Adjacent-despite-79 classification. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Qej5SBvhcbGXHwLqNWiskM
99 lines
3.1 KiB
Markdown
99 lines
3.1 KiB
Markdown
<!-- Shared workflow version: 2026-09-11 -->
|
|
|
|
# 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.
|