Best Practices for a GitHub Repository Companion Website for Multi-Agent Memory

Full report

On this page

Executive Summary

The current companion-site implementation has a strong conceptual foundation but a weak publishing architecture. In the repository, sites/multiagentmemory.com/ already contains a purpose-built static companion site with semantic HTML, a stylesheet, llms.txt, ai-manifest.json, robots.txt, sitemap.xml, and .well-known discovery files. However, the live root at multiagentmemory.com currently resolves to a directory index rather than that intended homepage, which is the most urgent issue to fix because it breaks trust, navigation, and SEO before anything else. At the same time, the repository contains a much richer documentation corpus under docs/ than the public companion site exposes, including an API contract, route inventory, deployment guidance, verification guidance, storage/database docs, reports, and long-term architectural notes.

For this project, the best long-term fit is MkDocs with Material for MkDocs, deployed through GitHub Pages using a custom GitHub Actions workflow. That recommendation fits the repo’s current shape: the documentation source is already mostly Markdown, the implementation stack is Python-centric, the current site is static, and the public docs should remain lightweight and fast. MkDocs is designed for Markdown documentation and static output; Material adds strong navigation and built-in search; versioning can be layered on with mike; and GitHub Pages supports custom workflows using the official Pages actions. Sphinx is still valuable for autogenerated Python internals if you later want a deeper code reference, while Docusaurus becomes attractive only if interactive MDX components, live playgrounds, or richer product-style docs become a first-class requirement.

The most impactful structural change is to adopt a simple rule: mirror stable narrative content on the site, link volatile or repository-native artifacts back to GitHub. In practice, the site should mirror overview, getting started, architecture, API overview, examples, security/contact guidance, release notes, contributor guidance, and citation/license guidance. It should link back to raw source trees, issues/PRs, full evidence reports, generated JSON audit artifacts, SQL schemas, and implementation details that are better maintained in the repo as the source of truth. That split reduces drift while still giving the public website enough substance to be useful to humans, search engines, and AI agents.

A practical roadmap is: fix deployment, adopt docs-as-code, expand information architecture, introduce versioned releases, generate API/reference docs, and then harden accessibility, SEO, security automation, analytics, and contributor onboarding. Also important: the current repository already has a CI workflow for application verification, but it does not build or deploy the companion docs, and the latest GitHub Actions signal is blocked by an account billing issue, so CI reliability itself needs remediation. There are also no GitHub Releases yet, despite a CHANGELOG.md and a 0.1.0 entry.

Current State and Inventory

The repo currently presents the companion site as a small static web surface plus machine-readable discovery files. In source, there are two human-facing HTML pages (index.html and docs/memory-boundary.html), one stylesheet, and seven discovery/support files (ai-manifest.json, ai.txt, llms.txt, robots.txt, sitemap.xml, .well-known/ai-agent.json, and .well-known/mcp.json). That is a healthy starting pattern for an AI-facing project, but it is much smaller than the documentation body already present in docs/.

pie title Current companion-site source composition
    "Human HTML pages" : 2
    "Machine-readable discovery files" : 7
    "Stylesheets" : 1

The architectural mismatch is stark: the live site root currently shows a LiteSpeed directory index, while the repository contains an intended homepage with a title, meta description, schema.org WebSite JSON-LD, primary navigation, and a structured hero section. That means your best-practice discussion should start from publishing correctness, not theme selection.

Inventory table mapping current site pages to repo files and gaps

A second important observation is structural: the repo’s docs/ directory is already the real documentation center of gravity. It includes API, route inventory, storage backends, database structure, repository structure, verification, deployment, reports, and long-term-memory notes, but the public companion site currently exposes only one of those concepts directly. That is exactly the kind of gap a repository companion website should close.

Information Architecture and Content Mapping

The right content strategy for this project is selective mirroring. Do not try to copy the whole repo into the website. Instead, treat the website as the curated public handbook and the repository as the operational source of truth. GitHub’s own guidance on READMEs, contributor guidelines, and citation files reinforces this split: public-facing entry points should help people understand what the project is, how to use it, and how to contribute, while repository-native files remain authoritative for source-level operations.

What to mirror and what to link

