Skill

Build and Maintain Structured Research Wikis

Create and maintain configurable research wikis - standalone folders with sources, compiled pages, prompts, and provenance logs.

Maintainer of this project? Claim this page to edit the listing.


78
Spark score
out of 100
Updated last month
Version 1.0.0

Add to Favorites

Why it matters

Create, organize, and grow reusable research wikis with configurable structure and flavors that can be queried and maintained over time for knowledge management and research projects.

Outcomes

What it gets done

01

Initialize new wiki structures with custom configurations and flavors

02

Add and organize research content into structured wiki pages

03

Query existing wiki content to retrieve relevant information

04

Maintain and update wiki structure as research evolves

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-wiki-builder | bash

Overview

Wiki Builder

Creates and maintains configurable research wikis - standalone folders with sources, compiled pages, prompts, and a local config that governs structure and style. Use to start a new wiki, ingest sources into an existing one, generate wiki pages, or restructure a wiki's flavor and layout.

What it does

Wiki Builder creates and maintains configurable research wikis, each a standalone folder with its own sources, compiled pages, derived artifacts, prompts, and local configuration. It is intentionally general rather than hard-coded to any one domain like AI papers - each wiki's own wiki.config.md is the source of truth for purpose, audience, page types, style rules, and update workflow, and that local config always beats generic defaults from this skill.

When to use - and when NOT to

Use it to start a new wiki or knowledge base for research notes, papers, products, people, organizations, domains, projects, or events; to ingest source material into an existing wiki; to generate wiki pages, source pages, concept pages, maps, timelines, briefs, or indexes; to query a wiki and file the answer back into it; or to refactor a wiki's structure, requirements, or flavor. When a request names an existing wiki, its wiki.config.md gets inspected before any changes are made, since every wiki can carry different rules.

Inputs and outputs

Wikis live by default under ~/dair-wikis/, overridable via the WIKI_ROOT environment variable or a --root flag, using lowercase kebab-case slugs such as agent-memory or open-source-models. New wikis start from a fixed layout - wiki.config.md, raw/, wiki/index.md, derived/, a prompts/ folder (compile-index, compile-source-page, compile-concept-page, query-and-file, lint-wiki), logs/maintenance-log.md, and sources.md - with folders like wiki/papers, wiki/people, or wiki/timelines added only as the config needs them. A bundled script scaffolds new wikis:

bash "${CLAUDE_PLUGIN_ROOT}/skills/wiki-builder/scripts/init_wiki.sh" <slug> --title "Readable Title" --flavor research

Supported flavors are research, paper, domain, product, person, organization, and project, defaulting to research when unsure. After scaffolding, the workflow is to edit wiki.config.md to match the real goal, drop source material into raw/, record provenance in sources.md, generate pages under wiki/, and log major maintenance actions.

Integrations

Provenance discipline runs throughout: loose claims never become wiki facts without a source, and sources.md entries record at minimum a title, source path or URL, date added, and a short note on what it contributes. Compiled pages are kept distinct from raw source material and favor a concise overview, source-grounded key points, links to related wiki pages, and explicit open questions or uncertainty over rewriting the same summary in multiple places. When many pages change, wiki/index.md, relevant maps, and the maintenance log get updated alongside them, and a references/wiki-flavors.md file gives suggested page types and structures per flavor.

Who it's for

Anyone building and maintaining a long-lived knowledge base - researchers tracking papers and concepts, teams documenting products, people, or organizations - who need source-grounded pages with clear provenance and a structure that stays navigable for future agents and humans, rather than a one-off pile of summaries.

Source README

Wiki Builder

Source: dair-ai/dair-academy-plugins (MIT).

Purpose

Create and maintain configurable research wikis. Each wiki is a standalone folder with its own sources, compiled pages, derived artifacts, prompts, and local configuration.

By default, wikis live under ~/dair-wikis/. Override the location with the WIKI_ROOT environment variable or the --root flag on init_wiki.sh.

This skill is intentionally general. Do not hard-code every wiki into the AI papers structure. Use each wiki's wiki.config.md as the source of truth for purpose, audience, page types, style rules, and update workflow.

When To Use

