Get started for engineering users
Use Glean Tau to investigate a codebase, make changes, run local tools, and review the result without switching between separate applications. Glean Tau connects company context, such as design decisions, owners, and tickets, to the actual paths in your local checkout.
Common engineering tasks include:
- Map an unfamiliar repository before your first change
- Turn one ticket into a local patch that a reviewer can trace back to its requirement
- Review a branch without running builds
- Adapt a fix across repositories
For a guided tour of the review and comment tools, see Fix a failing test with enterprise context.
Import a repository
To start, link a local repository to a project.
Add a project
In the left sidebar, select Add project (the folder icon beside the Chats heading).
Choose the import option
Select Import existing folder.
Select your repository
Choose your repository folder to import.
Glean Tau names the project after the selected folder and starts a new chat with that folder as its working directory. The project then appears in the sidebar's Chats list. For Git repositories, Glean Tau detects the current branch and makes the Review panel available.
Set agent access approval mode
Before you start, set how much the agent can do on your computer. In the composer, click the access approval mode control (it shows the current mode, such as Approve for me) and choose a mode.
Start with Approve for me for automatic review, or choose Ask for approval to review permission requests yourself. Use Full access only when you accept broad access to your local files, credentials, and network and your organization permits it. A project folder doesn't contain all effects of Full access. See Agent approval modes.
Then prompt the agent to investigate or change the code, for example, "Find where we validate API tokens, explain the flow, and add a test for expired tokens."
Review code
After your agent edits local files, a line under its response shows the number of files edited and the lines added and deleted. Select that line to open those edits in Review. You can also open Review from the side panel while working in a chat connected to a Git repository.
Choose what to inspect from the scope dropdown menu:
- Last edits shows the agent's most recent edits made with its file-editing tools
- Uncommitted shows current working-tree changes relative to HEAD. Choose All, Staged, or Unstaged
- Branch shows committed changes between the branch's merge base and HEAD
- Commits shows the changes introduced by a selected commit
- Pull request shows the combined diff of the branch's GitHub pull request, when it has one
The diff shows additions, deletions, and the files affected by the selected scope. Use Show files to browse or filter the changed files, and Collapse all files to fold them. You can switch between unified and split diffs, and More actions has Find in review and Wrap lines.
Changes appear in Review as the agent works and whenever the repository's Git state changes. Before committing, switch to Uncommitted → All to check the full working tree, including changes made outside the most recent agent turn.
For branch and pull request status, open the Overview drop-down in the chat header. It shows the current branch and worktree, and, when the branch has an open pull request, the PR number, title, draft state, failing checks, and unresolved review comments. See Take action on chat context.
To switch branches, open the branch picker in the composer and select a branch. A branch that's checked out in another worktree is unavailable, and switching to an existing branch needs a clean working tree, so commit or stash your changes first.
To start a new branch from the current one, select Create and checkout new branch… in the branch picker. Enter a Branch name and select Create. Glean Tau checks out the new branch and keeps your uncommitted changes.
Add and manage comments
Comments are local notes on specific diff lines. They aren't published to Git or GitHub. Glean Tau collects them in the composer and sends them with your next prompt, so you can point at exact lines instead of describing them.
Add a comment
Select the lines
In the Review panel, hover a line and select the + button in the gutter. To cover a range, drag the + button across the lines.
Enter your request
Enter your request in the Local comment box. The header shows the target, such as Comment on lines R42–R57 (R is the new side, L the old).
Save the comment
Select Comment or press Enter. Use Shift+Enter for a line break, Esc to discard.
The comment appears inline below its target line. Select Edit to change it, or Remove to delete it.
Find where comments surface
- Inline in Review, below the lines they target.
- In the composer, as a count such as 3 comments. Select Discard all comments beside the count to remove every pending comment.
Understand how comments reach the agent
Comments are instructions for your next message. When you send, queue, or steer, Glean Tau prepends each comment with its file path, line range, text, and a fenced excerpt labeled Diff context, then clears them. Unsent comments are saved with the chat and survive reopening it.
Here's an example of how to prompt the agent regarding your comments: "Address these review comments with the smallest safe patch. Don't change unrelated files."
You can also comment on selected text in an open artifact in the Library.
Comment limitations
- Comments are local drafts, never posted to a pull request or shared with teammates.
- There's no resolve action. You either remove a comment or send it, which clears it.
- Remove single comments inline in Review. The composer can only discard all comments at once.
- Glean Tau sends every pending comment, even if the code it targets changed after you wrote it. Before you send, remove comments that no longer apply.
- When you review a pull request, GitHub review threads appear inline with author, timestamp, comment count, and a · Resolved or · Outdated marker. They're read-only here: select Open on GitHub to reply or resolve, or select Fix beside the unresolved comment count on the Pull request card in Overview to start working through them. Requires the Pull requests capability.
Fix a failing test with enterprise context
Investigate, plan, implement, validate, review, correct, and ship with Glean Tau. Consider the following example scenario, where test_expired_token_rejected fails intermittently in code you didn't write.
Open the repository
Select Add project in the sidebar, then Import existing folder. Glean Tau starts a chat in that folder, detects the branch, and enables Review. See Import a repository.
Set the approval mode
Choose Approve for me for automatic review or Ask for approval for direct review of permission requests. Both modes can run work already permitted by an applicable rule. Check the sandbox setting separately. See Agent approval modes.
Investigate before changing anything
Prompt the agent to find the cause without editing files: "The test test_expired_token_rejected fails intermittently. Find the root cause, explain the token validation flow with file paths, and don't change any files yet."
Tool activity collapses into rows such as Read 6 files or Ran commands. Expand any row for the exact file, command, or output.
Add the context only Glean has
Ask about the history behind the code: "Search our company knowledge for the original design decision behind this token expiry window, and any incidents or tickets that mention this test."
Results come back as source chips you can open, so you can tell a design choice from a bug.
Approve a plan
Ask for a plan before any edits: "Make a short plan for the smallest safe fix. Wait for my approval before editing."
The composer shows progress such as Step 2 / 5. Select it to see each step's status. Narrow the scope before approving: "Skip the refactor. Only fix the expiry comparison and update the test."
Implement and validate
Approve the work and scope the test run: "Implement the approved plan, then run only the affected test target."
The composer tracks a running total of files changed, with added and removed line counts. During a run you can queue a follow-up with Enter, interrupt and redirect with Cmd+Enter, or stop with the Stop button or Esc twice. To make Enter steer instead of queue, change Settings → Personalization → Composer → Follow-up behavior to Steer.
Review the diff
A line under the response shows the number of files edited, with added and deleted line counts. Select it to open Review in Last edits scope, then switch to Uncommitted → All to confirm nothing else is unexpected. Use Show files to step through each file and the split view for larger edits. See Review code.
Comment on what needs to change
On the expiry comparison: "Use a monotonic clock here. Wall-clock time makes this flaky under clock skew."
On the test: "Add a case for a token that expires exactly at the boundary."
Then send one instruction: "Address these comments with the smallest safe patch and rerun the affected test."
Both comments arrive with their file paths, line ranges, and diff context, and clear once sent. See Add and manage comments.
Verify, then commit
Confirm the result before shipping: "Show me the full uncommitted diff and the test output one more time."
When it's right, ask for the Git work explicitly: "Commit these changes with a message describing the root cause, push the branch, and open a pull request that summarizes the fix, the test coverage, and the internal decision doc you found."
Glean Tau performs Git actions only when you ask.
Make it repeatable
Create a skill for your team's review checklist or pull request format (see Use and create skills), or a read-only automation that reports flaky and skipped tests weekly (see Create an automation).
Engineering use cases
Each of the following use cases lists when to use it, what to start with, the steps, what you get, and a prompt to try. Replace the bracketed placeholders with your own repositories, files, and checks. The prompts keep the work local and reviewable: they tell Glean Tau not to commit, push, or open pull requests, so you decide what ships.
Map an unfamiliar repository
Use it when: You need to understand a component before your first change, without guessing from documentation alone.
Start with: One local checkout at a known revision, a question about a component, and relevant docs.
- Confirm the folder, revision, and project rules. Inspect entry points, configuration, and test scripts without running them.
- Use Glean to find relevant owners and design decisions. Distinguish what the documentation claims from what the checkout shows.
- Save a component map with file paths, source links, open questions, and a proposed first check for maintainer review.
You get: A local repository map and first-task brief, with evidence and a proposed check. Look for correct entry points, a pinned revision, traceable ownership, and a check that's clearly marked as not yet run.
Try it:
"Using local [repo] and [docs folder], map [component]. Read project rules; inspect entry points and test scripts; use Glean for relevant owners and decisions. Save [repo-map.md] with file and source links, a proposed check, and uncertainties. Keep repository inputs unchanged; don't run commands, send, publish, or change systems."
Make it better:
- Ask for a task-to-file routing table: which module owns the behavior, which guide explains it, and which check could verify it.
- Save a small status handoff with the revision, open questions, and next action. Refresh it when the checkout changes.
Turn one ticket into a local patch
Use it when: A small ticket has clear acceptance criteria and you need a reviewable change, not an autonomous release.
Start with: A local checkout, a ticket export, and a list of offline checks you allow the agent to run.
- Read project rules and existing edits. Map each acceptance criterion to the relevant files and the Glean sources that record the decision.
- Implement the smallest scoped change. Preserve unrelated edits, and stop if requirements conflict or the change grows.
- Run only the allowed offline checks. Inspect the local diff in Review and record exact results, skipped checks, and unresolved assumptions.
You get: A local patch, an acceptance checklist, and check results for engineer review. Look for changes only in the intended files, sourced requirements, and failed or skipped checks that stay visible.
Try it:
"For local [repo] and [ticket export], implement only [acceptance criteria]. Read project rules; preserve existing edits; cite relevant Glean decisions. Run only these offline [checks]. Return a local diff, exact results, and unresolved assumptions. Don't commit, push, open PRs, merge, deploy, send, publish, or change production."
Make it better:
- Create a requirement-to-file checklist with source links. Ask the owner to resolve conflicting or unsupported requirements before editing.
- Choose a focused behavioral regression check. Compare before-and-after results, and record when reproduction or validation isn't possible.
Review a branch without running builds
Use it when: You want focused feedback on a local branch, especially when compiling or running tests would be costly or inappropriate.
Start with: A local checkout, the base and head revisions, and the review requirements.
- Confirm the base and head revisions, project rules, and existing edits. Review only the selected local diff.
- Inspect changed paths and related callers statically. Separate confirmed findings from untested risks.
- Draft line-referenced comments and suggested fixes. Leave the code and external review systems unchanged.
You get: Unsent, evidence-linked review comments with suggested fixes and explicit validation gaps. Look for actionable findings tied to actual lines, labeled hypotheses, and no implied approval or passing tests.
Try it:
"Review local [repo] diff [base..head] statically against [requirements]. Read project rules and relevant Glean decisions. Don't compile, run tests, or edit code. Save [review.md] with line references, evidence, suggested fixes, and unverified risks. Don't post comments, send, publish, commit, push, open PRs, merge, or deploy."
Make it better:
- Save a skill for static-only review with your checklist, and verify its instructions.
- Ask for a sequence diagram of a risky changed path. Verify every transition against the code and label untested behavior.
- To review a GitHub pull request in place, use the Pull request scope in Review and the Pull requests panel.
Adapt a fix across repositories
Use it when: A known fix exists elsewhere, but the target repository has different code paths, dependencies, or tests.
Start with: The source diff, two local checkouts, the target requirement, and offline checks.
- Pin the source and target revisions. Read both repositories' project rules and identify the behavior the source fix changes.
- Map equivalent target paths and dependencies. Make a bounded local adaptation, preserving existing edits and documenting differences.
- Run target-specific offline checks. Save the patch, a source-to-target map, and unresolved compatibility questions for maintainer review.
You get: A local target patch, adaptation notes, and check results linked to the source fix. Look for matching behavioral intent, justified differences, and target-specific evidence, with no assumed compatibility or merge readiness.
Try it:
"Using local [source repo or diff] and [target repo], adapt only [fix intent]. Read both repositories' project rules; map target behavior and dependencies; preserve existing edits. Run only these offline [checks]. Return a local patch, adaptation notes, and uncertainties. Don't commit, push, open PRs, merge, deploy, send, publish, or change production."
Make it better:
- Keep a source-to-target behavior map. Explain every adaptation rather than copying the patch blindly.
- Prove the fix in one target first. Then expand through a list of repositories, with a diff and check results for each.
For security-focused review of a code or configuration change, see Review a security-sensitive change.