# 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
```

![setup repos command](/files/sNbSgVNYxnHwoRJNeoYQ)

***

## 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**.

![results](/files/uB9LHWDlQeaeRQwsktyc)

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.

![evidence](/files/cHpSMhLo6fEuE6sUzToP)

### 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:

| Mode              | What it means                                                                                        | Default |
| ----------------- | ---------------------------------------------------------------------------------------------------- | ------- |
| **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.                 | ❌       |

![grouping](/files/8JUSA2fEVRkKxWa1yS4e)

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.opscanvas.io/oscar/setup-repos.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.