Use this skill when the user asks to:

  • Start a new wiki or knowledge base.
  • Create a wiki for research notes, papers, products, people, organizations, domains, projects, or events.
  • Ingest source material into an existing wiki.
  • Generate wiki pages, source pages, concept pages, maps, timelines, briefs, or indexes.
  • Query a wiki and file the answer back into the wiki.
  • Refactor or evolve a wiki's structure, requirements, or flavor.
  • Maintain provenance, source notes, and update logs for a wiki.

Default Wiki Location

Store wikis here unless the user explicitly gives a different path:

${WIKI_ROOT:-$HOME/dair-wikis}/<wiki-slug>

Use lowercase kebab-case slugs, for example agent-memory, ai-evals, open-source-models, or company-research.

Core Layout

New wikis should start with this layout:

<wiki-slug>/
├── wiki.config.md
├── raw/
├── wiki/
│   └── index.md
├── derived/
├── prompts/
│   ├── compile-index.md
│   ├── compile-source-page.md
│   ├── compile-concept-page.md
│   ├── query-and-file.md
│   └── lint-wiki.md
├── logs/
│   └── maintenance-log.md
└── sources.md

Add more folders only when the wiki's config needs them. Common additions include wiki/papers, wiki/concepts, wiki/people, wiki/products, wiki/organizations, wiki/timelines, wiki/questions, wiki/maps, and assets.

Starting A Wiki

For new wikis, use the bundled script (resolve its path via the plugin install location, typically ${CLAUDE_PLUGIN_ROOT}/skills/wiki-builder/scripts/init_wiki.sh):

bash "${CLAUDE_PLUGIN_ROOT}/skills/wiki-builder/scripts/init_wiki.sh" <slug> --title "Readable Title" --flavor research

Pass --root /custom/path to put the wiki somewhere other than ~/dair-wikis.

Supported default flavors are research, paper, domain, product, person, organization, and project. Use research when unsure.

After scaffolding:

  1. Edit wiki.config.md to match the user's real goal.
  2. Put copied or downloaded source material in raw/.
  3. Record source provenance in sources.md.
  4. Generate pages under wiki/.
  5. Record major maintenance actions in logs/maintenance-log.md.

Operating Workflow

1. Resolve The Task

Identify whether the user is asking to start, ingest, compile, query, restructure, lint, or export. If the request names an existing wiki, inspect its wiki.config.md before making changes.

2. Use The Local Config

Every wiki can have different rules. Before generating or modifying pages, read:

  • wiki.config.md
  • sources.md when source provenance matters
  • relevant files under prompts/ when the wiki has custom prompts

The local config beats generic defaults in this skill.

3. Preserve Provenance

Do not convert loose claims into wiki facts without a source. When using web pages, papers, transcripts, notes, or repository files, record enough provenance that a future agent can find the original source again.

At minimum, sources.md entries should include title, source path or URL, date added, and a short note about what it contributes.

4. Compile Pages

Prefer durable wiki pages over one-off summaries. Strong pages usually include:

  • a concise overview
  • source-grounded key points
  • links to related wiki pages
  • open questions or uncertainty
  • update notes when relevant

Keep page structure consistent with the wiki's config and flavor.

5. Maintain The Wiki

When adding or changing many pages, update wiki/index.md, relevant maps, and logs/maintenance-log.md. If the user's request changes the wiki's purpose or structure, update wiki.config.md first.

Flavors

Use references/wiki-flavors.md when choosing or adapting wiki types. The reference gives suggested page types and structures for research, paper, domain, product, person, organization, and project wikis.

Quality Bar

  • Make the first page useful immediately.
  • Prefer explicit filenames and stable slugs.
  • Separate raw source material from compiled interpretation.
  • Link related wiki pages.
  • Mark speculation and unknowns clearly.
  • Avoid rewriting the same source summary in many places.
  • Keep generated pages navigable for future agents and humans.

Limitations

  • Requires the upstream tool, account, API key, or local setup when the workflow names one.
  • Does not authorize destructive, production, paid, or external-message actions without explicit user approval.
  • Validate generated artifacts or recommendations against the user's real sources before treating them as final.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.