For Multi-Agent Memory, that means you should mirror the stable narrative from README.md, docs/api-contract.md, docs/route-inventory.md, docs/repository-structure.md, docs/verification.md, docs/deployment.md, CHANGELOG.md, CONTRIBUTING.md, SECURITY.md, LICENSE, NOTICE, and the examples folder. But you should link rather than duplicate large JSON reports, raw SQL schema files, and low-level script output that will change frequently and is easier to preserve in GitHub.

flowchart TD
    Home["Home"] --> GettingStarted["Getting Started"]
    Home --> Architecture["Architecture"]
    Home --> API["API Overview"]
    Home --> Examples["Examples and Demos"]
    Home --> Releases["Releases"]
    Home --> Community["Community"]
    Home --> Security["Security"]
    Home --> Citation["License and Citation"]

    Architecture --> MemoryBoundary["Memory Boundary"]
    Architecture --> RepoStructure["Repository Structure"]
    Architecture --> Verification["Verification and Deployment"]

    API --> Auth["Authentication"]
    API --> Routes["Route Catalog"]
    API --> OpenAPI["Machine-readable API spec"]

    Examples --> PowerShell["PowerShell examples"]
    Examples --> Curl["curl examples"]
    Examples --> Notebooks["Notebooks and widgets"]

    Community --> Contributing["Contributing"]
    Community --> Conduct["Code of Conduct"]

    Releases --> Changelog["Changelog"]
    Releases --> VersionMatrix["Version support matrix"]

A good public navigation for this repo would be:

• Home
• Getting Started
• Architecture
• API
• Examples
• Verification
• Releases
• Community
• Security
• Citation

That structure aligns what users most need to know with what the repository already knows, without exposing every internal artifact as a webpage. It also maps cleanly to your current documentation boundaries: .uai for local startup memory, MemoryEndpoints.com for protected durable memory, and MultiAgentMemory.com for public explanation and discovery.

Docs as Code Stack and Versioning

The repository currently appears to use hand-authored static HTML/CSS for the companion site, not a docs generator. In the observable repo surface, there is no mkdocs.yml, package.json, conf.py, Gemfile, or config.toml, and the current CI workflow verifies the Python app but does not build docs. That is workable for a two-page microsite, but it is not the best long-term approach for the documentation breadth already present in the repo.

Recommended tool choice

For this repo, I recommend the following decision:

• Primary recommendation: MkDocs + Material for MkDocs
• Secondary addition when needed: Sphinx for internal Python API reference generation
• Alternative only if you want richer interactions: Docusaurus
• Not preferred here: Jekyll or Hugo, unless you have a strong GitHub-native or Go-native content workflow preference

The reasons are concrete. MkDocs is built for Markdown docs and static output, and it can deploy to GitHub Pages. Material adds navigation and built-in search, while mike provides versioning. Sphinx is excellent for Python autodoc and autosummary. Docusaurus is powerful for MDX, live code editors, static SEO-friendly output, and built-in versioning, but it brings React/Node complexity that the current repo does not otherwise need. Jekyll is tightly aligned with GitHub Pages and has themes and GitHub Actions support, while Hugo is fast and strong on shortcodes and asset pipelines.

Practical fit table

A useful nuance for this project: your runtime stays intentionally standard-library-only, and requirements.txt says the runtime uses only the Python standard library. A docs toolchain does not violate that principle if it is build-time-only and produces static output deployed separately from the runtime. In other words, static-doc build dependencies are acceptable if the runtime remains clean.

Recommended docs source layout

Use the repo root as the source of truth, but move the public docs into a conventional MkDocs structure:

.
├── docs/
│   ├── index.md
│   ├── getting-started.md
│   ├── architecture/
│   │   ├── index.md
│   │   ├── memory-boundary.md
│   │   ├── repository-structure.md
│   │   └── verification-and-deployment.md
│   ├── api/
│   │   ├── index.md
│   │   ├── authentication.md
│   │   ├── routes.md
│   │   └── openapi.yaml
│   ├── examples/
│   │   ├── index.md
│   │   ├── free-account.md
│   │   ├── memory-submit.md
│   │   └── notebooks/
│   ├── releases/
│   │   ├── index.md
│   │   └── changelog.md
│   ├── community/
│   │   ├── contributing.md
│   │   └── code-of-conduct.md
│   ├── security.md
│   ├── citation.md
│   └── assets/
├── mkdocs.yml
└── scripts/
    └── build_docs_metadata.py

Sample mkdocs.yml

