New wiki thing?
├─ One self-contained app/tool/doc?            → Page  (open or closed source)
├─ A set of skills, one owner, ship together?  → Skillpack  (-skillpack suffix)
└─ A hub with parts that have their own        → Family  (anchor + children
   owners / release cadences?                            + family tag + breadcrumbs)

---
name: wiki-repo-styles
description: >-
  The taxonomy of Adom Wiki repo archetypes that have emerged from real use, and
  how to choose between them BEFORE you publish: Page (open- or closed-source),
  Skillpack (one repo, many bundled sub-skills, suffix -skillpack), and Family (an
  anchor page plus separately-published children). Read this when starting any new
  wiki repo or deciding how to structure related pages. Trigger words: what kind
  of wiki repo, wiki repo archetype, wiki repo style, page vs skillpack vs family,
  parent child wiki, super skill repo, bundle skills or separate, how to structure
  a wiki repo, skillpack vs family, one repo or many, chip-fetcher structure.
---

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

# Wiki repo archetypes — pick one before you publish

Three repo shapes have emerged from heavy real-world use of the Adom Wiki. Naming
them makes the choice deliberate instead of accidental. Decide which one a new
thing is **before** you create the page, because the layout, naming, and publish
flow differ.

## 1. Page — one page = one thing

A single wiki page for a single app, tool, skill, or doc. Two sub-variants by
**source visibility** (see **wiki-visibility**):

- **Open-source Page** — source public + installable. e.g. `chip-fetcher`,
  `adom-usb`. MIT, contributions welcome.
- **Closed-source Page** — source **private**, releases/adompkg **public** →
  install the compiled app, can't read the code. e.g. `hydrogen-desktop`,
  `adom-desktop`. Uses the private readme.

> **Page _type_ vs archetype.** Every page has a `type` (`app` | `skill` |
> `component`) — orthogonal to these archetypes. A **component** (a chip, molecule,
> or board) is normally the Page archetype, and chip families use the Family
> archetype. Publishing a component has its own rich rules → see **wiki-component**.

## 2. Skillpack — one repo, one main skill + N sub-skills

One repo, one installable package, that carries a whole set of skills installed
together by a single `adompkg install`. The sub-skills are files under `skills/`,
**not** separately published pages. Convention: the slug ends in **`-skillpack`**
so the class is recognizable in the grid and in `~/.claude/skills/`.

- Examples: **adom-ui-design** (grandfathered — predates the suffix), and **this
  pack, adom-wiki-skillpack**.
- Build it → **wiki-skillpack**.

## 3. Family — an anchor page + separately-published children

A parent ("anchor") page plus multiple **children published as their own pages**,
joined not by living in one repo but by convention:

- **Slug**: `<parent>-<descriptor>` (e.g. `adom-usb-sniffer-cdc`).
- **Title**: leads with the parent — `Adom USB - CDC serial sniffer` (plain ASCII
  hyphen, never em-dash) — because cards/search/screensaver show the title, and
  nobody reads slugs.
- **Family tag**: `<parent>-plugin` so the anchor's discovery finds children.
- **Breadcrumbs**: third parties attach a link back to the anchor (see
  **wiki-breadcrumbs**).

- Examples: **adom-desktop**, **adom-usb**.
- Build it → **wiki-family**.

## Skillpack vs Family — the decision rule

Both involve "a main thing plus many smaller things." The dividing question is
**ownership and update cadence**:

- **Skillpack** when **one author owns all the parts and they version together.**
  Shipping a new sub-skill means re-publishing the one pack. (The Adom UI design
  guidelines: one author, one coherent release.)
- **Family** when **children have independent owners or change on their own
  cadence.** Each child is its own page with its own version, and third parties
  can publish their own children without touching the anchor.

### Worked example: chip-fetcher

`chip-fetcher` is the instructive edge case. It's open source AND has many
per-vendor scraper skills (DigiKey, Mouser, TI, Analog Devices) that **change
daily** as those sites change, and **third parties** want to own and update the
ones they care about.

- If it were a **Skillpack**, every vendor tweak would force a re-publish of the
  whole pack by its single owner — a bottleneck, and third parties couldn't
  contribute their own scraper without a PR to the core repo.
- So `chip-fetcher` is better as a **Family**: an anchor (`chip-fetcher`) plus
  children like `chip-fetcher-digikey`, `chip-fetcher-mouser`, each separately
  publishable and independently owned, discovered via the `chip-fetcher-plugin`
  family tag and breadcrumbs. The anchor keeps a registry table of known children.

Rule of thumb: **does each part need its own lifecycle and possibly its own
author?** Yes → Family. No → Skillpack.

## Quick chooser

```
New wiki thing?
├─ One self-contained app/tool/doc?            → Page  (open or closed source)
├─ A set of skills, one owner, ship together?  → Skillpack  (-skillpack suffix)
└─ A hub with parts that have their own        → Family  (anchor + children
   owners / release cadences?                            + family tag + breadcrumbs)
```