---
name: wiki-anatomy
description: >-
  The mental model of the Adom Wiki (wiki.adom.inc): it is five familiar tools
  fused into one product keyed off a single slug per page — a git host, the
  adompkg package manager, a release database, a discussion forum, pull requests,
  and discovery — plus a presentation layer. Read this to understand WHAT the wiki
  is before learning HOW to drive it. Trigger words: what is the adom wiki, how
  does the wiki work, wiki architecture, wiki mental model, git plus npm plus
  releases, wiki page is a repo, two storage layers, why both git and registry,
  wiki anatomy, explain the wiki, six tools in one.
---

Parent skill: **adom-wiki-skillpack**

# What the Adom Wiki actually is

The Adom Wiki looks like a wiki, but it is **six tools you already know, fused
into one**, all addressed by a single `slug` per page. Understanding this is the
prerequisite for everything else — most publishing mistakes come from treating
it as one tool when it is really several stacked together.

## The six tools

1. **A git host (per page).** Every page owns a real git repo. The Files tab,
   README rendering, commit log, and contributors all read from it. You push to
   it via `POST /api/v1/pages/:slug/files` — that call *is* a `git commit`.

2. **adompkg — an npm-style package manager.** Alongside the git repo, each page
   can carry a package: versioned tarballs, a `package.json` manifest, a
   `dependencies` map, and dist-tags. `adompkg install <slug>` resolves and
   installs dependencies transitively, just like `npm i`. `adompkg update`
   upgrades everything installed.

3. **A release database.** Like GitHub Releases: a page can attach versioned,
   downloadable assets (per-platform binaries) via `adompkg release upload`. This
   is how closed-source apps ship a compiled binary without shipping source.

4. **A discussion forum.** Each page has discussions + threaded replies, the
   GitHub-Issues equivalent — for questions, bug reports, and feature requests.

5. **Pull requests.** Community members propose edits to a page's repo; the owner
   reviews and merges. The contribution path for a wiki you don't own.

6. **Discovery.** How a page/skill gets FOUND — search, the `/discover` endpoint's
   trigger matching, and local installed-skill matching. A first-class pillar: a
   page that can't be discovered may as well not exist. The **scoring/trending**
   signals (stars, high-fives, installs) feed discovery's ranking. See
   **wiki-discovery** (and **wiki-scoring** for the signals).

## The presentation layer

- **Presentation.** The Overview tab renders either a plain `README.md` or a
  custom `readme.html` for full control. A page whose source is private can also
  carry a **private readme** so the public still sees docs. See **wiki-readme**
  and **wiki-visibility**.

## The one idea that prevents most bugs: two independent storage layers

```
  ┌─────────────────────┐        ┌──────────────────────────┐
  │   GIT REPO           │        │   PACKAGE REGISTRY        │
  │  (browse / read)     │        │  (install / resolve)      │
  │  Files tab, README,  │        │  tarballs, versions,      │
  │  commits, page.json  │        │  dependencies, dist-tags  │
  └─────────────────────┘        └──────────────────────────┘
   written by POST /files          written by `adompkg publish`
```

They are **not** synchronized. `adompkg publish` does **not** push your source to
the git repo, and pushing files does **not** create a tarball. A correct publish
writes **both**. Doing only one leaves the page half-broken (placeholder Files
tab, or a README that won't install). This is the single most common failure —
the **wiki-api** and **wiki-publish-safely** skills exist to make you do both,
in the right order.

Same split as the rest of the world: GitHub (repo) + npm (registry). The wiki
just puts both behind one slug.