---
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`.