Context7

I’d like to propose that we make this repository’s documentation available in Context7 and keep it automatically refreshed from GitHub Actions.

Why this is useful

Context7 is increasingly used by LLM coding assistants and agentic tooling to fetch current library documentation and examples at inference time. Adding this repo would make it easier for coding tools to retrieve up-to-date MEDS-specific docs, instead of relying on stale training data or incomplete guesses.

For MEDS libraries in particular, this seems valuable because many of the APIs, configs, CLI patterns, and pipeline conventions are specialized enough that generic coding models often hallucinate details.

Proposed scope

I think the right minimal implementation is:

1. Submit the repo to Context7 once

   • Use the repo URL as the source.
   • This is a one-time bootstrap step.

2. Add a GitHub Actions workflow to refresh Context7 on pushes to main

   • Restrict it to documentation-relevant paths so it doesn’t run on every code-only change.
   • Also allow manual triggering via workflow_dispatch.

3. Optionally add a context7.json file

   • This lets us control which folders are indexed and add agent-facing guidance.
   • It is especially helpful if the repo contains a mix of docs, code, tests, benchmarks, or old material.

4. Optionally add /llms.txt

   • This can help make the highest-value docs pages more discoverable to LLM tooling in general.

Proposed implementation

1) Add a GitHub Actions secret

In repository settings, add:

• CONTEXT7_API_KEY

2) Add refresh workflow

Create .github/workflows/context7-refresh.yml:

name: Refresh Context7 Docs

on:
  workflow_dispatch:
  push:
    branches:
      - main
    paths:
      - 'README.md'
      - 'docs/**'
      - 'examples/**'
      - 'llms.txt'
      - 'context7.json'
      - '.github/workflows/context7-refresh.yml'

jobs:
  refresh:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Context7 refresh
        run: |
          curl --fail-with-body --silent --show-error \
            --request POST \
            --url https://context7.com/api/v1/refresh \
            --header "Authorization: Bearer ${{ secrets.CONTEXT7_API_KEY }}" \
            --header "Content-Type: application/json" \
            --data '{"libraryName":"/${{ github.repository }}"}'

3) Optional bootstrap workflow for initial submission

If we want submission itself to be automated rather than done manually in the UI, add .github/workflows/context7-submit.yml:

name: Submit Context7 Library

on:
  workflow_dispatch:
  release:
    types: [published]

jobs:
  submit:
    runs-on: ubuntu-latest
    steps:
      - name: Submit repo to Context7
        run: |
          curl --silent --show-error \
            --request POST \
            --url https://context7.com/api/v2/add/repo/github \
            --header "Authorization: Bearer ${{ secrets.CONTEXT7_API_KEY }}" \
            --header "Content-Type: application/json" \
            --data '{"docsRepoUrl":"https://github.com/${{ github.repository }}"}'

My preference would be:

• either do the initial submission once manually,
• or keep the submit workflow but only run it via workflow_dispatch / releases.

I would not run submission or refresh on every PR by default.

Optional context7.json

If this repo has mixed content, adding a context7.json file at the repo root seems worthwhile.

Example starting point:

{
  "$schema": "https://context7.com/schema/context7.json",
  "projectTitle": "REPO_NAME",
  "description": "Short description of the library.",
  "folders": ["docs", "examples"],
  "excludeFolders": ["tests", "benchmarks", "legacy", "scripts"],
  "excludeFiles": ["CHANGELOG.md"],
  "rules": [
    "Prefer documented public APIs over internal modules.",
    "Prefer current CLI/config patterns shown in the docs.",
    "Do not rely on deprecated configuration names or legacy examples."
  ]
}

Notes:

• If most useful documentation is in the root README.md, that is already fine.
• If useful docs also live outside docs/ or examples/, we should include those folders.
• If this repo has versioned docs, we could later add version tags/branches as well.

Optional llms.txt

If maintainers are open to it, a small /llms.txt could help point LLM tools toward the canonical entry points, such as:

• overview / README
• install / setup
• CLI usage
• configuration reference
• examples / tutorials
• API docs

Why I would avoid PR-triggered refresh by default

Refreshing on every PR seems higher-noise and lower-value than refreshing on merges to main:

• forks and secret handling can get awkward,
• preview branches may not correspond to a stable indexed library,
• the highest-value state for external coding tools is usually the default branch anyway.

If we later want preview indexing for a specific repo, we can add that intentionally.

Acceptance criteria

• The repository is submitted to Context7.
• The repo has a CONTEXT7_API_KEY GitHub Actions secret configured.
• A workflow exists that refreshes Context7 on doc-related pushes to main.
• (Optional) context7.json is added to improve indexing quality.
• (Optional) the library is claimed and maintained by repo owners.

Nice-to-have follow-ups

• claim the library in Context7,
• add a tighter context7.json,
• add /llms.txt,
• add version-specific indexing if this repo has materially different released APIs.

Open questions for maintainers

• Which folders should be indexed for this specific repo?
• Is the root README enough, or do we have more canonical docs elsewhere?
• Do we want only the refresh workflow, or also an automated submit workflow?

If there’s interest, I’m happy to open a small PR with the workflow and a first-pass context7.json tailored to this repo.

Start by inspecting README.md, docs/, examples/, and any existing .github/workflows to identify canonical documentation and workflow conventions. Review the proposed Context7 refresh and submission endpoints, secret usage, and path filters, then resolve which optional files and folders maintainers want indexed. Done means the repository is submitted and a documented workflow refreshes it on documentation pushes to main.