Skip to content

Community Packs

How community ADR links work in the Archgate registry, the lower curation bar, importing from external repositories, and the future visual builder.

Beyond the curated catalog, the registry indexes community links — pointers to external repositories that contain archgate-compatible ADRs but are authored and maintained by their own teams, not the Archgate maintainers.

Community links let the ecosystem grow without every pack having to pass maintainer review. They live in community/links.yaml as a machine-readable index, with a human-readable community/README.md alongside it.

Each entry in community/links.yaml is a single record pointing at an external repository:

links:
- title: "My ADR Collection"
url: "https://github.com/user/my-adrs"
tags:
- language:typescript
- concern:testing
description: "Short description of what this collection covers."
submittedBy: your-github-username
submittedAt: "2025-01-15"

The tags follow the same <axis>:<value> convention as curated packs (language:, framework:, runtime:, concern:), so the same filtering applies to both. The index ships with an empty links: [] and grows through community pull requests.

Because import is git-native, community links use the git URL form rather than the packs/... shorthand reserved for the official registry. Anything the system git binary can clone works — including private repositories, which resolve through your existing git authentication (HTTPS tokens, SSH keys, gh auth, or credential helpers).

Terminal window
# Paste a GitHub browser URL straight from the address bar
archgate adr import https://github.com/user/my-adrs/tree/main/packs/frontend
# Or the <org>/<repo>/<path> shorthand for a sub-path
archgate adr import user/my-adrs/packs/frontend
# SSH, self-hosted, or any other git URL
archgate adr import [email protected]:team/adrs.git

A target repository is archgate-compatible when it has either an archgate-pack.yaml at the root or pack directory, or ADR-plus-rule-file pairs that follow the archgate format. Third-party repositories can use any directory layout — the path you pass is literal, so a team organized as teams/frontend/adrs/* or governance/decisions/* works without the packs/ convention.

  1. Fork archgate/awesome-adrs.

  2. Add an entry to community/links.yaml following the schema above. Make sure the target repository is archgate-compatible.

  3. Open a pull request using the community link PR template.

The maintainers verify the repository is real, maintained, archgate-compatible, and not spam. Links that go unreachable are removed after 30 days; you can report a broken link with the repository’s broken-link issue template.

If you want your collection reviewed and hosted inside the registry with a Curated badge instead, follow the creating a pack guide and submit a curated pack instead of a link.

Browsing and composing packs is a web experience, not a terminal one — markdown rendering, syntax-highlighted rule code, search, filtering, and shareable selection URLs are all native on the web and costly in a CLI. That surface is the planned ADR builder.

Browse and filter

A grid of all packs with tags, ADR counts, and descriptions. Filter by language, framework, or concern, and toggle between curated-only and curated-plus-community.

Cherry-pick into a set

Open a pack or ADR, read the rendered document next to its rule code, and add individual decisions to a builder cart with dependency hints.

Copy a command

The builder emits a ready-to-run archgate adr import command with every selected path — curated paths as packs/... shorthand, community entries as full git URLs.

Share a selection

Selections serialize into a shareable URL, so a teammate opens the link and sees the same set pre-loaded.