site_name: Multi-Agent Memory
site_url: https://multiagentmemory.com
repo_url: https://github.com/MichaelKappel/Multi-Agent-Memory
repo_name: MichaelKappel/Multi-Agent-Memory
edit_uri: edit/main/docs/

theme:
  name: material
  features:
    - navigation.tabs
    - navigation.sections
    - navigation.footer
    - content.code.copy
    - search.suggest
    - search.highlight

plugins:
  - search

markdown_extensions:
  - admonition
  - attr_list
  - def_list
  - footnotes
  - tables
  - toc:
      permalink: true
  - pymdownx.superfences
  - pymdownx.highlight:
      anchor_linenums: true

nav:
  - Home: index.md
  - Getting Started: getting-started.md
  - Architecture:
      - Overview: architecture/index.md
      - Memory Boundary: architecture/memory-boundary.md
      - Repository Structure: architecture/repository-structure.md
      - Verification and Deployment: architecture/verification-and-deployment.md
  - API:
      - Overview: api/index.md
      - Authentication: api/authentication.md
      - Routes: api/routes.md
  - Examples:
      - Overview: examples/index.md
      - Free Account: examples/free-account.md
      - Memory Submit: examples/memory-submit.md
  - Releases:
      - Overview: releases/index.md
      - Changelog: releases/changelog.md
  - Community:
      - Contributing: community/contributing.md
      - Code of Conduct: community/code-of-conduct.md
  - Security: security.md
  - Citation: citation.md

extra:
  social:
    - icon: fontawesome/brands/github
      link: https://github.com/MichaelKappel/Multi-Agent-Memory

Versioning and release notes

Right now, the repo has a CHANGELOG.md with 0.1.0, but no GitHub Releases page entries. GitHub Releases are based on tags and are the natural public version artifact. For a public-facing companion site, I would use this pattern:

• Tag releases with SemVer-like tags such as v0.1.0
• Publish GitHub Releases with release notes
• Build docs from main for “latest”
• Publish versioned docs from tags using mike
• Surface a simple version support matrix on the site

That gives the site a stable URL structure and lets users distinguish between “current repo head” and “released documentation.”

API reference generation

API reference generation is applicable here. The repo already documents public and protected HTTP routes, auth, idempotency, limits, and route behavior in docs/api-contract.md and docs/route-inventory.md. That is enough to justify introducing a first-class OpenAPI spec for the HTTP surface. For internal Python modules, Sphinx autodoc or Python pydoc can generate code reference from docstrings when the module structure stabilizes.

My recommendation is:

• Public API: maintain docs/api/openapi.yaml, generate human API docs from it
• Internal Python reference: generate only for stable modules such as memoryendpoints.app, security, storage, and site_data
• Do not dump every internal symbol publicly at first; curate the public reference

Examples, notebooks, and interactive widgets

The repo already has public-safe PowerShell examples for free account creation and memory submission, but the companion site does not currently expose them well. Those should become first-class examples pages.

For richer examples:

• If you stay on MkDocs, use mkdocs-jupyter only for a small number of carefully curated notebooks.
• If notebooks become central, consider Jupyter Book / MyST-NB for executable computational narratives.
• If live browser interactivity becomes a major experience goal, Docusaurus’s live code block support is stronger than MkDocs’s default model.

Official docs support these tradeoffs: Jupyter Book supports executable content and cached notebook execution; MyST-NB supports notebooks and text-based notebook formats; mkdocs-jupyter supports .ipynb, Jupytext, and ipywidgets; and Docusaurus supports live code blocks via a dedicated plugin.

Delivery Automation and Governance

The current repository CI workflow runs unit tests, WSGI route verification, secret scanning, package-plan checks, .uai auditing, and an enterprise-readiness audit, but it does not build or deploy the companion website. Also, the repository’s current public CI signal is not trustworthy because the latest observed run was blocked by a GitHub account billing issue before the jobs truly ran. That means the right sequencing is: restore reliable CI first, then add docs build/deploy jobs.

flowchart LR
    PR["Pull request"] --> Checks["Lint, test, docs build, link check"]
    Checks --> Preview["Upload preview artifact"]
    Merge["Merge to main"] --> Release["Optional tag/release step"]
    Merge --> BuildDocs["Build static docs"]
    BuildDocs --> Validate["Validate sitemap, metadata, discovery files"]
    Validate --> Upload["Upload Pages artifact"]
    Upload --> Deploy["Deploy to GitHub Pages"]
    Deploy --> Smoke["Smoke-check public routes"]

