0 Fork 0

Files

T

dennisthiessenandClaude Opus 5 afdef7eb94 refactor: shared agent workflows (F01) and one application registry (F02)

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

2026-09-11 19:23:13 +02:00

3.1 KiB

Raw Blame History

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

Read config.md and the anti-fabrication rules in AGENTS.md.
Read the complete source material.
Check resume_builder/canonical/claims.json for existing facts and identifiers.
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:

# 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.

3.1 KiB Raw Blame History