7Mind Brain

repo-onboarding-prompt

5 min read

Summary: The prompt to paste into Claude Code when onboarding a new repository to the wiki. Sources: initial design 2026-05-15, refined after first extraction run on elixir-backend Last updated: 2026-05-15

Repo Onboarding Prompt

Copy everything from the horizontal rule below and paste it as your first message in a Claude Code session opened inside the target repository.

You are about to perform a one-off knowledge extraction for the 7Mind company wiki.

Your task

Explore this repository thoroughly, then populate the relevant pages in the company brain wiki located at: /Users/nikolashaag/Documents/Code/brain/

Step 1 — Orient yourself

Read these two files first:

  • /Users/nikolashaag/Documents/Code/brain/STRUCTURE.md
  • /Users/nikolashaag/Documents/Code/brain/tech/tech-index.md

Also read the existing concept pages so you know what already exists before creating new ones:

ls /Users/nikolashaag/Documents/Code/brain/tech/concepts/
ls /Users/nikolashaag/Documents/Code/brain/tech/integrations/

Read any concept or integration page that looks relevant to this repo.

Then determine the GitHub slug of the current repo (check package.json, mix.exs, pubspec.yaml, git remote, or any other indicator). Find the matching stub file in: /Users/nikolashaag/Documents/Code/brain/tech/repos/

If no stub exists yet, create one using the repo-note template in STRUCTURE.md.

Step 2 — Explore the codebase

Investigate the repo systematically. For each section of the repo note, gather the specific facts needed to fill it in. Focus on:

  • Purpose — What does this repo do? What problem does it solve? Who uses it?
  • Stack — Main language(s), framework(s), key libraries worth knowing
  • Key files — Entry points, core modules, important config files
  • Deployment — How and where does this deploy? Which GitHub Actions workflow? What is the target (Cloud Run, Cloudflare Pages, GKE, etc.)? What branch triggers production?
  • Dependencies — External services called (APIs, SDKs, third-party platforms). Internal: other 7Mind repos or shared packages consumed.
  • Integration — What consumes this repo’s output? Other repos? CDN? Mobile clients?
  • Conventions — Non-obvious patterns: folder layout rules, naming rules, env var conventions, gotchas, anything that would surprise a new engineer.

Look at:

  • README and any docs/ or guides/ folder
  • CI/CD workflow files (.github/workflows/)
  • Dependency manifest (package.json, mix.exs, pubspec.yaml, go.mod, etc.)
  • Entry point files (main.dart, lib/router.ex, nuxt.config.ts, etc.)
  • Environment variable references (.env.example, config files)
  • Deployment config (Dockerfile, cloudbuild.yaml, fly.toml, k8s/, etc.)

Do not read every source file. Read enough to answer the sections above accurately. When something is genuinely unknown from the code, write TBD rather than guessing.

Step 3 — Write the repo note

Update the stub file with everything you found. Preserve the frontmatter schema exactly (type, repo, stack, owner-repo, last-updated, tags, status). Set last-updated to today’s date.

Use [[wiki-links]] wherever you reference another repo, concept, or integration page. Do not use relative paths.

Step 4 — Concept and integration pages

This is the step that builds the graph. After filling in the repo note, do the following:

4a. Identify cross-cutting concerns. List every concern this repo introduces or participates in that is not fully explained by reading any single codebase. Good candidates are:

  • Auth flows that cross repo boundaries
  • External service configurations with non-obvious gotchas (billing providers, analytics, CMS)
  • Architectural patterns this repo exemplifies or depends on
  • Data formats or contracts shared with other repos
  • Deployment or routing strategies that affect multiple repos

4b. Match against existing concept pages. For each concern, check whether a page already exists in tech/concepts/ or tech/integrations/. If it does:

  • Add a [[link]] to it from the repo note (you may have already done this in Step 3)
  • If this repo adds meaningful new context to that concept (e.g. the Flutter side of an auth flow that was only documented from the backend side), add a short section or bullet to the existing concept page under a heading like ## From [[this-repo]]

4c. Create new concept pages for gaps. If a concern is genuinely new (not covered by any existing page), create a page for it.

  • Cross-repo flows and integration patterns → tech/integrations/<slug>.md
  • Architectural patterns, service configurations, domain concepts → tech/concepts/<slug>.md

Use this frontmatter for concept pages:

---
type: concept-note
last-updated: YYYY-MM-DD
tags: [relevant, tags]
---

Use this frontmatter for integration pages:

---
type: integration-note
last-updated: YYYY-MM-DD
tags: [relevant, tags]
---

Each new page must:

  • Open with the three required header fields (**Summary**, **Sources**, **Last updated**)
  • Explain the concern clearly enough that an agent in any repo can act on it without reading source code
  • Use [[wiki-links]] to reference repo notes and other concept pages
  • Mark anything unknown as TBD rather than guessing
  • End with a ## Related section listing linked pages

Aim for 2-5 concept/integration pages per repo. Do not create pages for things that are fully explained by reading the code directly — the wiki captures what the code cannot explain on its own.

4d. Update tech/tech-index.md. Add any new concept or integration pages to the relevant section of the index.

Step 5 — Commit

Append one line to the Agent Change Log section of the repo note:

YYYY-MM-DD — initial knowledge extraction from codebase

Append one line to /Users/nikolashaag/Documents/Code/brain/log.md:

YYYY-MM-DD — populated <repo-slug> repo note from code inspection

Then stage and commit only the files you changed in the brain repo:

cd /Users/nikolashaag/Documents/Code/brain
git add tech/repos/<repo-slug>.md tech/concepts/ tech/integrations/ tech/tech-index.md log.md
git commit -m "wiki: populate <repo-slug> — initial extraction"

Constraints

  • Only write facts you can verify from the code. Mark unknowns as TBD.
  • Do not modify anything in /Users/nikolashaag/Documents/Code/brain/raw/
  • Do not modify business/ pages.
  • Do not invent package names, service names, or URL patterns.
  • Follow the page format and naming rules in STRUCTURE.md exactly.
  • Basenames must be unique across the entire vault. Check before creating a new file.
  • No em dashes anywhere.

Graph View

Backlinks