How to find Amplifier repositories

Amplifier is not "one repo". It's an ecosystem of repositories: a small kernel, apps (like the CLI), libraries (amplifier-foundation), runtime modules, and bundles (which replaced the older collections system).

Canonical index of repos

The intended “table of contents” for the ecosystem is the Component Catalog: microsoft/amplifier/docs/MODULES.md.

GitHub: microsoft/amplifier/docs/MODULES.md
This book’s scanned overview: Ecosystem repo overview

It lists the kernel, apps, libraries, bundles, and runtime modules.
It links directly to the GitHub repo for each component.
This book's catalog updater uses that file as the source-of-truth for which repos to scan.
Note: Collections are listed but deprecated - bundles are the current system.

Dev workspace (submodules)

If you want to contribute across multiple repos at once (core + CLI + modules), it’s common to use a “dev workspace” repo. This is usually a normal git repo whose folders are git submodules pointing at other repos.

What a git submodule means (plain English)

The workspace repo contains pointers to other repos at specific commits.
Each submodule is its own git repo on disk (you can git status inside it).
The workspace can “pin” a compatible set of versions across many repos.

Example: clone a dev workspace

If a repo like amplifier-dev exists and you have access to it, you typically clone it like this:

# Clone the workspace and all submodules
git clone --recursive https://github.com/microsoft/amplifier-dev
cd amplifier-dev

# If you already cloned without --recursive:
git submodule update --init --recursive

How to tell if a repo uses submodules

# Shows submodule paths and pinned commits (if any)
git submodule status --recursive

# Also: look for a .gitmodules file at the repo root
ls -la .gitmodules

What you do with a dev workspace

Common workflows once you have multiple repos checked out locally:

Develop one module locally, while everything else stays on git: point module resolution at your local folder (e.g. via .amplifier/settings.yaml overrides or AMPLIFIER_MODULE_* env vars).
Make coordinated changes (e.g. update a core contract and adjust the CLI/module accordingly).
Debug end-to-end by stepping through app code and module code in the same workspace.

Important

Not every environment uses a dev workspace. If you’re just a user of the CLI, you usually don’t need submodules at all.

How this book stays up to date

This book is designed to be printable/portable: it does not assume it “lives inside” any specific repo. Instead, it keeps a generated catalog file with concrete facts extracted from the ecosystem.

Update the catalog

This command updates the website’s data (the lists and deep-dive pages). It does not update your installed Amplifier CLI modules.

python3 amplifier-book/tools/update_catalog.py

Reads repo links from docs/MODULES.md (component catalog).
Shallow-clones those repos into amplifier-src/ (or $AMPLIFIER_BOOK_SOURCES if set).
Scans repos for bundles, profiles, agents, and module entry points (from code + metadata).
Writes /data/catalog.json (this book's structured dataset).

What is catalog.json?

/data/catalog.json is a generated index that powers the book’s “scanned” lists (modules, hooks, profiles, collections) and deep-dive pages. It exists so the book can be updated by re-scanning GitHub, without manually rewriting pages.

Generated file: /data/catalog.json
Pages that use it: Bundles, Profiles, Profiles deep dive, Modules, Hooks, Collections, Collections deep dive, Repo overview

Reality check

Some community repos may not expose the same entrypoint conventions (or may not publish the relevant metadata). The catalog is best-effort; it also records clone failures so you can see what was missing.

Next: repo overview

See the ecosystem repo overview →