project-wiki
Skill118 starsChanged 4 months agoMITView on GitHub
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); 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…
3 other projects use a version of this.
Adopted by
Most recently taken up by
- GeminiLight/MindOStheir own version, first seen Oct 8, 2026
- giodra96/project-wikitheir own version, first seen Aug 24, 2026
- yh594774855/skill-collectiontheir own version, first seen Aug 3, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- GeminiLight/MindOS★ 705same name
- giodra96/project-wiki★ 40same name
- yh594774855/skill-collection★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- skill-creatorSkill
- app-store-opportunity-researchSkill
- brainstormSkill
- ebook-concept-developmentSkill
- ebook-discoverySkill
- handoffSkill
- leadSkill
- book-architectSkill
- book-ideationSkill
- book-idea-validatorSkill
- book-market-researchSkill
- book-research-assistantSkill
- chapter-architectSkill
- ghost-writerSkill
- writing-dna-discoverySkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 2 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 36
Read, in order: SCHEMA.md whole, index.md, the last 20 entries of log.md (grep "^## \[" log.md | tail -20 finds them).
- Distinctive: line 54
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 …
- Very specific: line 61
Update index.md for new pages and append one log.md entry naming every file touched.
- Very specific: line 71
Read index.md to pick the pages.
- Distinctive: line 72
Read them, answer, and cite the pages.
- Very specific: line 88
Run the lint and commit by path (git commit -m <msg> -- <paths>).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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); 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
leadskill, 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.
Operations
Ingest
A source arrives (a URL, a file, a pasted transcript, a worker's report).
- Save it under
raw/<kind>/with frontmatter (source_url,ingested, andsha256of the body), named by what it is and when. - Find what already exists: search
index.mdand the pages for every entity, concept, or step the source names. This is the difference between a wiki and a pile of duplicates. - 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## Relatedlist. New information that contradicts a page keeps both claims with dates, markscontested: trueandcontradictions:on both, and names the pair for the human. - Update
index.mdfor new pages and append onelog.mdentry 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.
- Read
index.mdto pick the pages; past a hundred pages, search the text too. - Read them, answer, and cite the pages.
- 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.
- Append a
log.mdentry either way.
Checkpoint
The project-record preset's unit of work, run at every acceptance, every pause, and every closed topic.
- Edit the pages the event touches: the plan's status and Result, the decision rows, the session page, the changelog, the roadmap board.
- Bump
updated:on each, add new pages toindex.md, append onelog.mdentry. - At a pause, rewrite the synthesis page whole and the maps a landed page belongs on.
- 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.
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; thesha256in its frontmatter is how drift shows.index.mdlists every page with one line;log.mdis 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.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

