Imported from Dgun1900/claude-setup (skills/vault-wiki-compiler/SKILL.md). Install upstream with npx skills add Dgun1900/claude-setup --skill vault-wiki-compiler. Copyright stays with the author.

Vault Wiki Compiler (v1 — propose-only)

This skill automates the knowledge-capture step that otherwise depends on you manually logging every useful fact. It reads what's new in your capture folders, pulls out the reusable ideas, and proposes where each belongs in your internal wiki — but it stops at a proposal. You stay the filter.

Think of it as a librarian who reads everything that landed on the "to file" shelf, drafts a filing plan, points out where a new note contradicts something already on the shelves, and hands you the plan to approve. Nothing gets shelved until you say so.

What this skill does

1. Reads its own marker file to find documents added since the last run.
2. Extracts the key concepts from each new document.
3. Proposes where each concept should be routed inside knowledge/.
4. Flags contradictions against existing knowledge/*/knowledge.md, hypotheses.md, and rules.md entries.
5. Proposes a new topic article when a concept appears in 3 or more distinct new source files.
6. Writes ONE staged report to Scratch pad/ and stops.
7. Updates its own marker file so the next run is incremental.

What this skill does NOT do (v1 hard constraints)

• Never writes into knowledge/ directly. No edits to any knowledge/*/knowledge.md, hypotheses.md, or rules.md file. Direct-write mode is a v2 decision, made only after you've reviewed several reports and trust the output.
• Never edits knowledge/index.md or any other shared index file.
• Does not delete or move source files in Scratch pad/ or Meetings/.
• Does not exclude any document by sensitivity — it scans everything in scope. The report itself is the review gate; you are the filter, not the scan.

Marker file

Path: Skills/vault-wiki-compiler/last-run.json

{
  "last_run_at": "2026-01-15T14:00:00-06:00",
  "files_seen": [
    "Scratch pad/260114 Weekly Planning Notes.md",
    "Meetings/260112 Vendor Kickoff Call.md"
  ]
}

• last_run_at: timestamp of the previous run's completion. On the first run, this file does not exist — treat every file in Scratch pad/ and Meetings/ as new.
• files_seen: the full relative-path list of every file the last run considered "new" and processed (whether or not it produced a routing proposal). Kept so that a file which yields zero extractable concepts still isn't re-scanned every run.
• Update this file only as the LAST step, after the report is written successfully. If the report write fails, do not touch the marker — the next run must retry the same file set.

Step 1 — Find new documents

"New" = file modified-time later than last_run_at AND filename not already in files_seen. (The second half catches files whose modified-time predates the marker because of a sync or copy, but which were never actually processed.)

Scope: every file directly inside Scratch pad/ and Meetings/. Confirm both are flat directories first; if a subfolder appears, scan it too and note the deeper path in the report.

Skip: any file this skill produced on a prior run (filename pattern NNNNNN Vault Wiki Compiler Report.md) — never treat your own past output as a new source.

If there are zero new files: write a one-line report noting "No new documents since [last_run_at]" and update the marker with last_run_at = now. Do not invent findings to fill the page.

Step 2 — Extract concepts per file

For each new file, read it and pull out discrete, named concepts — not a summary of the whole document. A concept is worth extracting when it is:

