---
name: "expertise_capture_from_artifacts"
description: "Turns someone's own documents, chats, and emails into a usable knowledge skill: extracts claims with provenance, interviews the person to fill gaps, and validates before the skill claims to speak for them. Use when building a personal knowledge base, onboarding an agent to someone's workflow, or converting scattered expertise into a skill someone else could run."
---

# Expertise Capture from Artifacts

## Purpose
Raw documents do not make a skill. This method converts a person's scattered artifacts (docs, notes, chat exports, emails) into a skill that genuinely represents their expertise: claims extracted with provenance, gaps found by comparing claims against the job the skill must do, gaps closed by interview, everything validated before the skill ships. The signature move is the validation step. A skill that has not passed it does not get to claim it speaks for the person.

## Workflow
1. **Consent and scope.** Confirm in writing: which artifacts are in scope, what is off-limits, where the captured knowledge may live and be shared, and what must be redacted. If the person has not said yes to a source, it is not a source. Stop and ask if anything is unclear.
2. **Inventory.** List every artifact with its date range, format, and staleness risk. Flag obvious gaps (e.g. "no notes from 2024") and contradictions ("doc A says X, email B says not-X"). Write the inventory down; it becomes your provenance map.
3. **Extract claims.** Read the artifacts and pull out atomic claims: one fact, rule, preference, or procedure per line, in the person's own terms where possible. Every claim gets a source pointer and a status. See references/validation-and-claim-schema.md for the exact format. Do not paraphrase away nuance to make claims fit.
4. **Gap-find.** Write down what the skill must be able to answer (competency questions: "when the user asks X, what should it say?"). Match claims against those questions. Every question with no claim behind it is a gap; every contradiction is a gap; every low-confidence claim is a gap. This list becomes your interview plan.
5. **Interview to close gaps.** Prefer incident probes over general questions: ask about a specific hard case ("walk me through the last time you had to...") instead of "how do you usually...". The Critical Decision Method family of probes works: cues noticed, options rejected and why, what a novice would have missed, what-if variations. Full question bank in references/interview-question-bank.md. Every interview answer becomes a new claim with `src: interview <date>`.
6. **Validate.** Run `bin/claim_check.py` on the claims file. Resolve every contradiction by asking the person which is right (do not pick for them). Then run a coverage check: take three real past situations the skill should have handled and confirm each answer the skill would give matches what the person actually did. Anything that fails becomes a new interview round.
7. **Person sign-off.** Show the person the finished skill and the claim list. They confirm it represents them before it is published anywhere. No silent publishing.
8. **Author the skill.** Write the skill in skill-creator format from the validated claims only. Unverified claims stay out or get marked as opinion.

## Output Contract
- A claims file using the schema in references/validation-and-claim-schema.md (every claim: text, source, date, status).
- `bin/claim_check.py` run, all errors resolved, verification summary recorded.
- A SKILL.md authored from validated claims only, plus the source inventory.
- Written confirmation from the person that the skill represents them.

## Operating Rules
- Provenance on every claim, no exceptions. A claim without a source is not a claim.
- Never invent numbers, dates, quotes, or events. Unverifiable material is cut or labeled as the person's opinion.
- Conflicts between sources go to the person, never resolved by inference.
- Prefer incident-based probes over abstract questions; expertise shows up clearest in hard, specific cases.
- Keep personal data local by default: do not send someone's emails or private notes to external services without explicit permission for that destination.
- Redact third-party secrets, names, and private details that are not needed for the skill to work.
- The person reviews before anything publishes. Their sign-off is the quality gate, not your judgment.