@ericrisco/rsc 0.1.34 → 0.1.35

package/README.md

@@ -256,6 +256,26 @@ The front door and the workspace brain.
 > self-improving wiki. It governs software *or* a whole company. **orient** is the
 > always-on compass that keeps a non-technical human oriented after every step.
 
+> #### 📦 The `02-DOCS/` brain is now 100% Open Knowledge Format (OKF v0.1) conformant
+>
+> Google Cloud published the [**Open Knowledge Format**](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf)
+> — a vendor-neutral standard for portable, agent-readable knowledge — built on the
+> same Karpathy *LLM-wiki* pattern our `02-DOCS/` engine has used from day one. We
+> independently converged on the same design, so adopting the standard cost almost
+> nothing. As of now, **every `02-DOCS/wiki/` is a valid, portable OKF bundle**:
+>
+> - **Markdown + YAML frontmatter**, `type` on every concept doc, OKF-standard
+>   fields (`title`, `description`, `resource`, `tags`, `timestamp`).
+> - **Standard markdown links** (not wikilinks) form the knowledge graph — any OKF
+>   consumer reads it, *and* it stays a native Obsidian vault (graph, backlinks,
+>   Properties, Bases). Same files, no export step.
+> - **Reserved files** honored: `index.md` (no frontmatter) for navigation,
+>   `log.md` (newest-first, ISO 8601) for history.
+>
+> Tarball a `wiki/` and any OKF tool — including Google's own viewer — can read it.
+> And the brain now **keeps your repo clean**: a loose file it ingests (a PDF at the
+> root, anything in `inbox/`) is *moved* into `raw/`, never left as clutter.
+
 ### 📐 Spec-Driven Development
 Take a fuzzy intent to a shipped, verified change — phase by phase. `npx @ericrisco/rsc install --profile core`.
 

package/manifest.json

@@ -1,5 +1,5 @@
 {
-  "version": "0.1.34",
+  "version": "0.1.35",
   "counts": {
     "skills": 232
   },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ericrisco/rsc",
-  "version": "0.1.34",
+  "version": "0.1.35",
   "description": "Eric Risco's agent-skills catalog as a granular, self-recommending CLI installer.",
   "type": "module",
   "bin": {

package/skills/agent-eval/SKILL.md

@@ -199,7 +199,7 @@ Pick by where the eval runs and what it must do. Versions as of 2026-06 — re-v
 
 ## Project grounding
 
-If the workspace has a `02-DOCS/` harness, record the eval policy in `02-DOCS/wiki/stack/evals.md`: dataset location, scorer mix, gate baseline file, judge model, and the failure modes covered. Index it in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer). This is **recorded, not gated** — skip silently if there is no harness.
+If the workspace has a `02-DOCS/` harness, record the eval policy in `02-DOCS/wiki/stack/evals.md`: dataset location, scorer mix, gate baseline file, judge model, and the failure modes covered. Write it as an OKF v0.1 wiki article per the harness [`wiki-article-template.md`](../harness/references/wiki-article-template.md): open with YAML frontmatter carrying a non-empty `type:` (use `type: stack`), `timestamp` in ISO 8601, and standard markdown links — never wikilinks. Index it in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer). This is **recorded, not gated** — skip silently if there is no harness.
 
 ## verify.sh
 

package/skills/analyze/SKILL.md

@@ -112,7 +112,7 @@ Produce a single consistency report:
 3. **Findings table** — `# | Severity | Type | Artifact A (loc) | Artifact B (loc) | Conflict | Resolve in (phase)`.
 4. **Recommended routing** — group fixes by the phase that owns them (`clarify` for spec ambiguity, `plan` for missing architecture, `tasks` for a missing done-check, `constitution` if a principle itself is wrong).
 
-Write the report to `02-DOCS/wiki/sdd/analysis/<slug>.md` (create the dir if absent) and index it in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer) under the `sdd/` topic, so the next phase and the harness can find it. The report is the artifact analyze owns — it is the *only* thing analyze writes. Per-run point-in-time; overwrite on re-run, the wiki keeps history.
+Write the report to `02-DOCS/wiki/sdd/analysis/<slug>.md` (create the dir if absent) and index it in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer) under the `sdd/` topic, so the next phase and the harness can find it. It is an OKF v0.1 wiki article: open it with YAML frontmatter carrying a non-empty `type:` (use `type: analysis`), a `timestamp` in ISO 8601, and standard markdown links — never wikilinks. The report is the artifact analyze owns — it is the *only* thing analyze writes. Per-run point-in-time; overwrite on re-run, the wiki keeps history.
 
 Adapt the rendered verbosity to the dial (L0 = table only; L3 = full walk-through). Do not log a decision to `decisions.md` — analyze decides nothing; the phase that resolves the finding logs its own decision.
 

package/skills/brand-voice/SKILL.md

