Skip to main content
skill CX Codex

project-wiki — Claude Code skill: what it does, how to install

Builds and maintains an in-repo Karpathy-style wiki where the AI updates interconnected notes and you review decisions and concepts.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add robertguss/claude-code-toolkit --skill project-wiki -a claude-code
Open on GitHub

What project-wiki does

This skill implements a repository wiki following Andrej Karpathy's architecture. Content lives in three layers: raw files in raw/, agent-edited markdown documents, and SCHEMA.md defining conventions. You choose between two initial setups: a project record for engineering tasks or a research vault for study. The agent handles editing.

Every working session starts by reading SCHEMA.md and index.md. Ingestion computes sha256 checksums on incoming source files to detect drift. Pages require at least two [[wikilinks]], while factual clashes get marked with contested: true. Work is saved via checkpoints. Without Python 3 available, running tools/lint.py fails and prevents proper validation. The wiki can deploy to GitHub Pages through Quartz on branch pushes.

What it helps with

  • Track project decisions, sessions, and roadmap progress directly in markdown
  • Archive external reference documents in raw/ with immutable sha256 checksums
  • Organize topic research into interconnected pages using bidirectional [[wikilinks]]
  • Validate wiki links, orphan pages, and frontmatter constraints with a dedicated linter

Example prompts for the agent

  • Ingest the meeting summary from raw/notes/kickoff.md, link relevant entity pages, and record changes in log.md
  • Run a session checkpoint: update the active plan status, refresh the synthesis note, and execute tools/lint.py
  • Scan index.md for contested topics and summarize all contradictory claims marked in the wiki

How to install project-wiki

1Skills CLI (Vercel)

npx skills add robertguss/claude-code-toolkit --skill project-wiki -a claude-code

2Manually: put the files in place

~/.claude/skills/project-wiki/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/project-wiki/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about project-wiki

How to install project-wiki in Claude Code?

Run npx skills add robertguss/claude-code-toolkit --skill project-wiki -a claude-code. You can also configure it directly by placing the skill at ~/.claude/skills/project-wiki/SKILL.md.

What is the difference between project record and research vault?

The project record preset tracks active repository progress with roadmaps, session logs, and architectural decisions. The research vault focuses on studying domains, organizing raw sources, concepts, entities, and filed queries.

What prerequisites are needed for linting the wiki?

The linter requires Python 3 to run python3 <wiki>/tools/lint.py. It checks for broken wikilinks, orphan notes, schema violations, unregistered tags, and pages over 200 lines.

Source text

SKILL.md · MIT
---
name: project-wiki
description:
  Build and keep a Karpathy-style LLM wiki inside a repo, as a project record or
  a research vault, with a schema, an index, a log, a lint, and a Quartz site on
  GitHub Pages.
disable-model-invocation: true
---

# Project wiki

A wiki is a persistent, compounding record: interlinked markdown pages the agent
writes and maintains and the human reads. Knowledge is compiled once and kept
current, so every page already carries its cross-references, its contradictions,
and its place in the whole. The pattern is Karpathy's
([`references/karpathy-llm-wiki.md`](references/karpathy-llm-wiki.md)); this
skill is its shape for a repo.

Three layers, all inside the repo:

- **Raw sources** (`raw/`): immutable. Read, never edited. Corrections go on
  wiki pages.
- **The wiki**: the pages. Written by the agent only. In a project run by the
  `lead` skill, the lead writes them and the worker never does.
- **The schema** (`SCHEMA.md`): the page types, frontmatter, tag taxonomy, and
  conventions. The agent and the human co-evolve it; a convention changes there
  first, then on the pages.

Two presets, chosen at init: **project record** (plans, sessions, decisions, a
roadmap board, a standing synthesis, maps) for a repo being built, and
**research vault** (sources, entities, concepts, comparisons, filed queries) for
a topic being studied. Both share the operations below.

## Start of session

Read, in order: `SCHEMA.md` whole, `index.md`, the last 20 entries of `log.md`
(`grep "^## \[" log.md | tail -20` finds them). In a project record, also the
synthesis page and the roadmap board. Only then touch a page.

No `SCHEMA.md` in the repo means the wiki does not exist yet: follow
[`references/init.md`](references/init.md).

## Operations

### Ingest

