Set Up Repositories
The /setup repos command teaches Oscar about your infrastructure by analyzing the repositories on your workstation. Once set up, Oscar can answer questions about your applications, environments, and services directly from its local knowledge graph — without needing to reach out to GitHub, AWS, or kubectl every time.
Run it from the Oscar terminal:
/setup repos
What Happens
Oscar scans the repository roots you point it to, analyzes each one using a combination of file inspection and CI/CD evidence, and builds a picture of what it found: which applications and services live in the repo, which environments they deploy to, and how the pieces relate to each other.
When the scan is complete, Oscar opens a browser-based review page where you can confirm, adjust, or skip each repo before anything is saved.
The Review Page
The review page shows one card per repository. Cards that need your attention are in the Remaining bucket. Cards for repos that haven't changed since your last run appear in Unchanged.
Each card shows:
Repo — the repository name and provider (GitLab, GitHub, etc.), with a disclosure toggle to view the raw evidence Oscar used to identify it
Application — the application identity Oscar detected
Environments — the deployment environments (lower, production, etc.)
Services — the individual deployable units within the repo
You can edit any name before confirming. Click a chip to set an alias. Use × to remove an application, environment, or service from the repo. Use ↺ to undo a removal.
Evidence
Each entity shows a show evidence toggle. Clicking it reveals the signals Oscar used to identify it — git remote URLs, CI pipeline variables, directory structure, file patterns, and config values. This is useful for spotting misidentifications before you confirm.
Confirming and Skipping
Confirm — saves the proposal to your local topology. Confirmed cards are locked for this session.
Skip — discards the proposal. The repo will appear again on the next run.
When all remaining cards are resolved, Oscar notifies you in the terminal to continue.
Grouping
When Oscar finds multiple deployable services in a single repository, it needs to know how they relate to each other. The grouping control at the bottom of each card lets you choose:
Microservices
Multiple services grouped under one parent application. Each service deploys to shared environments.
✅
Monorepo
Each service is its own independent application. No parent grouping.
❌
Monolith
The repo is a single application. Service names are preserved as searchable aliases.
❌
Hover over each option to see a description. The control updates the staged proposal immediately — nothing is committed until you hit Confirm.
Running Again
You can run /setup repos as often as you like. On subsequent runs, Oscar checks for changes since the last scan. Repos that haven't changed appear as Unchanged and require no action. Repos where Oscar detects new services, changed environments, or updated CI configuration appear as Remaining for review.
Aliases and grouping choices you made in earlier sessions are preserved.
How This Helps Oscar
Every time you ask Oscar about your infrastructure — which tag is running in production, whether a service has been deployed to lower, what environments a repo targets — Oscar checks its local topology first.
With repositories set up, Oscar can:
Identify the right scope immediately. When you ask about "opsrunner-api in lower," Oscar resolves the application, environment, and runtime access in one local lookup instead of searching across GitHub, kubectl contexts, and cloud accounts.
Reach for external tools less. Fewer API calls and CLI invocations means faster answers and lower token usage. Oscar only reaches for kubectl or the cloud provider when the topology doesn't have what it needs.
Avoid guessing context. Without topology, Oscar may query the wrong environment or make assumptions about which cluster "lower" refers to. With it, the mapping is explicit.
The topology grows incrementally as you set up more repositories, add observability connections, and map runtime access. The more Oscar knows, the less it has to discover on every question.
Last updated
Was this helpful?