@@ -150,7 +150,7 @@ Tone by context: onboarding=warm; error=plain+reassuring, no humor;
   success=light warmth, no hype; billing=precise+calm; legal=formal+exact.
 ```
 
-**Persist it.** Write the compiled guide under `02-DOCS/wiki/brand/voice-guide.md` and the voice-DNA block beside it, per the `harness` Karpathy-wiki convention (compiled brand articles under `02-DOCS/wiki/brand/`, raw user inputs under `02-DOCS/raw/brand/`). This is the exact study `marketing`, `landing-copy`, and `content-engine` read to ground their copy. A guide in a slide deck is invisible to them.
+**Persist it.** Write the compiled guide under `02-DOCS/wiki/brand/voice-guide.md` and the voice-DNA block beside it, per the `harness` Karpathy-wiki convention (compiled brand articles under `02-DOCS/wiki/brand/`, raw user inputs under `02-DOCS/raw/brand/`). The persisted file is an OKF v0.1 wiki article: open it with YAML frontmatter carrying a non-empty `type:` (use `type: brand-voice`) — see the frontmatter block in [`references/voice-guide-template.md`](references/voice-guide-template.md). This is the exact study `marketing`, `landing-copy`, and `content-engine` read to ground their copy. A guide in a slide deck is invisible to them.
 
 ## Auditing for drift
 

package/skills/brand-voice/references/voice-guide-template.md

@@ -2,6 +2,20 @@
 
 Fill every slot. Delete the instruction lines in italics before you ship. The finished file lives at `02-DOCS/wiki/brand/voice-guide.md`. A fully worked mini-example follows the blank template — copy its shape, not its content.
 
+The persisted guide is an OKF v0.1 wiki article: it MUST open with YAML frontmatter carrying a non-empty `type`. Copy the block below verbatim to the top of `02-DOCS/wiki/brand/voice-guide.md`, fill the values, and set `timestamp` to the ISO 8601 datetime of the edit:
+
+```yaml
+---
+type: brand-voice
+title: <brand> — Voice & Tone Guide
+description: How the <brand> brand sounds — traits, rules, dimensions, word bank, and AI voice-DNA.
+tags: [brand-voice, tone-of-voice, voice-guide]
+timestamp: YYYY-MM-DDTHH:MM:SSZ
+topic: brand
+status: stable
+---
+```
+
 ---
 
 ## Blank template

package/skills/building-agents/SKILL.md

@@ -454,9 +454,9 @@ agent inherits the conventions instead of re-deriving them.
 
 1. **Find the article** `02-DOCS/wiki/stack/agents.md`, indexed in `02-DOCS/wiki/index.md` (the Knowledge map index; root `CLAUDE.md` points to it).
 2. **If missing or stale**, create/update it with the project's real choices — the provider(s) and model routing, where the provider adapter lives, tool/RAG conventions, the eval gates, and the observability backend —
-   then index it in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer to it).
+   then index it in `02-DOCS/wiki/index.md` (the Knowledge map; root `CLAUDE.md` keeps only a short pointer to it). Write it as an OKF v0.1 wiki article per the harness [`wiki-article-template.md`](../harness/references/wiki-article-template.md): open with YAML frontmatter carrying a non-empty `type:` (use `type: stack`), and use standard markdown links — never wikilinks.
 3. **Read it first on every use** and stay consistent; when a convention changes, update the
-   article (bump its `Updated` date) in the same change.
+   article (bump its `timestamp`) in the same change.
 
 No `02-DOCS/` layer? Skip silently (optionally suggest `harness`). Unlike the
 brand study, technical conventions are *recorded, not gated* — never block the task on this.

package/skills/competitor-watch/SKILL.md

@@ -122,10 +122,15 @@ Good: 2026-05-20 · pricing · Acme · acme.com/pricing
 ## The tracker artifacts
 
 Three structured files. Required fields named here; full schema + a filled end-to-end example
-competitor live in `references/tracker-schema.md`.
-
-- **Competitor profile** (one per rival): `name`, `positioning_line`, `segment`, pricing tiers
-  (each with `amount`, `currency`, `source_url`, `date`), feature-matrix rows, watched URLs.
+competitor live in `references/tracker-schema.md`. The profile is a `.md` page under the
+`02-DOCS/wiki/` OKF v0.1 bundle, so its YAML frontmatter carries a non-empty `type: competitor`
+(plus the OKF-recommended `title`/`description`/`tags`/`timestamp`) alongside the domain keys;
+its body uses standard markdown links, never wikilinks. The two CSVs are data files, not OKF
+documents.
+
+- **Competitor profile** (one per rival): OKF frontmatter (`type: competitor`, …) + the domain
+  keys `name`, `positioning_line`, `segment`, pricing tiers (each with `amount`, `currency`,
+  `source_url`, `date`), feature-matrix rows, watched URLs.
 - **Feature matrix** (CSV): rows = features, columns = competitors, each cell sourced + dated.
 - **Change log** (CSV, append-only): `date,competitor,axis,url,old_value,new_value,materiality,action`.
 

package/skills/competitor-watch/references/tracker-schema.md

@@ -5,12 +5,28 @@ captures (the diffed HTML/JSON snapshots) go under `02-DOCS/raw/competitors/<riv
 rule that overrides everything: **a price or feature cell without a `source_url` + `date` is
 not knowledge — leave it blank and say so.**
 
