Adom Wiki Skill Pack
Public Unreviewedby John Lauer
How to use the Adom Wiki without breaking pages — the wiki is six tools in one (git, adompkg, releases, discussions, PRs, discovery), and three repo archetypes have emerged from real use: Page, Skillpack, and Family. Plus how to publish rich component pages (chips, molecules, boards). One install, 15 skills, plus a write-up of the design patterns for the people who build the wiki.
name: wiki-forking description: >- Forking and community contribution on the Adom Wiki — how someone who doesn't own a page proposes changes to it. Pull requests are live (propose edits to a page's repo, the owner reviews and merges); a dedicated fork button is planned. Read this when contributing to a wiki repo you don't own, or planning the community-contribution path for a repo you do. Trigger words: fork a wiki page, fork wiki repo, contribute to a wiki page, propose changes wiki, wiki pull request, wiki PR, community update wiki, submit a change to someone's page, review a wiki PR, accept community changes.
Parent skill: adom-wiki-skillpack
Forking & community contribution
The wiki is a git host, so the goal is a familiar fork → change → propose → review → merge loop for pages you don't own. The pieces are at different maturity, so be precise about what works today.
Status
- Pull requests: live.
GET/POST /api/v1/pages/:slug/prsandPOST /api/v1/prs/:id/merge|closework — you can propose changes to a page's repo and the owner can review and merge. (GET .../prsreturns{"prs":[]}on a page with none.) - Fork (a dedicated fork-your-own-copy button): Planned (spec).
POST /api/v1/pages/:slug/forkreturns 404 today — there is no fork endpoint yet. Don't tell a user they can fork until this lands; use the PR path instead.
Per the standing rule: don't claim a feature works without reading the API response. Re-probe before relying on either path in automation.
The contribution path that works today (PRs)
- Open a PR against the page's repo with your proposed file changes:
POST /api/v1/pages/:slug/prs(see wiki-api for auth + the files/commit model — a PR proposes a commit to the page's git layer). - The owner reviews the PR on the page's PR list (
GET .../prs). - Merge or close:
POST /api/v1/prs/:id/mergeor.../close.
This is the right answer to "I want to improve someone else's wiki page": don't ask for write access, open a PR. It's also how a Family anchor owner accepts improvements to the anchor while third-party children stay independent pages (see wiki-family).
Designing for contribution (if you own the repo)
- Keep the repo clean and the README's "how to contribute" explicit so a PR is low-friction.
- For things that should be separately owned rather than merged into your repo, prefer the Family pattern (a child page + a breadcrumb) over a PR — don't absorb a third party's independently-evolving work into your repo.
When fork lands
When a fork endpoint ships, the flow becomes the standard GitHub one: fork to your
namespace, change freely, open a PR back to the upstream page. Until then, this
skill's PR path is the supported route. Update this status after re-probing
POST /pages/:slug/fork.
---
name: wiki-forking
description: >-
Forking and community contribution on the Adom Wiki — how someone who doesn't
own a page proposes changes to it. Pull requests are live (propose edits to a
page's repo, the owner reviews and merges); a dedicated fork button is planned.
Read this when contributing to a wiki repo you don't own, or planning the
community-contribution path for a repo you do. Trigger words: fork a wiki page,
fork wiki repo, contribute to a wiki page, propose changes wiki, wiki pull
request, wiki PR, community update wiki, submit a change to someone's page,
review a wiki PR, accept community changes.
---
Parent skill: **adom-wiki-skillpack**
# Forking & community contribution
The wiki is a git host, so the goal is a familiar fork → change → propose →
review → merge loop for pages you don't own. The pieces are at different
maturity, so be precise about what works today.
## Status
- **Pull requests: live.** `GET/POST /api/v1/pages/:slug/prs` and
`POST /api/v1/prs/:id/merge|close` work — you can propose changes to a page's
repo and the owner can review and merge. (`GET .../prs` returns `{"prs":[]}` on a
page with none.)
- **Fork (a dedicated fork-your-own-copy button): Planned (spec).**
`POST /api/v1/pages/:slug/fork` returns 404 today — there is no fork endpoint
yet. Don't tell a user they can fork until this lands; use the PR path instead.
Per the standing rule: don't claim a feature works without reading the API
response. Re-probe before relying on either path in automation.
## The contribution path that works today (PRs)
1. **Open a PR against the page's repo** with your proposed file changes:
`POST /api/v1/pages/:slug/prs` (see **wiki-api** for auth + the files/commit
model — a PR proposes a commit to the page's git layer).
2. **The owner reviews** the PR on the page's PR list (`GET .../prs`).
3. **Merge or close**: `POST /api/v1/prs/:id/merge` or `.../close`.
This is the right answer to "I want to improve someone else's wiki page": don't
ask for write access, open a PR. It's also how a **Family** anchor owner accepts
improvements to the anchor while third-party *children* stay independent pages
(see **wiki-family**).
## Designing for contribution (if you own the repo)
- Keep the repo clean and the README's "how to contribute" explicit so a PR is
low-friction.
- For things that should be **separately owned** rather than merged into your
repo, prefer the **Family** pattern (a child page + a breadcrumb) over a PR —
don't absorb a third party's independently-evolving work into your repo.
## When fork lands
When a fork endpoint ships, the flow becomes the standard GitHub one: fork to your
namespace, change freely, open a PR back to the upstream page. Until then, this
skill's PR path is the supported route. Update this status after re-probing
`POST /pages/:slug/fork`.