Interactive map of a repository

You read a repository, model it in C4 terms and hand the result to the interactive-map skill, which renders the map. This skill decides what goes on the map; interactive-map decides how to write and render the JSON. Read its SKILL.md before writing the map definition.

The reader is someone who must understand a codebase fast: a lead reviewing a team's project, a new engineer, a lecturer. Every element on the map must be traceable to files in the repository. When you infer something you could not see in the code, say so in the panel text.

1. Find the evidence

Read in this order and stop each step when the answer is clear:

1. README, docs folder, architecture notes.
2. Deployment units: docker-compose*.yml, Dockerfiles, Kubernetes or Helm manifests, Procfile, serverless configs, IaC (Terraform, Pulumi). Each separately deployed or separately running process or data store is a container candidate.
3. Entry points: main functions, server start files, CLI commands, job and worker definitions, cron and schedulers, queue consumers.
4. External contracts: HTTP routes, OpenAPI specs, message topics, environment variables naming other services (*_URL, *_HOST, SMTP, OAuth, cloud SDK clients).
5. Dependency manifests (package.json, pyproject.toml, go.mod, ...) to name the technology of each container.

Write down, with file paths, what you found before designing anything.

2. Build the C4 model