+`02-DOCS/wiki/` is an OKF v0.1 bundle, so the one `.md` file here (the competitor profile)
+carries YAML frontmatter with a non-empty `type:`; the two CSVs are data files, not OKF
+documents. Any cross-references in the profile body use **standard markdown links** (e.g.
+`[Beta](./beta.md)`), never wikilinks. See `../../harness/references/wiki-protocol.md`
+"## Conventions".
+
 ## 1. Competitor profile (one file per rival)
 
 Markdown front-matter + body. One per rival, named `02-DOCS/wiki/competitors/<rival>.md`.
+The frontmatter is OKF v0.1 conformant: `type:` is the only required field (non-empty);
+`title`/`description`/`tags`/`timestamp` are the recommended standard surface. All the
+domain keys below (`name`, `positioning_source.date`, every `pricing_tiers[].date`, …) are
+kept verbatim — OKF allows any extra key and `verify.sh` reads them, so adding the OKF
+fields is purely additive.
 
 ```yaml
 ---
+type: competitor
+title: Acme
+description: "Tracker of record for Acme — positioning, pricing tiers, and watched surfaces."
+tags: [competitor, pricing-watch, feature-watch]
+timestamp: 2026-05-28T00:00:00Z
 name: Acme
 positioning_line: "The all-in-one workspace for remote-first teams"
 positioning_source: { url: "https://acme.com", date: "2026-05-28" }
@@ -28,6 +44,9 @@ pricing_tiers:
 
 ## Notes
 Repositioned from "project tool" to "workspace" in Q2 2026 — see change log 2026-05-12.
+
+## Related
+- [Beta](./beta.md) — closest competing positioning; cross-watch their pricing moves.
 ```
 
 Every `pricing_tiers` row and any feature claim must carry `source_url` + `date`. If you only

package/skills/constitution/references/constitution-template.md

@@ -5,6 +5,16 @@ Render this into `02-DOCS/wiki/sdd/constitution.md`. Keep it to 1-2 screens. Eve
 ---
 
 ```markdown
+---
+type: constitution
+title: <Project> — Constitution
+description: The non-negotiable principles every rsc-sdd phase obeys.
+tags: [sdd, constitution]
+timestamp: YYYY-MM-DDTHH:MM:SSZ
+topic: sdd
+version: v1.0.0
+---
+
 # <Project> — Constitution
 
 > Version: v1.0.0 · Ratified: YYYY-MM-DD · Last amended: YYYY-MM-DD

package/skills/content-engine/SKILL.md

@@ -79,7 +79,7 @@ date,pillar,cluster,format,owner,stage,brief_link,atomization,mix
 
 ## The brief
 
-A slot **cannot leave the `idea` stage without a brief.** One canonical brief format means consistent output regardless of who writes it. Required fields (inline minimum):
+A slot **cannot leave the `idea` stage without a brief.** One canonical brief format means consistent output regardless of who writes it. The brief is a `.md` page in the `02-DOCS/wiki/` OKF v0.1 bundle: its YAML frontmatter carries a non-empty `type: content-brief` (plus the OKF-recommended `title`/`description`/`tags`/`timestamp`) alongside the domain fields below, and any body cross-references use standard markdown links, never wikilinks. Required fields (inline minimum):
 
 - **objective** — the one outcome this piece drives.
 - **persona** — which of the 2–4 you target.

package/skills/content-engine/references/brief-and-pipeline.md

@@ -8,6 +8,13 @@ template, the stage gates, and the CSV column docs you fill in.
 Every slot carries one brief in the same shape. A slot cannot leave the `idea` stage
 without it. Store briefs under `02-DOCS/wiki/content/briefs/<slug>.md`.
 
+These briefs live in the `02-DOCS/wiki/` OKF v0.1 bundle, so each brief `.md` carries YAML
+frontmatter with a non-empty `type: content-brief` (the OKF-recommended `title`/`description`/
+`tags`/`timestamp` are added where meaningful). The domain brief fields below are kept as-is —
+OKF allows any extra key. Cross-references in the body use **standard markdown links**, never
+wikilinks (e.g. `[brand voice](../brand-voice.md)`). See
+`../../harness/references/wiki-protocol.md` "## Conventions".
+
 | Field | Required | What goes here |
 |---|---|---|
 | `objective` | yes | the one outcome (e.g. "drive activation-checklist signups") |
@@ -25,6 +32,13 @@ without it. Store briefs under `02-DOCS/wiki/content/briefs/<slug>.md`.
 
 ```markdown
 ---
+# OKF v0.1 standard surface — `type` is the only REQUIRED field (non-empty).
+type: content-brief
+title: "Onboarding activation guide — brief"
+description: "Brief of record for the flagship activation-checklist guide."
+tags: [content-brief, onboarding, flagship]
+timestamp: 2026-07-01T00:00:00Z
+# Domain brief fields (OKF allows any extra key; the pipeline + verify read these).
 slug: onboarding-activation-guide
 objective: drive activation-checklist signups from new-trial users
 persona: hands-on-ops-lead
