Chat With a GitHub Repository: An AI Codebase Guide

To chat usefully with a GitHub repository, give the assistant access to the correct repository and revision, then ask a bounded question that can be answered from specific files. A repository URL alone does not establish that the assistant has read its contents. Start by checking what it can actually see.

This guide uses Brainbaby’s repository attachment workflow. You can explore the GitHub integration first, or open chat if you already have an account.

Attach the right repository and check its scope

Open the repository attachment dialog in chat. When GitHub is connected, choose a project from Your GitHub repositories. The filter searches the repositories already loaded; use Load more repositories if the project is not in that list. Check the account shown above it so you do not choose a similarly named project from the wrong account.

Select the repository, then choose its Working branch. Read the preview before using Attach: it shows the repository name, branch, a short revision identifier and a file list. A protected branch can appear in the picker; that does not grant permission to write to it.

The chat dialog also accepts a repository URL or owner/name as a fallback. Enter it and choose Load when you need a specific public repository or cannot find a project in the loaded list. Private repositories still require the connected account to have access. Baby Code uses its own repository picker; choosing a repository there is distinct from attaching an overview to a chat message.

The attachment supplies an overview to the next message. It is not proof that every file has been read, that the latest uncommitted changes are included, or that a runnable development environment exists. Pay attention to any warnings in the preview. If the question concerns a different branch, establish the correct source before asking for a fix.

Do not paste access tokens, private keys or production environment files into the conversation. Share the smallest relevant code excerpt when the connector cannot access a file.

Start with a codebase map

A broad request such as “explain this repo” often produces a summary of the README. Ask for the route through the code that a new contributor needs instead:

Help me understand this repository at the attached revision. Identify its entry point, main folders, dependency manifest, test commands and configuration examples. For every claim, name the file you inspected. Separate verified findings from assumptions. If you only have the file tree, say which files you need next.

Review the answer against the repository. Does the entry file exist? Does the package manifest actually contain the suggested command? Has the assistant confused a frontend package with the backend? A useful map should reduce the number of files you need to inspect, while leaving the evidence visible.

GitHub’s own guide to exploring a codebase with Copilot also recommends asking about structure and requesting examples linked to repository files. Brainbaby has a different interface; use its available tools rather than assuming feature parity between products.

Trace one feature from input to output

Choose a feature you can recognize in the app, such as saving a document. Follow the UI event to its request, server handler and storage operation. This reveals more than a list of folder descriptions.

Trace what happens when a user saves a document. Start at the button or form handler, then identify the API call, authorization check and database write. Give file paths and function names. Mark any step you cannot inspect as unknown. Do not suggest changes yet.

For a small project, a short ordered list may be enough. In a larger project, ask for a table with step, file, function and responsibility. Check that the assistant has followed imports and real calls rather than matching similarly named files.

Debug with a reproducible example

Include the action you took, expected result and actual result. A screenshot can help describe the interface, but a sanitized error and the relevant handler are often needed to investigate a code defect.

On the attached revision, saving an empty document shows success but the document disappears after refresh. Expected: a validation message before saving. Trace the existing validation and persistence path. Rank possible causes by evidence, identify the smallest proposed fix and suggest a regression test. Do not claim you ran a test unless a tool actually ran it.

Treat the proposed cause as a hypothesis until it matches the reproduction. Ask the assistant to explain why the change fixes that behavior and whether another caller uses the same function. Avoid broad refactors during the first debugging pass: they make it harder to tell which change mattered.

Review a patch before applying it

Reading a repository, generating a patch and writing to GitHub are separate actions. Confirm the available permissions and inspect the proposed diff before allowing writes. Review changed files for unrelated edits, newly added dependencies and missing failure handling.

A focused review prompt is:

Review this diff for the reported bug. Check authorization, error states and behavior when the request is retried. Identify concrete issues with file references. List the tests actually run separately from tests still recommended.

Run the project’s documented checks in an appropriate environment. A plausible explanation is not a passing test result. If the tool cannot run the project, keep that limitation in the handoff.

Common questions

Why does the assistant still ask for a repository link?

A connected account identifies which projects the service may access; it does not select the project for the conversation. Use the repository picker and verify its branch and revision before asking about the code. You should not need to copy a link for a repository you can select there. Use the URL fallback when the project is absent from the loaded list, then investigate account access or organization permissions if it still fails.

Can the assistant understand the entire repository at once?

Do not assume so. Repository size, tool access and the available context affect what can be inspected. Ask for the relevant files explicitly, work through one feature at a time and require the answer to state what remains unread.

Diagnose an empty or failed repository list

Check whether the dialog is still restoring your session or loading repositories before treating an empty list as a missing project. If it says No matches in the loaded repositories, clear the filter or load another page. Refresh reloads the connected list; it does not expand the account’s permissions.

An explicit Reconnect GitHub message means the saved connection was rejected. Follow that path when it appears, then retry the same project. A branch error has its own retry control; it is not proof that the entire account must be reconnected. For a private organization repository, verify the connected account’s access and any organization authorization requirements in GitHub.

Download a repository review worksheet

The free repository review worksheet gives you a Markdown record for the repository, revision, reproduction, inspected files, proposed change and actual checks. It requires no account to download. Copy it into your project notes and fill in only what you have verified.

The worksheet is not an executed test report. Leave an unavailable check marked not run, and keep proposed changes separate from applied changes. This makes it useful for handing work to a teammate or returning to a chat later without losing the evidence.

Keep a reusable onboarding note

Save a short note with setup commands, a feature map, important constraints and unresolved questions. Include the revision it describes so a future reader can tell when it is stale. Use the document workflow guide to turn reviewed findings into an onboarding document. Check current plan allowances before a long series of repository requests.

Verify connected access before repeating the setup

A connected GitHub account and an attached repository are different states. Check the account, repository, branch and the connection's permitted scope. If the assistant cannot read a private repository, inspect the selected account and granted access before pasting secrets or repeatedly starting a new connection. Never infer that all repositories are available from a connection badge alone.

Start a codebase question by asking for the actual files inspected. For example: “Trace the checkout form from its submit handler to the request function. Name the source files, explain which facts come from them and identify anything you could not read.” If the files are unavailable, the correct next step is to fix access or supply the relevant source, rather than accept an invented explanation.

Evaluate a change before handing it to a client

For a duplicate-submit bug, check double clicks, keyboard submit, a rejected request and retry. Review whether the patch matches the existing API contract. Separate an explanation, a source edit, a test result, a draft pull request, a merge and a deployment. An assistant's description of running a check does not establish that it happened.

The coding systems comparison provides an eight-point acceptance checklist and a local-versus-hosted comparison. For a nontechnical stakeholder, turn the verified facts into a short report using the client deliverables workflow. Do not promise a fixed response time or a universal model-quality winner from one repository exercise.