• A fact, decision, number, rule, or observed pattern that could inform future work, OR
• A named entity plus a relationship (a person's role, a vendor's product, a system's behavior), OR
• A stated theory, prediction, or plan about something not yet confirmed (hypothesis-shaped).

Do not extract: personal correspondence with no reusable fact, pure scheduling logistics (a meeting's time and place), or content that is just a copy of something already in knowledge/. Check before extracting — if the fact already exists verbatim or near-verbatim in the target domain's files, skip it; it isn't new.

Each extracted concept gets: a one-sentence statement, the source file, a short source quote or paraphrase for traceability, and a fact-vs-speculative classification (Step 4).

Step 3 — Routing rules (apply explicitly, in this order)

Route each concept to the FIRST matching domain in your knowledge/ base. Every knowledge/ deployment is different, so build the routing table from whatever domain folders actually exist in your own knowledge/ — list them (ls knowledge/) at the start of the run and match each concept to the folder whose scope fits best.

A generic routing table looks like this — replace the rows with your own domains:

Sub-file check (do this before routing to ANY domain). A domain folder may hold more than the standard three files (knowledge.md, hypotheses.md, rules.md). Before writing a routing proposal, ls the target domain folder and look for any additional named file. If one exists and the concept's subject matches that file's evident scope more specifically than the domain's general knowledge.md, propose the addition to that sub-file instead. Don't assume the standard three files are the only targets without checking.

Tie-break rule. If a concept plausibly fits two or more domains, route it to the MORE SPECIFIC domain — a copy-wording rule beats a general-tool fact; a system-mechanics fact beats a general copy rule. State the tie-break reasoning in one clause in the report.

No existing domain fits. Do not force it into the nearest existing folder. Mark it a new-domain candidate instead (Step 6 decides when that becomes a formal proposal). Do not silently drop it — mark it UNROUTED.

Step 4 — Fact vs. speculative classification

For every routed concept, decide which file it would land in IF approved:

• knowledge.md (facts) — the source states something as already true, decided, or observed: a completed action, a confirmed number, a system behavior that was directly witnessed, a decision that was made. Look for past tense, confirmed outcomes, "as of [date]", direct-observation language.
• hypotheses.md (speculative) — the source states a theory, prediction, plan, or untested expectation: "should", "might", "we think", "the idea is", forward-looking claims not yet confirmed by outcome. Auto-extracted concepts default here whenever confidence is ambiguous — do not default to knowledge.md when unsure.
• Never propose a rules.md entry directly. Promotion from hypotheses.md to rules.md should happen through your own confirmation process (see knowledge/index.md), not through this skill.

Step 5 — Contradiction test (apply mechanically, in this order)

Before proposing an addition, check the routed domain's existing knowledge.md, hypotheses.md, and rules.md for an entry about the SAME subject (same named thing — same system, same policy, same number's referent).

If there's no existing entry on the same subject: not a contradiction. Proceed as a plain addition.

If an existing entry on the same subject states a DIFFERENT value or claim than the new source:

1. Check whether the new source's date is later than the existing entry's last_verified date.
2. Check whether the new source uses explicit supersession language about that same fact: "now", "as of [date]", "replaces", "updated to", "changed to", "no longer".
3. Both true (later date AND supersession language) → classify as "likely supersession." Propose it as an update note pointing at the specific existing entry, not a bare contradiction. This still requires your approval before anything is edited.
4. Either condition fails → classify as "contradiction." Flag the existing entry (quote it, with its file and line) and the new claim (quote it, with its source file) side by side. Do not guess which one is right. Default to contradiction whenever uncertain — that's the safe failure mode.

Step 6 — New topic article test

Track every routed (non-unrouted) concept across all the new files in this run by a normalized concept key — same subject, loose text match (e.g. "onboarding cadence" and "onboarding sequence timing" are the same concept if they describe the same thing).

If a concept key appears in 3 or more distinct source files in this run: propose it as a candidate for a new standalone topic article (not just a knowledge.md line item) inside its routed domain folder. Name the proposed article, list all contributing source files, and give a 2–3 sentence draft summary.

"3 or more distinct source files" means files, not runs — all three can appear in the same run. The trigger for THIS report is 3+ files gathered in this run's own extraction pass. Note any prior partial count as a courtesy, but don't auto-promote across runs.

If 5 or more unrouted concepts share the same subject across 3+ files: propose a new-domain candidate instead of a topic article, with a suggested domain name (short, lowercase, consistent with your existing names).

Step 7 — Write the report

Filename: Scratch pad/YYMMDD Vault Wiki Compiler Report.md (today's date, your file-naming convention).

Structure:

# Vault Wiki Compiler Report — YYMMDD

Run window: [last_run_at] to [now]
New documents scanned: N (list filenames)
Documents with zero extractable concepts: N (list filenames)

## Proposed Additions

### [domain]/knowledge.md
- **[Concept statement]** — Source: [file]. Quote: "[...]"

### [domain]/hypotheses.md
- **[Concept statement]** — Source: [file]. Quote: "[...]"

## Contradictions Flagged

- **Subject:** [subject]
  **Existing ([domain]/[file], last_verified [date]):** "[quote]"
  **New claim (Source: [file]):** "[quote]"
  **Classification:** Contradiction | Likely supersession (reasoning: [...])

## New Topic Article Candidates

- **Proposed article:** [name] in [domain]/
  **Appears in:** [file1], [file2], [file3]
  **Draft summary:** [2-3 sentences]

## New Domain Candidates

- **Proposed domain:** [name]
  **Rationale:** [...]
  **Concepts that would route here:** [...]

## Unrouted (single mention, no domain fit, below new-domain threshold)

- [concept] — Source: [file]

## Approval

Mark each item above Approved / Rejected / Modify, then hand it back to apply.
Nothing above has been written to knowledge/ yet.

If a section has zero entries, keep the heading and write "None this run" — don't omit headings, so the report shape stays predictable run over run.

Step 8 — Update the marker file

Only after the report file is confirmed written: update Skills/vault-wiki-compiler/last-run.json with last_run_at = now and files_seen = the union of the old list and every file processed this run.

Notes for future runs

• If you approve items from a prior report, note in the NEXT report's intro which prior report they came from and confirm they aren't re-proposed (check files_seen and the prior report's approvals before re-extracting the same file).
• This skill has no write access to knowledge/ by design in v1. If you ask it to "apply" a report, that is a separate, explicit request — running the compiler is never implicit permission to also write the approved items.