A source arrives (a URL, a file, a pasted transcript, a worker's report).

1. Save it under `raw/<kind>/` with frontmatter (`source_url`, `ingested`, and
   `sha256` of the body), named by what it is and when.
2. Find what already exists: search `index.md` and the pages for every entity,
   concept, or step the source names. This is the difference between a wiki and
   a pile of duplicates.
3. Write or update pages by the schema's thresholds: a page when a thing appears
   in two sources or is central to one, an update when it is already covered,
   nothing for a passing mention. Every page carries frontmatter from the
   schema, two or more outbound `[[wikilinks]]`, and a `## Related` list. New
   information that contradicts a page keeps both claims with dates, marks
   `contested: true` and `contradictions:` on both, and names the pair for the
   human.
4. Update `index.md` for new pages and append one `log.md` entry naming every
   file touched.

Done when every page the source bears on has been read and either updated or
left with a reason.

### Query

A question about the domain.

1. Read `index.md` to pick the pages; past a hundred pages, search the text too.
2. Read them, answer, and cite the pages.
3. File an answer worth keeping (a comparison, a synthesis, a connection) as a
   page of the schema's type for it; leave a lookup unfiled.
4. Append a `log.md` entry either way.

### Checkpoint

The project-record preset's unit of work, run at every acceptance, every pause,
and every closed topic.

1. Edit the pages the event touches: the plan's status and Result, the decision
   rows, the session page, the changelog, the roadmap board.
2. Bump `updated:` on each, add new pages to `index.md`, append one `log.md`
   entry.
3. At a pause, rewrite the synthesis page whole and the maps a landed page
   belongs on.
4. Run the lint and commit by path (`git commit -m <msg> -- <paths>`).

Done when the lint reports no broken links, no missing index entries, and no
frontmatter faults, and the log's last entry is this checkpoint.

### Lint

`python3 <wiki>/tools/lint.py` from the repo root: broken wikilinks, orphans,
index completeness, required frontmatter, tags outside the taxonomy, raw drift,
contested or low-confidence pages, pages over 200 lines, log size. Run it at
every checkpoint and at the end of every session, and record the count in
`log.md`. Issues the human owns stay listed and are named as theirs.

## Publishing

The wiki reads as a site with Quartz and GitHub Pages, built on every push to
the default branch. Setup is one branch of init:
[`references/publish.md`](references/publish.md).

## Conventions that hold in every preset

- File names lowercase with hyphens; a numbered page keeps its number forever.
- `created:` never changes; `updated:` is bumped on every edit.
- `raw/` is immutable; the `sha256` in its frontmatter is how drift shows.
- `index.md` lists every page with one line; `log.md` is append-only with the
  prefix `## [YYYY-MM-DD] action | subject`.
- Tags come from the taxonomy in `SCHEMA.md`; add the tag there first.
- Who said what stays visible: the human's words are quoted as theirs, the
  agent's recommendations are marked as recommendations.
- Prose the human reads comfortably: short paragraphs, narrow tables, snippets
  under 20 lines.

© robertguss · MIT · robertguss/claude-code-toolkit

Similar skills

All skills for Writing and docs →

From the same set18

book-ideation Develop a nonfiction book idea into a structured concept, clarifying its reader, central claim, and promise. Use it before validating the idea or planning the book. CX Codex +1 ★ 132repo stars book-idea-validator Stress-tests a nonfiction book concept against existing research. Tells you whether the thesis holds up before you write. CX Codex +1 ★ 132repo stars ebook-discovery Find ebook concepts in published work, personal expertise, audience questions, and archives. The skill assesses ideas and tracks candidates for further development. CX Codex +1 ★ 132repo stars ebook-concept-development Turns a single ebook idea into a structured concept: reader, transformation, promise, scope. Useful before you start planning the book itself. CX Codex +1 ★ 132repo stars lead A skill to organize project work through a task queue. You write briefs, send each to a fresh Opus agent in Herdr, verify the outcome, and keep a record—the loop runs without stopping. CX Codex +1 ★ 132repo stars handoff Writes a structured session document so the next agent session can resume your task without a long re-explanation. CX Codex +1 ★ 132repo stars brainstorm Guides multi-session ideation and logs decisions across versioned Markdown files. Suitable for vetting product ideas, strategies, and content plans over days or weeks. CX Codex +1 ★ 132repo stars app-store-opportunity-research Researches iOS app niches, competitors, demand signals, and revenue clues, then produces ranked opportunities and an MVP PRD. Useful before you build. CX Codex +1 ★ 132repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor