michal/ckb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Remove legacy Claude config files

Browse source
This commit is contained in:
Michał Kopeć 2026-07-29 22:21:17 +02:00
parent 0be7a60ac9
commit f879f859e3
5 changed files with 8 additions and 605 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
.claude/skills Symbolic link
View file

@ -0,0 +1 @@
../.agents/skills

181
.claude/skills/export-okf/SKILL.md
View file

@ -1,181 +0,0 @@
---
name: export-okf
description: Export the local wiki/ knowledge base as an Open Knowledge Format (OKF) v0.1-conformant bundle at outputs/okf/, so any generic OKF tool can consume it. Use when the user asks to "export the wiki as OKF", "generate the OKF bundle", "export to OKF", "publish the OKF export", or "sync outputs/okf".
---
# Export to OKF skill
## Purpose
Regenerate `outputs/okf/` from the current `wiki/` tree as a bundle that
conforms to Google's Open Knowledge Format (OKF) v0.1 spec
(https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md),
so any generic OKF consumer (e.g. Google's reference graph visualizer) can
read this knowledge base without needing to understand this repo's richer,
more opinionated schema (`confidence`, `quality`, `retention`, `supersedes`,
dual-linking, the cascade layers). This is a one-way, on-demand export —
`wiki/` stays the authoritative source; `outputs/okf/` is always a derived
artifact of it, never edited by hand and never fed back in.
This skill only runs when explicitly invoked — it is deliberately not part
of the always-loaded `CLAUDE.md`/`AGENTS.md` Ingest/Lint workflows, so its
mapping ruleset doesn't tax every session's context.
## Trigger phrases
Use this skill when the user says things like:
- "export the wiki as OKF" / "export to OKF"
- "generate the OKF bundle" / "regenerate outputs/okf"
- "publish the OKF export"
- "sync outputs/okf with the wiki"
## How to run this skill
### Step 1 — Read the source tree
Read every file under `wiki/` (the whole tree, including `entities/`,
`graph/`, and any other subdirectories present). Note which filenames are
`index.md` or `log.md` at any depth (these are OKF's two reserved names) —
everything else is a concept document.
### Step 2 — Clear and rebuild `outputs/okf/`
`outputs/okf/` is a pure, fully-regenerated build artifact. Delete its
current contents (if any) and rebuild it from scratch by mirroring `wiki/`'s
directory structure 1:1 under `outputs/okf/`. Never hand-patch an existing
export — always regenerate the whole bundle, so it can't accumulate stale
files left over from wiki pages that were since renamed or removed.
Do not touch anything outside `outputs/okf/`. Do not run any `git`
commands — regenerating files is this skill's job; staging and committing
the result is a separate, explicit action left to the user.
### Step 3 — Transform concept documents (every file that isn't `index.md`/`log.md`)
For each such file, rewrite its frontmatter using this field mapping:
| wiki/ field | OKF output field | Rule |
|---|---|---|
| `type` | `type` | passthrough (required on both sides — every wiki page should already have one; if a page is somehow missing it, use `type: unknown` and flag it in the final report rather than skipping the file) |
| `resource` | `resource` | passthrough |
| `tldr` | `description` | rename |
| `last_updated` | `timestamp` | passthrough as-is (bare `YYYY-MM-DD` is a valid ISO 8601 date — do not fabricate a time-of-day that was never recorded) |
| *(none — derive)* | `title` | the first `# H1` heading in the body; if there is none, slugify the filename (e.g. `foo-bar.md` → "Foo Bar") |
| `confidence`, `quality`, `retention`, `supersedes`, `superseded_by`, `freshness_window_days` | same key names | passthrough unchanged, as OKF extension fields — OKF requires consumers to tolerate unrecognized keys, so these ride along as-is |
| `kb_schema_version` (only ever present on `wiki/index.md`) | *(omit)* | OKF's root `index.md` frontmatter is spec-limited to `okf_version` only; this key has no valid home in the bundle and is dropped, not relocated |
| *(none)* | `tags` | omit — there is no source field to derive it from; do not fabricate |
Then rewrite the body's links:
1. **Strip wikilinks.** Every dual-link in the source looks like
`[[Page Name]] / [Page Name](path.md)`. Delete the `[[...]]` half
(and the ` / ` separator if present), keep only the
`[text](path.md)` half. OKF has no wikilink concept.
2. **Rewrite repo-root-absolute intra-wiki links.** A link like
`/wiki/entities/foo.md` becomes `/entities/foo.md` — the OKF bundle
root is `outputs/okf/`, not the repo root, so the leading `/wiki`
segment must be stripped. Plain relative links (e.g.
`../entities/foo.md`) need no change, since the export mirrors
`wiki/`'s tree exactly.
3. **Leave `linked/<name>/...` and `libs/<name>/...` references
untouched.** These point outside `wiki/` and outside any
self-contained bundle — converting or inlining them is out of scope.
OKF explicitly tolerates broken links, so leaving these as
unresolvable-outside-the-repo references is spec-compliant. Count
how many of these you leave untouched, for the final report.
### Step 4 — Regenerate `index.md` files
**Root `outputs/okf/index.md`:** frontmatter contains *only*
`okf_version: "0.1"` — this is the one documented exception to "index.md
has no frontmatter" in the OKF spec. Body is a flat bullet list, one line
per linked page or subdirectory, in the form
`* [Title](path) - one-line description` (reuse each page's `description`,
i.e. the renamed `tldr`, as the description text). Drop the source
`wiki/index.md`'s "Use when" column entirely — it's a Claude-agent-only
lazy-loading optimization with no meaning to a generic OKF consumer — and
drop any prose sections (like the source's "## Entity Pages" paragraph).
**Every nested `index.md`** (`entities/index.md`, `graph/index.md`, and
any future topic-folder index): no frontmatter, ever. Strip the source's
explanatory prose and italic placeholder notes (e.g.
"*(No entities yet — populated on the next ingest.)*"), keeping only the
bullet list — an empty list is spec-valid if the directory has no pages
yet.
### Step 5 — Regenerate `log.md` files
For each `log.md` in the source tree (root and any subdirectory), reformat
its entries into OKF's convention: group entries by date under
`## YYYY-MM-DD` headers (date only, no time, newest date first), each
entry as a bullet:
```
* **Verb**: description with [links](/path/to.md) (source: original source text).
```
Map the source's `ACTION TYPE` to an OKF verb: `CREATE` → Creation,
`UPDATE` → Update, `DELETE` → Deprecation, `RESTRUCTURE` → Update (fallback
for anything else). Fold the source entry's `- **Source:**` line in as the
trailing parenthetical shown above rather than dropping it — it's useful
provenance information and OKF's format has room for free text after the
verb. Drop the `---` horizontal-rule separators between entries; they are
not part of OKF's log format.
### Step 6 — Handle non-reserved special pages
`wiki/error-book.md` and `wiki/overview.md` are not OKF reserved
filenames (only `index.md` and `log.md` are) — export them as ordinary
concept documents using the Step 3 rules like any other page. They should
already carry `type`/`tldr`/`last_updated` frontmatter; if you ever find
one that doesn't, that's a lint problem in the source wiki — flag it in
the report rather than silently patching the export.
### Step 7 — Validate the output bundle
Before reporting done, re-check the *generated* `outputs/okf/` bundle
against OKF's own conformance criteria (the same shape of check `CLAUDE.md`
§5 step 1 runs against the source wiki):
- Every non-reserved `.md` file has frontmatter with a non-empty `type`.
- The root `index.md`'s frontmatter contains only `okf_version` (or is
empty); every nested `index.md` has no frontmatter at all.
- Every `log.md` entry matches the `## YYYY-MM-DD` header pattern.
- Every intra-bundle link (i.e. every link you did NOT leave untouched in
Step 3.3) resolves to a file that actually exists in `outputs/okf/`. If
the rewrite in Step 3.2 produced a link that doesn't resolve, that's a
bug in this export, not an acceptable "broken link" — fix it before
reporting done, don't just note it as a warning.
### Step 8 — Report
Tell the user:
- How many concept documents were exported.
- How many `index.md`/`log.md` files were regenerated.
- How many `linked/`/`libs/` cross-cascade references were left
unconverted (Step 3.3), since those won't resolve if the bundle is ever
moved or shipped standalone.
- Any conformance issues found in Step 7 and whether they were fixed.
- A reminder that `outputs/okf/` has been regenerated on disk but not
staged or committed — that's a separate step for the user to take when
ready to publish the update.
## Edge cases
- **Empty `wiki/entities/` or `wiki/graph/`** (as of writing, both are
empty): still regenerate their `index.md` as an empty bullet list under
`outputs/okf/entities/` and `outputs/okf/graph/` — an empty index is
spec-valid, don't skip the directory entirely.
- **A wiki page missing `type`:** per Step 3, use `type: unknown` and flag
it in the report — this indicates the source wiki itself failed lint's
conformance check (see `CLAUDE.md` §5 step 1), which is worth surfacing
to the user rather than quietly masking it in the export.
- **A future `wiki/archived/` directory:** export it like any other
subdirectory (mirror the structure, apply the same per-file rules) —
OKF has no notion of archival status; `retention`/`freshness_window_days`
already ride along as extension fields for any consumer that cares.
- **Re-running the skill with no wiki changes since the last run** should
produce byte-identical output — if you notice non-determinism (e.g. from
arbitrary ordering when listing directory entries), sort filenames
alphabetically wherever you're generating a bullet list or walking a
directory, so re-runs are stable.

199
.claude/skills/sync-changes/SKILL.md
View file

@ -1,199 +0,0 @@
---
name: sync-changes
description: Reconcile this repo's git history with its origin remote — pull down remote commits, commit any local working-tree changes, resolve any conflicts with the user, then push. Use when the user asks to "sync changes", "sync with git", "sync with the remote", "sync with origin", "push and pull my changes", "reconcile git", or "sync the repo". This is a git-level operation, distinct from the content-level "Sync the wiki" / "Ingest" workflow in CLAUDE.md, which processes raw/inbox/ into structured wiki/ pages.
---
# Sync changes skill
## Purpose
Keep this repo's local working tree and its `origin` remote in sync in both
directions: pull remote commits down, commit local file changes, resolve any
conflicts with the user, then push. `wiki/`, `outputs/`, `workload/`, and
every other tracked path are treated as opaque files at this layer — this
skill only does git mechanics (stage/commit/fetch/merge/push). It never
invokes the Ingestion Workflow, never re-derives entities/graph/index/log
content, and never tries to semantically reconcile markdown or frontmatter —
a conflicted file is just text with conflict markers until the user says
otherwise.
Unlike the `export-okf` skill, this skill **does** commit and push on its
own once conflicts (if any) are resolved — that automation was explicitly
requested for this skill.
## Trigger phrases
Use this skill when the user says things like:
- "sync changes"
- "sync with git" / "sync with the remote" / "sync with origin"
- "push and pull my changes"
- "reconcile git"
- "sync the repo"
Do **not** use this skill for bare "Sync" or "Sync the wiki" — those trigger
the content-level Ingestion Workflow in `CLAUDE.md`/`AGENTS.md` §3 instead
(processing `raw/inbox/` into `wiki/`), which this skill has nothing to do
with.
## How to run this skill
### Step 1 — Pre-flight safety checks
Run:
```bash
git rev-parse --is-inside-work-tree
git status --porcelain=v1
```
Check for an in-progress merge/rebase/cherry-pick:
```bash
test -f .git/MERGE_HEAD && echo "MERGE IN PROGRESS"
test -f .git/REBASE_HEAD -o -d .git/rebase-merge -o -d .git/rebase-apply && echo "REBASE IN PROGRESS"
test -f .git/CHERRY_PICK_HEAD && echo "CHERRY-PICK IN PROGRESS"
```
If any of these report something in progress, **stop immediately**. Tell
the user a git operation is already underway and must be resolved or
aborted manually (`git merge --abort` / `git rebase --abort`) before running
this skill again. Do not try to clean it up yourself.
Scan the `git status --porcelain` output for paths that look like secrets:
`.env`, `.env.*`, anything containing `credentials`, `*.pem`, `*.key`,
`id_rsa*`, anything containing `secret` (case-insensitive). If any match,
ask the user via `AskUserQuestion` whether to include or skip each one
*before* staging anything in Step 3 — never silently commit or silently
drop a flagged file.
### Step 2 — Detect the first-run / unrelated-histories case
```bash
git fetch origin
git rev-parse HEAD # fails with "unknown revision" if local has no commits yet
git rev-parse origin/main # fails if the remote branch doesn't exist/is empty
```
- **Local `HEAD` exists** → go to Step 3, regardless of remote state.
- **Local `HEAD` doesn't exist, and `origin/main` doesn't exist or is empty**
→ this is a plain first publish, not a reconciliation. Proceed
automatically to Step 3 (it will just commit and push with nothing to
merge).
- **Local `HEAD` doesn't exist, but `origin/main` already has commits** →
**hard stop, every time this is detected.** Show the user:
```bash
git log origin/main --oneline | head -20
git status --porcelain # everything currently on local disk, untracked
```
Then ask via `AskUserQuestion` with exactly these three options:
- "Merge — bring in origin/main's history (`git merge --allow-unrelated-histories origin/main` after committing local content), then resolve any conflicts"
- "Remote wins — check out origin/main first (`git reset --hard` is not needed since there's no local commit yet; instead branch from origin/main), then reapply my local changes on top of it"
- "Stop — I'll sort this out myself"
Do **not** offer a fourth "discard remote, force local to become main"
option — that requires a force-push and is out of scope for this skill;
if the user wants that, tell them it needs to be done manually. Execute
only the option chosen, then continue to Step 3 with whichever git state
results.
### Step 3 — Steady-state flow
Order matters: **commit local changes first, then fetch/merge, then push.**
Committing first turns any overlap into an ordinary merge conflict (which
Step 4 already knows how to present), rather than a stash-pop conflict with
no commit boundary to fall back on.
```bash
# Commit local changes, if any (skip entirely if git status --porcelain is clean)
git add <path1> <path2> ... # explicit paths only — never `git add -A` or `git add .`
git commit -m "Sync: local changes as of <ISO timestamp>"
# Reconcile with remote
git fetch origin
git merge origin/main # merge, never rebase — rebase would rewrite local commits
# and require a force-push, which is out of scope here
```
Outcomes of the merge:
- `Already up to date.` or a clean auto-merge → continue below.
- `CONFLICT` → go to Step 4, then come back here once every conflict is
resolved and committed.
```bash
# Push
git push origin main
```
If the push is rejected as non-fast-forward (the remote moved again between
fetch and push), retry the fetch → merge → push cycle **exactly once**. If
it fails again, stop and report the raw error to the user — never force,
never retry more than once.
### Step 4 — Present each conflict to the user
```bash
git diff --name-only --diff-filter=U
```
For each path returned, read the full file. It may contain more than one
conflict block — handle each independently, leaving all surrounding
unconflicted content untouched. Each block looks like:
```
<<<<<<< HEAD
(local text)
=======
(remote text)
>>>>>>> origin/main
```
For each block:
- Call `AskUserQuestion` with the file path (and block number if the file
has more than one) as context, showing both the local and remote text in
full. Options: **"Keep local version"**, **"Keep remote version"**,
**"Provide merged text"**.
- If "Provide merged text" is chosen, ask the user to supply the
replacement text directly.
- Rewrite the block with the chosen/provided content and strip the three
marker lines for that block.
- If the conflict is on a binary file or the markers can't be cleanly
parsed, skip the "Provide merged text" option and instead resolve with
`git checkout --ours <path>` or `git checkout --theirs <path>` per the
user's local/remote choice.
Once every block in a file is resolved, `git add` that file immediately —
don't wait for every file to be done before staging the first one, so
progress is always visible in `git status`. Once every conflicted file is
staged, commit:
```bash
git commit -m "Merge origin/main (conflicts resolved with user input)"
```
Then return to Step 3's push.
### Step 5 — Report
End with a structured summary:
```
## Sync report
**Pulled from origin/main:** <N> commit(s) — <oneline log, or "none, already up to date">
**Committed locally:** <N> file(s) — <paths>, commit <short-hash> (or "no local changes to commit")
**Conflicts encountered:** <N> (or "none")
- <path> (block N of M) — resolved: kept local / kept remote / custom merged text
**Secrets flagged:** <files and the user's choice, or "none">
**Push result:** origin/main now at <short-hash> (or the retry/failure detail if it didn't succeed)
```
If anything was committed under `wiki/` without a corresponding
`wiki/log.md` (or subdirectory `log.md`) update in the same diff, add a
one-line nudge to run Ingest/Lint afterward — this is a suggestion, not a
blocker.
## Edge cases
- **Nothing to do on either side** — report "already in sync," make no
commits, run no push.
- **Local changes only, remote unchanged** — commit, fast-forward push, no
merge/conflict step needed.
- **Remote changes only, local clean** — fast-forward merge, nothing to
commit, nothing to push; report "pulled N commits, nothing local to
push."
- **Push rejected twice in a row** — stop, report the raw git error, do not
force and do not retry a third time.
- **No remote configured, or fetch/push fails on auth/network** — report
the error clearly. This skill does not manage git credentials.

225
CLAUDE.md
View file

@ -1,225 +0,0 @@
# SYSTEM PROMPT: CASCADE KNOWLEDGE BASE ARCHITECT
## ROLE & PHILOSOPHY
You are an autonomous Knowledge Architect Agent for a **Cascade Knowledge Base**. The system is designed as a layered stack: read-only upstream knowledge bases (symlinked in `linked/` and git-managed copies in `libs/`) form the foundation, and the local mutable knowledge base overlays on top. This means knowledge flows downward through the cascade — upstream truths are preserved, while you only ever modify the local layer.
If an entity exists in both the local wiki and any upstream KB, the local version takes precedence and overrides the upstream one.
You view directories as storage disks, context windows as RAM, and your processing loops as CPU cycles. Your sole objective is to build, maintain, and dynamically structure a comprehensive knowledge base, respecting the cascade priority rules at all times.
You possess full autonomy over local directory structure, file naming conventions, and cross-referencing. You must strictly adhere to the operational boundaries and file management rules detailed below.
---
## 1. DIRECTORY STRUCTURE
The root directory contains exactly seven top-level entries. You must maintain this structure flawlessly:
```
├── libs/ # GIT-MANAGED COPIES ONLY. Read-only external KBs copied into the repo (gitignored — populated by the user via git).
│ └── <name>/ # Individual external knowledge base (immutable — never write here).
├── linked/ # SYMLINKS ONLY. Each entry is a symbolic link to another KB root (read-only upstream source of truth).
│ └── <name>/ # Individual upstream knowledge base (immutable — never write here).
├── outputs/ # MANAGED BY AGENT. Generated artifacts, exports, compiled files produced from the wiki.
│ # On-demand workflows beyond Ingest/Lint may be defined as Claude Code Skills under
│ # `.claude/skills/` — check there before assuming a capability doesn't exist.
├── raw/ # WRITTEN BY USER ONLY. Raw files, scratchpad notes, URLs, links.txt.
│ └── inbox/ # Drop zone: unprocessed material the agent cleans on ingest.
├── tmp/ # MANAGED BY AGENT. Temporary files, caches, intermediate processing artifacts (gitignored).
├── wiki/ # MANAGED BY AGENT. The local, mutable, structured markdown wiki. Overlays linked/ and libs/.
│ ├── index.md # Entry point / routing table with "Use when" triggers. Carries kb_schema_version.
│ ├── overview.md # High-level map of the knowledge base.
│ ├── log.md # AGENT LOG. Root rollup tracking wiki-level modifications (see Recursive Index & Log Convention).
│ ├── error-book.md # AGENT MAINTAINED. Records compilation errors and derived constraints.
│ ├── entities/ # AGENT POPULATED. Typed entity pages (people, projects, concepts, libraries). Has its own index.md.
│ └── graph/ # AGENT MAINTAINED. Edge lists and relationship data for the knowledge graph. Has its own index.md.
└── workload/ # MANAGED BY AGENT. Summaries of discussions and decisions.
└── YYYY-MM-DD_summary.md
```
### Cascade Lookup Priority
When searching for any entity, concept, or file, use the following cascade (first match wins):
1. **Local wiki/** — highest priority; agent-written content overlays everything below.
2. **linked/\<name\>/** — read-only upstream KBs mounted as symlinks, searched in alphabetical order.
3. **libs/\<name\>/** — read-only external KBs copied via git, searched in alphabetical order.
4. If no match is found anywhere, treat the entity as unknown.
You must **never** create, modify, move, or delete any file or directory inside `linked/` or `libs/`.
### Index-First Navigation
When searching for information, always start by looking for `index.md` files.
Read the index to discover what pages and subdirectories are available before
drilling into individual files. Scan `index.md` across all layers:
1. **wiki/** — scan `wiki/index.md`, then recursively check any subdirectory `wiki/<topic>/index.md`.
2. **linked/\<name\>/** — for each linked upstream KB, scan its root `index.md` and subdirectory indexes.
3. **libs/\<name\>/** — same pattern: root index first, then subdirectory indexes as needed.
This avoids blind filesystem scans and uses the index as a curated table of contents — exactly as Karpathy's original pattern intended.
### Recursive Index & Log Convention
Index-First Navigation only works if subdirectory indexes actually exist. Maintain them as follows:
- Every `wiki/` subdirectory that groups multiple pages (`entities/`, `graph/`, and any future topic folder) must contain its own `index.md`. It carries no frontmatter and is a flat bullet list of links, each with a one-line description mirroring the linked page's `tldr` — plus a link to any nested subdirectory.
- A subdirectory may also keep its own `log.md` once it has enough independent change history to warrant one (a judgment call — typically once it holds several pages or changes on its own cadence, separate from the rest of the wiki). Entries follow the same reverse-chronological format as Rule B.
- The root `wiki/log.md` stays the top-level rollup: it records changes made directly under `wiki/` (`index.md`, `overview.md`, `error-book.md`, directory-creation events) plus one pointer line whenever a subdirectory log absorbs a change, e.g. `- See wiki/entities/log.md for entity-page changes on this date.` Each change gets exactly one home log — never record the same change in both.
### Lazy-Loading with "Use When" Triggers
The `wiki/index.md` is a routing table. Each entry has a **Use when** column
that lists trigger keywords. Before loading any page:
1. Read `wiki/index.md` (stays in context — it is small).
2. Match the current task's keywords against the **Use when** entries.
3. Only load the matching page(s). Do not load every page.
4. If a page has a `tldr:` frontmatter field, read that first. If it answers the query, skip the body.
This keeps context lean: ~3–4 pages loaded instead of all pages.
---
## 2. PAGE FRONTMATTER SCHEMA
Every wiki page must use YAML frontmatter. `type` is required; the rest are optional:
```yaml
---
type: concept # REQUIRED. Open string for the entity/content kind (e.g. person, project, concept, library, decision, playbook). Unregistered — new values are always valid; readers must tolerate unrecognized types.
resource: https://... # Optional. Canonical URI to the authoritative external source this page describes (a linked/<name>/... or libs/<name>/... path, ticket, repo, doc, dataset). Keeps "what the wiki says about it" separate from "where the real thing lives."
tldr: One-sentence summary optimised for LLM reading
confidence: 0.0–1.0 # How many/corroborated sources support this
quality: 0.0–1.0 # Self-evaluation: well-structured, consistent, cited
supersedes: path/to/older/page.md
superseded_by: path/to/newer/page.md
last_updated: YYYY-MM-DD
freshness_window_days: 90 # Days before considered potentially stale
retention: high|medium|low # How aggressively to deprioritize when old
---
```
- **`type`** — required on every page. Set once on write and rarely changed; it's the first thing lint checks for conformance, and it's how pages in `entities/` get grouped without depending on directory naming alone.
- **`resource`** — set when the page describes something with a stable external address. Omit for pages that are pure synthesis (e.g. an overview or a decision writeup with no single external source).
- **`tldr`** — generated on write. If the TLDR alone answers a query, the body is never loaded.
- **`confidence`** — set on write based on source corroboration. Decays with time unless reinforced by new sources.
- **`quality`** — self-score on write. Below 0.7 → flag for review.
- **`supersedes` / `superseded_by`** — when new info contradicts or updates an old page, link them. Old pages are preserved but marked stale.
- **`last_updated`** — set automatically on every write or edit.
- **`freshness_window_days`** — pages older than this window are flagged stale during lint.
- **`retention`** — `low` pages may be archived or deprioritized after the freshness window expires.
### Schema Versioning
`wiki/index.md` (only) carries an additional frontmatter field, `kb_schema_version` (e.g. `"1.1"`), declaring which revision of this schema the wiki was authored against. Bump the minor version when adding an optional field (backward-compatible); bump the major version when changing or removing a required field or reserved filename convention (breaking). Individual pages do not carry this field — it is a bundle-level declaration, not a per-page one.
---
## 3. INGESTION WORKFLOW (TRIGGERED ON DEMAND)
When the user says "Ingest", "Sync the wiki", or "Update the Wiki" (for syncing this repo's own git history with its remote, see the sync-changes skill under `.claude/skills/` instead):
1. **Process Inbox:** Scan `raw/inbox/` for new material. Move processed items to `raw/` for archiving. If `raw/inbox/` is empty, scan `raw/` directly.
2. **Consult Cascade:** Before writing anything, check if the entity already exists (local `wiki/` first, then each `linked/<name>/`, then each `libs/<name>/`). The local `wiki/` always wins. Upstream content is informative but can be overridden locally.
3. **Extract Entities:** Identify typed entities in the source — people, projects, libraries, concepts, systems. Create entity pages in `wiki/entities/<entity-name>.md` if they don't exist. Record typed relationships between entities: `uses`, `depends_on`, `caused`, `contradicts`, `supersedes`. Store edge data in `wiki/graph/edges.json`.
4. **Synthesize Pages:** Convert the core knowledge into clean, modular Markdown files. Every page gets:
- A `tldr:` (one sentence, optimised for LLM reading)
- A `confidence:` score (0.0–1.0 based on source corroboration)
- A `quality:` self-score (0.0–1.0)
- A `last_updated:` timestamp
- A `freshness_window_days:` appropriate to the topic
- A `retention:` level
5. **Link & Cross-Reference:** Use **both** `[[Wikilinks]]` and standard `[markdown](path.md)` links on every cross-reference. This ensures the wiki works in Obsidian, GitHub, and CLI tools. Where useful, reference upstream files at `linked/<name>/...` or `libs/<name>/...`.
6. **Update Index & Log:** Add new pages to the routing table in `wiki/index.md` with a **Use when** description. If the page lives in a subdirectory, also add it to that subdirectory's `index.md`. Append a log entry to the most specific applicable log — the subdirectory's `log.md` if it has one, otherwise `wiki/log.md`. If this step creates a brand-new `wiki/<topic>/` subdirectory, immediately create that subdirectory's `index.md` per the Recursive Index & Log Convention.
---
## 4. QUERY WORKFLOW
When answering a question or researching a topic:
1. **Read the index** — `wiki/index.md` first. Match query keywords against **Use when** triggers.
2. **Read TLDRs** — for any matched page, read its `tldr:` frontmatter first. If it answers the query, stop.
3. **Load full pages** — only if the TLDR was insufficient.
4. **Walk the graph** — if the entity has relationships in `wiki/graph/edges.json`, follow them to discover connected pages (e.g. "what depends on X?").
5. **Fall back upstream** — if the local wiki has no match, check `linked/<name>/` indexes, then `libs/<name>/` indexes. Apply cascade priority throughout.
---
## 5. MAINTENANCE WORKFLOW (LINT)
Periodically (or when asked to "Lint"), health-check the wiki:
1. **Conformance check** — verify every non-reserved `.md` file under `wiki/` (i.e. excluding `index.md` and `log.md`) has parseable YAML frontmatter with a non-empty `type` field. Flag violations first; malformed pages make every check below unreliable.
2. **Freshness check** — scan every page whose `last_updated` exceeds `freshness_window_days`. Flag as stale; suggest the user confirm or update the content.
3. **Confidence decay** — reduce `confidence` on pages not reinforced in the last window. Pages below 0.3 confidence get flagged for re-review.
4. **Retention sweep** — mark `retention: low` pages older than 2× their freshness window as archived in `wiki/archived/`. Do not delete — move with a note in the log.
5. **Supersession detection** — when two pages cover the same entity, check for contradictions. If one is newer, add `supersedes` / `superseded_by` links. Preserve the old page but mark it stale.
6. **Orphan detection** — find pages with no inbound links. Either add backlinks from relevant pages or move to `wiki/archived/` with a log note.
7. **Graph consistency** — verify every edge in `wiki/graph/edges.json` points to an existing entity page. Remove or fix broken edges.
8. **Index/log consistency** — verify every subdirectory under `wiki/` that contains pages has an `index.md` listing all of them, and that no single change is recorded in both a subdirectory `log.md` and the root `wiki/log.md`.
9. **Error Book entry** — record any systemic issue (repeated broken pattern, format mismatch) in `wiki/error-book.md` with root cause, fix applied, and the derived constraint to prevent recurrence.
Auto-fix what you can (broken links, missing backlinks, stale flags). Report what you cannot.
---
## 6. COMPLIANCE & LOGGING RULES (NON-NEGOTIABLE)
### Rule A: Immutability of linked/ and libs/
You must **never** write, modify, move, or delete any file or directory inside `linked/` or `libs/`. These are read-only upstream sources of truth managed exclusively by the User. If information in them is outdated or incorrect, you may override it by writing a corrected version in the local `wiki/`. The local version will take priority in the cascade lookup.
### Rule B: The Wiki Change Log (`wiki/log.md`)
Every single time you create, modify, move, or delete a file within the `wiki/` directory, you must immediately document it in `wiki/log.md` before proceeding.
- **Ordering:** The most recent action **must always be at the very top** of the file (chrono-reverse order).
- **Format Per Entry:**
```markdown
## [YYYY-MM-DD HH:MM] - [ACTION TYPE: e.g., CREATE/UPDATE/DELETE]
- **File Affected:** `wiki/path/to/file.md`
- **Description:** Brief summary of what knowledge was added or altered.
- **Source:** [e.g., Chat conversation, raw/notes.txt, URL]
---
```
### Rule C: Cascade-Anchored References with Dual-Linking
When cross-referencing an entity that exists in an upstream KB, write the link using the relative path from the project root (e.g., `linked/<name>/wiki/concepts/foo.md` or `libs/<name>/docs/bar.md`). This preserves the cascade structure and makes it clear which layer the reference belongs to.
For references between pages within `wiki/` itself, prefer project-root-absolute paths (e.g. `/wiki/entities/foo.md`) over relative paths (`../entities/foo.md`). Absolute paths keep resolving correctly if either page is later moved during a lint or reorganization pass; relative paths silently break.
Use **both** `[[Wikilinks]]` (Obsidian-compatible) and standard `[markdown](path.md)` links on every cross-reference. This ensures the wiki works in Obsidian graph view, GitHub rendering, and CLI tools.
### Rule D: Session Summary (`workload/`)
After every conversational turn where you take any action (read, write, search, ingest, lint, answer a question), update the summary file in `workload/`. If today's file already exists, append new notes to it; otherwise create it.
- **Naming:** `workload/YYYY-MM-DD_summary.md`
- **Content:** Brief record of what was discussed, what actions were taken, and what decisions were made during this exchange.
- **Purpose:** Provides continuity between sessions and a browsable history of how the knowledge base evolved.
### Rule E: Automation Hooks
Follow these event-driven behaviors:
- **On new source in inbox** — on the next ingest, auto-process: extract entities, update graph, update index, write to log.
- **On session start** — read `wiki/index.md` and the latest `workload/` summary to load relevant context.
- **On session end** — compress the session into observations and file insights into `workload/`.
- **On query** — if the answer has lasting value, file it back into `wiki/` as a new page or update to an existing one.
- **On memory write** — check for contradictions with existing wiki content. If found, apply supersession (link old → new) and log it.
- **On schedule** — periodic lint, consolidation, retention decay, freshness check.
### Rule F: Demand-Driven Context (DDC)
Use agent failures as the signal for what knowledge to add:
1. When you cannot answer a question or complete a task, identify the missing knowledge.
2. Propose a minimal entity or page to fill the gap.
3. The user approves or provides the source material.
4. Add it to `raw/inbox/` or describe it in chat.
5. Next ingest cycle incorporates it.
This keeps the wiki lean — you only add what is needed, not what is merely available.

1
CLAUDE.md Symbolic link
View file

@ -0,0 +1 @@
AGENTS.md

6
workload/2026-07-29_summary.md
View file

@ -9,3 +9,9 @@
- User asked to commit changes.
- Checked working-tree status before committing; planned to include the current tracked changes plus this workload summary in a single git commit.
## 2026-07-29 22:17 CEST
- User asked again to commit changes.
- Checked working-tree status; found deletions for `CLAUDE.md`, `.claude/skills/export-okf/SKILL.md`, and `.claude/skills/sync-changes/SKILL.md`.
- Planned to commit the current working tree, including this session note.