@@ -36,7 +50,7 @@ owner: ana
 target_keyword: "saas user activation checklist"
 success_metric: 100 checklist downloads in 30 days
 atomization_intent: 10 derivatives — 3 LinkedIn, 1 X thread, 2 shorts, 1 newsletter, 3 carousels
-voice_ref: 02-DOCS/wiki/brand-voice.md
+voice_ref: ../brand-voice.md
 ---
 ```
 

package/skills/course-builder/references/grounding-and-scoping.md

@@ -46,6 +46,29 @@ Reuse the learner profile if it exists rather than re-interviewing. When you wri
 matrix, persist them there so `course-storytelling` can pick up the same grounding for the hand-off.
 Note in the file that the profile is shared, so neither skill clobbers the other's section.
 
+Each persisted `02-DOCS/wiki/teaching/*.md` file is an OKF v0.1 wiki article: open it with YAML
+frontmatter carrying a non-empty `type:` (`type: course-outline`), then the H1 and body. Use standard
+markdown links between articles (`[Outcomes](./<course>-outcomes.md)`), never wikilinks. Mirror the
+harness `wiki-article-template.md` shape:
+
+```markdown
+---
+type: course-outline
+title: <Course> — Outcomes
+description: The measurable, ABCD-complete learning outcomes for <course>.
+tags: [course, learning-outcomes]
+timestamp: YYYY-MM-DDTHH:MM:SSZ
+topic: teaching
+status: stable
+---
+
+# <Course> — Outcomes
+
+> Sources: {user interview, YYYY-MM-DD}
+
+...
+```
+
 ## Right-sizing scope by format
 
 The single most common failure is too many outcomes for the time. Honest ceilings:

package/skills/course-storytelling/references/learner-grounding.md

@@ -81,9 +81,19 @@ If the user can't answer a question, that dimension stays incomplete — note th
 
 ### Profile wiki article template
 
-Each `02-DOCS/wiki/teaching/*.md` article follows the harness wiki format:
+Each `02-DOCS/wiki/teaching/*.md` article follows the harness wiki format. It is an OKF v0.1 article: open it with YAML frontmatter carrying a non-empty `type:` (`teaching-profile`), then the H1 and body:
 
 ```markdown
+---
+type: teaching-profile
+title: Teaching — Learner
+description: Who is learning, their level and prior knowledge, their pains and desires, and what they can DO after.
+tags: [teaching, learner, profile]
+timestamp: YYYY-MM-DDTHH:MM:SSZ
+topic: teaching
+status: stable
+---
+
 # Teaching — Learner
 
 > Sources: {user interview, YYYY-MM-DD}
@@ -116,9 +126,19 @@ After this, the learner can: …
 
 ### False-beliefs article specifics
 
-`false-beliefs.md` must type every belief so `brunson-frameworks.md` can match it to a breaking story:
+`false-beliefs.md` must type every belief so `brunson-frameworks.md` can match it to a breaking story (same OKF frontmatter; `type: teaching-profile`):
 
 ```markdown
+---
+type: teaching-profile
+title: Teaching — False Beliefs
+description: The learner's blocking beliefs, typed vehicle / internal / external, each with a breaking story.
+tags: [teaching, false-beliefs, profile]
+timestamp: YYYY-MM-DDTHH:MM:SSZ
+topic: teaching
+status: stable
+---
+
 # Teaching — False Beliefs
 
 > Sources: {user interview, YYYY-MM-DD}

package/skills/decision-records/SKILL.md

@@ -56,9 +56,22 @@ Map every ADR to the **MADR 4.0.0 template** (released 2024-09-17 — the curren
 
 Required spine, in order: **Title → Status → Date → Context and Problem Statement → Decision Drivers → Considered Options → Decision Outcome → Consequences**. The MADR-optional sections (Confirmation, Pros and Cons of the Options, More Information) you add only when they pull weight.
 
-Minimal skeleton — this is enough for most decisions:
+Minimal skeleton — this is enough for most decisions. When the ADR lives in a harness
+workspace (`02-DOCS/wiki/decisions/`), it is part of an OKF v0.1 bundle, so it opens with YAML
+frontmatter carrying a non-empty `type: decision` (plus the OKF-recommended `title`/`tags`/
+`timestamp`). The body keeps the human-readable `- Status:`/`- Date:` lines verbatim — they are
+the decision's domain record and `scripts/verify.sh` reads them, so the frontmatter is purely
+additive. Cross-references use standard markdown links, never wikilinks. (In a plain code repo
+under `docs/adr/`, the frontmatter is optional — OKF conformance only governs the wiki bundle.)
 
 ```markdown
+---
+type: decision
+title: "Choose Postgres over DynamoDB for the primary store"
+tags: [adr, database, billing]
+timestamp: 2026-06-02T00:00:00Z
+---
+
 # 7. Choose Postgres over DynamoDB for the primary store
 
 - Status: accepted

package/skills/decision-records/references/templates.md

@@ -8,6 +8,17 @@ Filenames: `NNNN-title-with-dashes.md` where `NNNN` is a zero-padded sequential
 
 Store under one log only — `docs/adr/` (code repo) or `02-DOCS/wiki/decisions/` (harness workspace). Maintain an index as `docs/adr/README.md` or `0000-index.md`:
 
+When the log lives in `02-DOCS/wiki/decisions/`, each ADR is a document in an OKF v0.1 bundle, so it opens with YAML frontmatter carrying a non-empty `type: decision` (plus the OKF-recommended `title`/`tags`/`timestamp`). The MADR body — `- Status:`, `- Date:`, the sections — is kept exactly as below; the frontmatter is additive and `verify.sh` keeps reading the body lines. The index file (`0000-index.md` / `README.md`) is the OKF reserved directory listing and carries **no frontmatter**. All cross-references are standard markdown links, never wikilinks. In a plain `docs/adr/` code repo the frontmatter is optional — OKF conformance governs only the wiki bundle. The OKF frontmatter block to prepend (shown once; the templates below omit it for brevity):
+
+```yaml
+---
+type: decision
+title: "<short decision title>"
+tags: [adr]
+timestamp: YYYY-MM-DDTHH:MM:SSZ
+---
+```
+
 ```markdown
 # Decision Log
 
@@ -116,7 +127,16 @@ a test, an architecture-fitness check.>
 
 ## Worked example — `0007-choose-postgres.md`
 
+Shown with the OKF frontmatter it carries when stored in `02-DOCS/wiki/decisions/`:
+
 ```markdown
+---
+type: decision
+title: "Choose Postgres over DynamoDB for the primary store"
+tags: [adr, database, billing]
+timestamp: 2026-06-02T00:00:00Z
+---
+
 # 7. Choose Postgres over DynamoDB for the primary store
 
 - Status: accepted

package/skills/design/references/brand-grounding.md

@@ -102,9 +102,19 @@ If the user can't answer a question, that dimension stays incomplete — note th
 
 ### Visual-identity wiki article template
 
-Each `02-DOCS/wiki/brand/*.md` article follows the harness wiki format:
+Each `02-DOCS/wiki/brand/*.md` article follows the harness wiki format. It is an OKF v0.1 article: open it with YAML frontmatter carrying a non-empty `type:` (`brand-study`), then the H1 and body:
 
 ```markdown
+---
+type: brand-study
+title: Brand — Visual Identity
+description: The visual personality — OKLCH color system, type pairing & scale, and radius/shadow/motion personality.
+tags: [brand, visual-identity, design]
+timestamp: YYYY-MM-DDTHH:MM:SSZ
+topic: brand
+status: stable
+---
+
 # Brand — Visual Identity
 
 > Sources: {user interview, YYYY-MM-DD}

package/skills/harness/SKILL.md

@@ -11,7 +11,7 @@ profiles: [minimal, core, full]
 The **harness** is the control plane of a workspace. A workspace need not be code: it can be a company, an ops desk, a legal archive, a personal knowledge vault. Whatever it is, the harness is the durable apparatus that keeps it operable and legible, made of three parts:
 
 - **`01-TOOLS/<PROVIDER>/`** — the operational tooling layer. One folder per external provider, co-locating credentials (`.env`) with the scripts that consume them. Each tool ships a working `test_connection` against the real API.
-- **`02-DOCS/`** — the **Karpathy chaos→knowledge engine**: a domain-agnostic LLM wiki (`inbox/` + `raw/` + `raw/worklog/` + `wiki/` + `wiki/index.md` + `wiki/log.md` + `wiki/gaps.md` + `wiki/scores.json` + the `.base` views), fully embedded in this skill. It feeds from **two on-ramps**: (1) the user drops **any raw file in any format** (PDF, image, CSV, JSON, txt, html…) into `inbox/`, and an **Auto-Ingest Sweep** ("the agent goes for a walk") extracts, classifies, cross-links, and compiles it — and goes further, **discovering un-ingested documents anywhere in the workspace** (a stray `/transcripts`, `/facturas`…), bounded by `.rscignore` and de-duplicated by the `wiki/.ingested.json` ledger, fired automatically at SessionStart (when the inbox has material) and by the daily cron. Ingest is non-destructive (originals are copied, never moved); removing an emptied folder needs explicit consent; (2) a **Worklog Sweep** captures **what we do** — every meaningful session of work is itself a `raw` source (`raw/worklog/`) compiled into the wiki, fired by a `PreCompact`/`SessionEnd` hook, by an explicit milestone (a commit), or by the daily curation automation (`references/daily-curation-automation.md`). The wiki is **Obsidian-native**: wikilinks, YAML frontmatter (Properties), readable filenames, and `.base` views give a real graph + live tables — structure, **not vector DB / embeddings / RAG**. The agent writes it; the human reads it in Obsidian. See `references/wiki-protocol.md` for the protocol, `references/ingest-formats.md` for the multiformat Fetch, `references/wiki-worklog-template.md` for the work capture, and `references/obsidian-scaffolding.md` for the vault scaffolding. Topics are inferred from content (`finanzas/`, `legal/`, `crm/`…), never hardcoded. The wiki **self-improves continuously**: every Ingest, Sweep and Query triggers a Maintenance Pass (deterministic lint, score recomputation, gap detection, Related/See-Also sweep), and every N interactions a Micro-Improve runs. Deep Improve runs on explicit request or via the scheduled daily curation. No external skill needed.
+- **`02-DOCS/`** — the **Karpathy chaos→knowledge engine**: a domain-agnostic LLM wiki (`inbox/` + `raw/` + `raw/worklog/` + `wiki/` + `wiki/index.md` + `wiki/log.md` + `wiki/gaps.md` + `wiki/scores.json` + the `.base` views), fully embedded in this skill. It feeds from **two on-ramps**: (1) the user drops **any raw file in any format** (PDF, image, CSV, JSON, txt, html…) into `inbox/`, and an **Auto-Ingest Sweep** ("the agent goes for a walk") extracts, classifies, cross-links, and compiles it — and goes further, **discovering un-ingested documents anywhere in the workspace** (a stray `/transcripts`, `/facturas`…), bounded by `.rscignore` and de-duplicated by the `wiki/.ingested.json` ledger, fired automatically at SessionStart (when the inbox has material) and by the daily cron. Ingest keeps the repo clean: a loose file it ingests at the workspace root (or anything in `inbox/`) is **moved into `raw/`** (relocated, never deleted — a dropped PDF ends up in `raw/`, not at the root), while files inside a user-maintained folder are copied and consolidation is proposed; removing a redundant folder needs explicit consent; (2) a **Worklog Sweep** captures **what we do** — every meaningful session of work is itself a `raw` source (`raw/worklog/`) compiled into the wiki, fired by a `PreCompact`/`SessionEnd` hook, by an explicit milestone (a commit), or by the daily curation automation (`references/daily-curation-automation.md`). The `wiki/` is a **100%-OKF-v0.1 bundle** (Google's [Open Knowledge Format](https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf)) AND an **Obsidian-native** vault at the same time — standard markdown links, OKF-standard YAML frontmatter (Properties), readable filenames, and `.base` views give a real graph + live tables — structure, **not vector DB / embeddings / RAG**. The agent writes it; the human reads it in Obsidian. See `references/wiki-protocol.md` for the protocol, `references/ingest-formats.md` for the multiformat Fetch, `references/wiki-worklog-template.md` for the work capture, and `references/obsidian-scaffolding.md` for the vault scaffolding. Topics are inferred from content (`finanzas/`, `legal/`, `crm/`…), never hardcoded. The wiki **self-improves continuously**: every Ingest, Sweep and Query triggers a Maintenance Pass (deterministic lint, score recomputation, gap detection, Related/See-Also sweep), and every N interactions a Micro-Improve runs. Deep Improve runs on explicit request or via the scheduled daily curation. No external skill needed.
 - **The Knowledge map** — the `## Knowledge map` section of the root `CLAUDE.md` that indexes the wiki (including the `harness/` topic) and is read by every other skill before it works in its area.
 
 `harness` is the **protagonist concept**. `init` is the bootstrap front door — it gauges the user, drafts the profile, and hands off the first scaffold. THIS skill (`harness`) is the **ongoing control**: it audits, migrates, scaffolds, sweeps the inbox, and keeps the wiki, the tooling and the Knowledge map honest over the life of the workspace. It also generates root `CLAUDE.md` and `AGENTS.md`, and migrates legacy `XX-*` numbered folders into the canonical layout.
@@ -105,7 +105,7 @@ harness/
 │   ├── inbox-readme-template.md      ← the inbox/README.md drop-zone contract
 │   ├── wiki-raw-template.md          ← format for raw/<topic>/*.md
 │   ├── wiki-worklog-template.md      ← format for raw/worklog/*.md (work-driven capture)
-│   ├── wiki-article-template.md     ← format for wiki/<topic>/*.md (Obsidian frontmatter + wikilinks)
+│   ├── wiki-article-template.md     ← format for wiki/<topic>/*.md (OKF frontmatter + markdown links)
 │   ├── wiki-index-template.md       ← format for wiki/index.md (machine catalog; .base = human nav)
 │   ├── obsidian-scaffolding.md      ← .base views, .gitignore, attachments, .obsidian config
 │   ├── daily-curation-automation.md ← portable scheduled compounding pass (the third trigger)
@@ -356,7 +356,7 @@ If any of these occur, stop and report:
 - `references/inbox-readme-template.md` — the `inbox/README.md` drop-zone contract shown to the user.
 - `references/wiki-raw-template.md` — format for `02-DOCS/raw/<topic>/*.md`.
 - `references/wiki-worklog-template.md` — format for `02-DOCS/raw/worklog/*.md` (the work-driven capture; the session as a raw source).
-- `references/wiki-article-template.md` — format for `02-DOCS/wiki/<topic>/*.md` (Obsidian frontmatter + wikilinks + `## Related`).
+- `references/wiki-article-template.md` — format for `02-DOCS/wiki/<topic>/*.md` (OKF v0.1 frontmatter + relative markdown links + `## Related`).
 - `references/wiki-index-template.md` — format for `02-DOCS/wiki/index.md` (machine catalog; the `.base` views are the human navigation).
 - `references/obsidian-scaffolding.md` — the vault scaffolding: `.base` views, `.gitignore`, `attachments/`, `.obsidian` config (no vector DB / RAG).
 - `references/daily-curation-automation.md` — portable scheduled compounding pass; on Claude Code wired via the `schedule` skill.

package/skills/harness/references/daily-curation-automation.md

@@ -39,12 +39,14 @@ Run the daily curation pass for this 02-DOCS second brain.
 
 Use the harness wiki-protocol.md as the contract. First run the Auto-Ingest Sweep:
 process inbox/, then scan the workspace (minus .rscignore) for un-ingested documents,
-ingest the clearly-documentary folders (copy originals, never move), record them in
-wiki/.ingested.json, and list ambiguous folders as proposals (do not grab them).
-Then compile pending raw/worklog/ material into wiki/ pages (update existing before
-creating new), keep frontmatter + wikilinks consistent, append significant decisions
-to wiki/harness/decisions.md, refresh the .base-backed navigation, recompute
-scores.json + the score: property, and append a dated entry to wiki/log.md.
+applying Clean-as-you-go (move loose root-level + inbox files into raw/ after a
+verified ingest; copy files nested in user-maintained folders and propose
+consolidation), record them in wiki/.ingested.json, and list ambiguous folders as
+proposals (do not grab them). Then compile pending raw/worklog/ material into wiki/
+pages (update existing before creating new), keep frontmatter + relative markdown
+links OKF-consistent, append significant decisions to wiki/harness/decisions.md,
+refresh the .base-backed navigation, recompute scores.json + the score: property,
+and prepend a dated entry (newest first) to wiki/log.md.
 
 Be conservative. If the topic map no longer fits, record a recommendation in
 wiki/gaps.md or a page's Open Questions instead of moving large parts of the

package/skills/harness/references/obsidian-scaffolding.md

@@ -31,17 +31,24 @@ not bundled with a specific raw source. Link them from the page that depends on
 them. Source-bundled originals stay in `raw/<topic>/_originals/`.
 ```
 
-## `02-DOCS/.obsidian/app.json` (attachment folder)
+## `02-DOCS/.obsidian/app.json` (attachment folder + OKF link mode)
 
 ```json
 {
   "attachmentFolderPath": "attachments",
-  "newLinkFormat": "shortest",
-  "useMarkdownLinks": false
+  "newLinkFormat": "relative",
+  "useMarkdownLinks": true,
+  "alwaysUpdateLinks": true
 }
 ```
 
-`useMarkdownLinks: false` makes new internal links wikilinks. `userIgnoreFilters`
+`useMarkdownLinks: true` makes new internal links **standard markdown links**, not
+wikilinks — this is what keeps `wiki/` a 100%-OKF-conformant bundle (OKF consumers
+follow markdown links; wikilinks `[[...]]` are non-conformant). `newLinkFormat:
+relative` writes paths relative to the current file (`../topic/page.md`), which OKF
+supports and which resolves both in Obsidian and in any OKF consumer.
+`alwaysUpdateLinks: true` makes Obsidian rewrite those relative links automatically
+on rename, so links survive moves the way wikilinks used to. `userIgnoreFilters`
 (Settings → Files & Links → Excluded files) should hide noise from search/graph:
 `raw/_originals/`, `inbox/_processed/`, `audits/`.
 
@@ -59,7 +66,7 @@ filters:
 views:
   - type: table
     name: All Articles
-    order: [file.name, topic, status, score, updated]
+    order: [file.name, topic, status, score, timestamp]
     sort:
       - property: score
         direction: DESC
@@ -74,9 +81,9 @@ filters:
 views:
   - type: table
     name: Worklog
-    order: [file.name, topic, date, status]
+    order: [file.name, topic, timestamp, status]
     sort:
-      - property: date
+      - property: timestamp
         direction: DESC
 ```
 
@@ -89,8 +96,8 @@ filters:
 views:
   - type: table
     name: Decisions
-    order: [file.name, topic, status, updated]
+    order: [file.name, topic, status, timestamp]
     sort:
-      - property: updated
+      - property: timestamp
         direction: DESC
 ```

package/skills/harness/references/wiki-article-template.md

@@ -1,19 +1,23 @@
 ---
+# OKF v0.1 standard surface — `type` is the only REQUIRED field (non-empty).
+type: article
 title: {Title}
-aliases: [{old-slug}]
+description: {One-sentence summary, for previews + search.}
+resource: {URL or path to the underlying source/asset — omit the line if none}
 tags: []
-type: article
+timestamp: {YYYY-MM-DDTHH:MM:SSZ}
+# rsc custom fields (OKF allows any; conformant consumers preserve unknown keys)
+aliases: [{old-slug}]
 topic: {topic}
 status: draft
 sources: []
-updated: {YYYY-MM-DD}
 score: 0.0
 ---
 
 # {Title}
 
 > Sources: {Author1, YYYY-MM-DD; Author2, YYYY-MM-DD}
-> Raw: [[{raw-source-1}]]; [[{raw-source-2}]]
+> Raw: [{raw-source-1}](../../raw/{topic}/{raw-source-1}.md); [{raw-source-2}](../../raw/{topic}/{raw-source-2}.md)
 
 ## Overview
 
@@ -25,19 +29,32 @@ score: 0.0
 
 ## Related
 
-{OPTIONAL — include only when cross-references exist. Maintained during lint. Use wikilinks so the link survives renames and shows in the Obsidian graph + backlinks:
-- Same or different topic: `- [[Other Article]] — why it connects.`
-- With display text: `- [[Other Article|how we say it here]] — why it connects.`}
+{OPTIONAL — include only when cross-references exist. Maintained during lint. Use
+standard markdown links (OKF-conformant — they ARE the knowledge graph; an OKF
+consumer follows them, and the Obsidian graph + backlinks render them too):
+- Same topic: `- [Other Article](./other-article.md) — why it connects.`
+- Different topic: `- [Other Article](../other-topic/other-article.md) — why it connects.`
+- With display text: `- [how we say it here](../other-topic/other-article.md) — why it connects.`}
 
 <!--
-FRONTMATTER CONTRACT (this is what powers Obsidian Properties + Bases + graph):
-- title    human-readable; the H1 matches it.
-- aliases  keep the old kebab slug here so pre-migration links/wikilinks still resolve.
-- tags     cross-cutting qualities ONLY — never the main category (that is `topic`).
-- type     article | decision | worklog | brief | spec | profile
+FRONTMATTER CONTRACT — OKF v0.1 conformant. Powers OKF consumers AND Obsidian
+Properties + Bases + graph (same file, no translation).
+OKF standard surface:
+- type         REQUIRED, non-empty. article | decision | worklog | brief | spec | profile.
+               (OKF type values are not registered centrally; consumers tolerate unknown ones.)
+- title        human-readable; the H1 matches it. Consumers may derive from filename if absent.
+- description  single-sentence summary for previews/search.
+- resource     URI/path to the underlying asset this concept documents (omit if none).
+- tags         cross-cutting qualities ONLY — never the main category (that is `topic`).
+- timestamp    ISO 8601 datetime of the last meaningful edit (e.g. 2026-06-28T14:30:00Z).
+rsc custom fields (allowed by OKF; never required for conformance):
+- aliases  keep the old kebab slug here so pre-migration links still resolve.
 - topic    the wiki/<topic>/ folder, one level. Inferred from content, never hardcoded.
 - status   draft | stable | stale  (lifecycle; filterable in a Base).
-- sources  wikilinks to raw/ pages this was distilled from (cite your evidence).
-- updated  YYYY-MM-DD of the last meaningful edit.
+- sources  markdown links to raw/ pages this was distilled from (cite your evidence).
 - score    mirror of scores.json, written by the Maintenance Pass (single writer → no drift).
+
+LINKS: standard markdown links only — NEVER wikilinks ([[...]]). Relative paths
+(./same-topic.md, ../other-topic/page.md, ../../raw/<topic>/<file>.md). This is
+what keeps wiki/ a portable, 100%-OKF-conformant bundle.
 -->

package/skills/harness/references/wiki-index-template.md

@@ -1,5 +1,9 @@
 # Knowledge Base Index
 
+> **OKF v0.1 reserved file** — `index.md` carries **no frontmatter** (it is a
+> directory listing for progressive disclosure, per the OKF spec). Links are
+> standard markdown, relative to this file (`topic/article.md`), NEVER wikilinks.
+>
 > **Human navigation lives in the `.base` views** (`Articles.base`, `Worklog.base`,
 > `Decisions.base`) — live tables over frontmatter, sorted by score/status/date.
 > This index is the **machine-readable catalog + fallback** the agent maintains;
@@ -11,8 +15,8 @@
 
 | Article | Summary | Updated | Score |
 |---------|---------|---------|-------|
-| [[{Article Title}]] | {One-line summary} | {YYYY-MM-DD} | {N.N} |
-| [[{Archived Article}]] | [Archived] {One-line summary} | {YYYY-MM-DD} | {N.N} |
+| [{Article Title}]({topic-name}/{article-file}.md) | {One-line summary} | {YYYY-MM-DD} | {N.N} |
+| [{Archived Article}]({topic-name}/{archived-file}.html) | [Archived] {One-line summary} | {YYYY-MM-DD} | {N.N} |
 
 ## {another-topic}
 
@@ -20,7 +24,7 @@
 
 | Article | Summary | Updated | Score |
 |---------|---------|---------|-------|
-| [[{Article Title}]] | {One-line summary} | {YYYY-MM-DD} | {N.N} |
+| [{Article Title}]({another-topic}/{article-file}.md) | {One-line summary} | {YYYY-MM-DD} | {N.N} |
 
 > **Score**: composite quality score (inbound links, source count, cited count,
 > freshness; minus conflicts and orphan penalty). Regenerated on every