GitHub Pages officially supports custom workflows, and the official Pages actions are designed exactly for this pattern: configure Pages metadata, upload a Pages artifact, then deploy that artifact in a dedicated job.

Sample GitHub Actions workflow for docs build and deploy

name: Docs

on:
  push:
    branches: [main]
    tags: ["v*"]
  pull_request:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: docs-pages
  cancel-in-progress: true

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Pages
        uses: actions/configure-pages@v6

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install docs tooling
        run: |
          python -m pip install --upgrade pip
          pip install mkdocs mkdocs-material mike

      - name: Build generated metadata
        run: |
          python scripts/build_docs_metadata.py

      - name: Build docs
        run: |
          mkdocs build --strict

      - name: Upload Pages artifact
        if: github.event_name != 'pull_request'
        uses: actions/upload-pages-artifact@v3
        with:
          path: site

      - name: Upload preview artifact
        if: github.event_name == 'pull_request'
        uses: actions/upload-artifact@v4
        with:
          name: docs-preview
          path: site

  deploy:
    if: github.event_name != 'pull_request'
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build

    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

Recommended automation additions

The app CI is already doing valuable verification, so the right move is not to replace it, but to add a docs lane and a supply-chain lane.

A good minimum set is:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

  - package-ecosystem: "pip"
    directory: "/"
    schedule:
      interval: "weekly"
    allow:
      - dependency-type: "direct"

# dependency-review.yml
name: Dependency Review

on:
  pull_request:
    branches: [main]

permissions:
  contents: read

jobs:
  dependency-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/dependency-review-action@v5

GitHub’s official docs recommend Dependabot version/security updates, dependency review for pull requests, and CodeQL/default code scanning where appropriate. Secret scanning push protection is also relevant for this project because the docs and deployment notes explicitly emphasize keeping credentials out of Git.

Design, SEO, Accessibility, and Operations

The current source-level companion site already has some good fundamentals: semantic HTML (header, nav, main, footer, article, heading hierarchy), a viewport tag, page titles, meta descriptions, and on the homepage a schema.org WebSite JSON-LD block. It also stays lightweight by linking only a single stylesheet and no analytics or client-side framework code. Those are strengths worth preserving.

At the same time, significant gaps remain:

• no Open Graph tags were found on the source pages
• no Twitter/X card metadata was found
• no canonical URLs were found
• the inner page lacks page-level structured data
• the sitemap omits some public discovery assets
• no focus styles were found in CSS
• no responsive media queries or reduced-motion handling were found
• no analytics or error-monitoring scripts were found
• contributor/community surfacing is weak, and no code of conduct was observed

Those are precisely the sorts of issues a mature companion site should close.

Accessibility checklist

WCAG 2.1 remains the applicable baseline you asked for, and W3C’s guidance is the correct reference point. For this site, the main accessibility work is not “framework migration”; it is interaction polish and audit discipline.

A minimal focus/skip-link patch:

<a class="skip-link" href="#main-content">Skip to content</a>

.skip-link {
  position: absolute;
  left: -9999px;
  top: 0;
}

.skip-link:focus {
  left: 16px;
  top: 16px;
  z-index: 1000;
  padding: 8px 12px;
  background: #ffffff;
  border: 2px solid #0b5f59;
}

a:focus-visible,
button:focus-visible {
  outline: 3px solid #0b5f59;
  outline-offset: 2px;
}

SEO and metadata checklist

The current home page includes a title, meta description, and WebSite structured data, which is a good baseline, but best practice for a companion website requires share metadata, canonicalization, and page-level structured data. The Open Graph protocol defines the social-preview model, and Schema.org provides standard structured data types such as WebSite and WebPage.

Suggested metadata partial:

<link rel="canonical" href="https://multiagentmemory.com/docs/memory-boundary/" />

<meta property="og:type" content="article" />
<meta property="og:site_name" content="Multi-Agent Memory" />
<meta property="og:title" content="Memory Boundary" />
<meta property="og:description" content="Short-term, durable, and public-documentation boundaries for the Multi-Agent Memory project." />
<meta property="og:url" content="https://multiagentmemory.com/docs/memory-boundary/" />
<meta property="og:image" content="https://multiagentmemory.com/assets/og/memory-boundary.png" />

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Memory Boundary" />
<meta name="twitter:description" content="Short-term, durable, and public-documentation boundaries for the Multi-Agent Memory project." />
<meta name="twitter:image" content="https://multiagentmemory.com/assets/og/memory-boundary.png" />

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Memory Boundary",
  "url": "https://multiagentmemory.com/docs/memory-boundary/",
  "description": "Short-term, durable, and public-documentation boundaries for the Multi-Agent Memory project."
}
</script>

Performance and Lighthouse

I did not generate a live Lighthouse trace here, so I would not claim measured current scores. What I can say from source inspection is that the current companion site is lightweight by construction: one stylesheet, no JS framework, and no analytics scripts found in the page source. That is an excellent starting point, and you should preserve it even if you adopt MkDocs. Lighthouse’s performance score is driven by metrics such as LCP, CLS, TBT, and FCP, so your optimization priority should stay on small static pages, optimized images, minimal font/network overhead, and caching.

Recommended operational targets:

• keep the site static-first
• ship optimized Open Graph images
• add long-lived caching for immutable assets
• avoid introducing heavy third-party scripts
• test Lighthouse mobile on Home, API, and Examples pages every release

Security, analytics, licensing, citation, and i18n

Because the runtime is deliberately conservative and the docs repeatedly emphasize secret safety, the docs toolchain should be similarly disciplined: Dependabot for docs/build dependencies, dependency review in PRs, secret scanning push protection, and optional CodeQL where appropriate. That becomes even more important once you add MkDocs plugins or notebook tooling.

For analytics, I would choose privacy-preserving instrumentation. Plausible is explicitly positioned as a privacy-friendly lightweight alternative, while Cloudflare Web Analytics provides visitor and performance insights without requiring a heavy custom analytics stack. For front-end error monitoring, Sentry’s browser SDK is the practical default if you later add more JavaScript.

For licensing and citation, the site should plainly explain that the project uses a source-available license, not an OSI-approved open-source license, and it should add a CITATION.cff file so GitHub can expose citation guidance natively. Current repo files already make the source-available and attribution model explicit, and GitHub officially supports CITATION.cff.

Internationalization is not a near-term priority. The current source pages declare lang="en" and are entirely English. Unless you have a real multilingual audience or contributor need, full i18n would add maintenance cost before it adds much value.

Templates and Roadmap

README template

# Multi-Agent Memory

Public, source-available reference implementation and documentation for Multi-Agent Transactive Memory.

## What this project is

Multi-Agent Memory has two public surfaces:

- **MemoryEndpoints.com**: the deployable MATM endpoint and protected API surface
- **MultiAgentMemory.com**: the companion documentation website for architecture, public discovery, examples, and contributor guidance

## Why it exists

This project demonstrates a bounded, inspectable approach to shared memory for AI agents:

- short-term/startup memory stays local in `.uai/`
- durable protected memory lives behind authenticated MATM routes
- public docs and discovery files stay public, human-readable, and AI-readable

## Quick start

python run_dev.py

Open `http://127.0.0.1:8088/`.

## Documentation

- Website: `https://multiagentmemory.com`
- Repository docs: `docs/`
- API contract: `docs/api-contract.md`
- Route inventory: `docs/route-inventory.md`
- Verification: `docs/verification.md`
- Deployment: `docs/deployment.md`

## Examples

- `examples/curl/free-account.ps1`
- `examples/curl/memory-submit.ps1`

## Releases

See `CHANGELOG.md` and the GitHub Releases page.

## Contributing

Please read:

- `CONTRIBUTING.md`
- `SECURITY.md`
- `CODE_OF_CONDUCT.md`

## License

This project uses the **MemoryEndpoints Source-Available License**.
See `LICENSE` and `NOTICE`.

## Citation

If you reference this work in research, an article, a talk, or derivative examples, use the instructions in `CITATION.cff`.

CONTRIBUTING template

# Contributing

Thank you for contributing to Multi-Agent Memory.

## Scope

Contributions are welcome for:

- documentation
- examples and tutorials
- tests
- route behavior verification
- bug fixes
- public-safe API and discovery improvements
- accessibility, SEO, and site quality improvements

## Before you open a pull request

Please make sure your change:

- does not include secrets, credentials, deployment handoff files, logs, or raw private memory payloads
- keeps public claims bounded by verifiable evidence
- updates docs and examples when behavior changes
- preserves attribution and existing license notices
- includes focused tests when applicable

## Local checks

Run the project checks that apply to your change:

python -m unittest discover -s tests python scripts\verify_memoryendpoints.py --wsgi python scripts\secret_scan.py python scripts\package_memoryendpoints.py --check-only python scripts\audit_uai_memory.py python scripts\enterprise_readiness_audit.py --run-checks

If you change docs, also run the docs build locally.

## Docs contribution standards

- write for both humans and AI readers
- keep terminology consistent with the memory boundary model
- prefer stable URLs
- prefer concise examples that are safe to publish
- link to the repo for raw evidence artifacts rather than duplicating them in prose

## Pull request checklist

- [ ] Change is scoped and explained clearly
- [ ] Tests and verification were run where appropriate
- [ ] Docs or examples were updated
- [ ] No secrets or unsafe data were introduced
- [ ] Claims remain evidence-based

## Questions

If the change affects the project boundary, release claims, or security posture, open an issue first so the direction can be agreed before implementation.

CODE_OF_CONDUCT template

# Code of Conduct

## Our commitment

We want Multi-Agent Memory to be a respectful, technically serious, and welcoming project for contributors, users, researchers, and reviewers.

## Expected behavior

Participants in this project are expected to:

- communicate respectfully and constructively
- assume good intent while discussing technical disagreements
- focus criticism on ideas, code, documentation, and process
- respect the safety and privacy boundaries of the project
- avoid overstating claims about certification, authority, or security guarantees

## Unacceptable behavior

The following are not acceptable:

- harassment, intimidation, or discriminatory behavior
- personal attacks, insults, or hostile language
- posting or requesting secrets, credentials, raw private memory payloads, or exploit material with live access
- misrepresenting the project’s license, provenance, or authorship
- making deceptive claims about endorsement, certification, or official status

## Scope

This Code of Conduct applies to repository discussions, issues, pull requests, documentation contributions, and project-linked communication spaces.

## Reporting

If you experience or witness behavior that violates this Code of Conduct, contact the maintainer privately.

Security-sensitive reports should follow `SECURITY.md`.

## Enforcement

Project maintainers may remove content, limit participation, or close discussions that violate this policy in order to protect contributors and the project.

Docs landing page template

# Multi-Agent Memory

Public documentation for the Multi-Agent Memory reference implementation and its companion endpoint system.

## Start here

Multi-Agent Memory separates three concerns:

- **Short-term/startup memory** in the repository `.uai/` files
- **Durable protected memory** in the authenticated MATM endpoint
- **Public documentation and discovery** on this site

## Read by goal

### Understand the architecture
- [Memory boundary](architecture/memory-boundary.md)
- [Repository structure](architecture/repository-structure.md)
- [Verification and deployment](architecture/verification-and-deployment.md)

### Use the project
- [Getting started](getting-started.md)
- [API overview](api/index.md)
- [Examples](examples/index.md)

### Evaluate trust and scope
- [Security](security.md)
- [Releases](releases/index.md)
- [Citation](citation.md)

## Public discovery files

- [`/llms.txt`](/llms.txt)
- [`/ai-manifest.json`](/ai-manifest.json)
- [`/.well-known/ai-agent.json`](/.well-known/ai-agent.json)
- [`/.well-known/mcp.json`](/.well-known/mcp.json)

## Repository

- [GitHub repository](https://github.com/MichaelKappel/Multi-Agent-Memory)

Prioritized maintenance checklist

pie title Recommended effort allocation over the next phase
    "Deployment and CI" : 25
    "Content expansion" : 30
    "SEO and accessibility" : 15
    "Versioning and releases" : 10
    "API and examples" : 10
    "Community and governance" : 10

Final recommendation

If you want the best balance of rigor, low maintenance, and future extensibility, the target state should be:

• Docs source in docs/
• MkDocs + Material for MkDocs
• GitHub Pages custom workflow deployment
• Git tags + GitHub Releases + mike for versioning
• Generated discovery files and sitemap from a shared docs source
• Curated public API docs from OpenAPI
• Sphinx or pydoc only for stable Python internals
• Privacy-preserving analytics later, not first
• Strict mirror-vs-link discipline to prevent drift

That architecture is the cleanest fit for what the repository already is, what the companion site is trying to become, and what official GitHub Pages and docs-tool maintainers support well today.