> ## Documentation Index > Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt > Use this file to discover all available pages before exploring further. # Navigate a change > Move between views, layers, and files, search the artifact, track what you have already read, and share a link that points where you mean. export const EarlyAccessBadge = ({tip = "This feature is in early access. Enable it by setting `early_access: true` in your `.coderabbit.yaml`, or by toggling Early Access on the web interface.", title = "Early Access", cta = "View configuration", href = "/reference/configuration#param-early-access", disabled = false}) => { return {title} ; }; export const AzureBadge = ({tip = "This feature is available on Azure DevOps.", title = "Azure", cta, href, disabled = false}) => { return {title} ; }; export const BitbucketBadge = ({tip = "This feature is available on Bitbucket.", title = "Bitbucket", cta, href, disabled = false}) => { return {title} ; }; export const GitLabBadge = ({tip = "This feature is available on GitLab.", title = "GitLab", cta, href, disabled = false}) => { return {title} ; }; export const GitHubBadge = ({tip = "This feature is available on GitHub and GitHub Enterprise.", title = "GitHub", cta, href, disabled = false}) => { return {title} ; }; | A large pull request is a navigation problem before it is a reading problem. Change Stack gives you four ways through one: primary views that answer different questions about the same change, rails that walk the artifact by layer or by file, a search over everything already loaded, and links that address any point in the artifact precisely enough to paste into a conversation. ## Primary views The primary views are rows at the **top of the left rail**, above the divider that separates them from Layer 1. Click one to switch. Each answers a different question about the same snapshot, and switching between them does not change which snapshot you are on. | View | The question it answers | | ------------------- | ---------------------------------------------------------------------------------------------------------------- | | Overview | What is the state of this pull request, what did the review conclude, and what needs attention before it merges? | | Layer | What actually changed in this area of the code, and what did the review say about it? | | Blast Radius | What else could this change affect — which dependencies, consumers, and tests sit around it? | | Architecture Impact | Which system-level responsibilities and relationships changed, and how? | [Blast Radius](/security/blast-radius) and [Architecture Impact](/security/architecture-review) are produced by CodeRabbit Security; Change Stack displays them for the snapshot you have open and links their findings back into the code. [Findings](/change-stack/findings) covers what the Overview puts in front of you and how it ranks it. ## The left rail The left rail walks the artifact, in one of two modes. | Mode | What you get | | ------ | ------------------------------------------------------------------------------------------------------------------------------- | | Layers | The artifact's layer tree — the change grouped into coherent areas and ordered so foundations come before what depends on them. | | Files | The changed-file tree, for when you know the path you want. | Layers are the mode to default to, because the ordering is the point: it is the reading order the change deserves rather than the alphabetical one the provider gives you. Switch to files when you are looking for something specific rather than reading the change through. Inside a layer, the content splits by what you want beside the code: | Tab | What it shows | | -------- | ------------------------------------------------------------------ | | Files | The changed files and their diffs. | | Diagrams | Diagrams generated for this layer, where a visual earns its place. | Diagrams are Mermaid diagrams generated per layer, and the kind is picked to fit the change: a class diagram for schema and type changes, a sequence diagram for API and request/response flows, a flowchart for validation and data movement, a state diagram for lifecycle transitions, an entity-relationship diagram for persistence changes. A layer with nothing worth drawing — tests, configuration, documentation, cosmetic edits — gets no diagram, and the tab is empty rather than showing a trivial one. The review context beside the code splits the same way: | Tab | What it shows | | --------- | ------------------------------------------------ | | Summaries | The generated summaries for this layer's ranges. | | Comments | The review comments associated with this layer. | ## The right panel The right panel is either review context — summaries, comments, and the context for the range you have selected — or [chat](/change-stack/chat). It shows one at a time. ## The command palette and keyboard The command palette moves between views, layers, and files without touching the rails, and it doubles as the shortcut reference: every command it lists shows the key that runs it. Open it with Cmd/Ctrl+K or ?. The same navigation is available through responsive controls on a narrow screen, where the rails collapse. Change Stack is built to be driven from the keyboard, and the shortcuts are worth learning if you review often. | Key | Action | | ------------------------------------------------------------- | ---------------------------------------------------------- | | J / K | Next / previous layer | | L / H | Next / previous file | | Shift+J / Shift+K | Next / previous item in the review context panel | | C | Comment on the current item in the review context panel | | F | Show the Files tab | | D | Show the Diagrams tab, when the layer has diagrams | | U | Toggle between unified and split diff | | \[ | Collapse or expand the left rail | | ] | Toggle the right panel | | Z | Toggle focus mode | | O | Open the pull request on your provider | | / | Open search | | Cmd/Ctrl+K or ? | Open the command palette | | Esc | Clear the active comment, or clear the selected diff range | Focus mode hides both rails and the review context beside the diff, leaving the code on its own. It is the shortcut to reach for when a layer is dense and the chrome is in the way. Shift+J, Shift+K and C follow whichever tab the review context panel is showing: on **Summaries** they step through this layer's range summaries and comment on the one you are on, and on **Comments** they step through its comment threads — CodeRabbit findings and human comments alike — and reply to the one you are on. Switching that tab changes what those three keys act on. There is no keyboard shortcut and no command-palette entry for switching primary views; that is the left rail's job. Inside the diff, ↑ and ↓, PageUp and PageDown, Space and Shift+Space, and Home and End scroll the pane. In the comment composer, Cmd/Ctrl+Enter submits and Esc cancels. ## Search the artifact Search runs in your browser against the artifact already loaded, so it returns results as fast as you can type and works across five kinds of content at once. Five sources, each filterable on its own: **file** paths, **diff** text, indexed source **content**, generated **summaries**, and review **comments**. Two properties of a browser-side search are worth knowing rather than discovering. The index builds progressively as the artifact loads, so results can be incomplete while more of the artifact is still arriving. If a search on a large change comes back thin, run it again once the page has settled. Results are capped: a blank search returns at most 60 indexed records, and a query returns at most 200 ranked results. On a large artifact a broad query will hit that ceiling, so narrow the query or pick a source filter rather than scrolling for something that was never in the list. ## Track what you have read You can mark a file viewed and see reviewed-file progress for the snapshot you are on, which is what keeps a multi-session review from restarting every time you come back to it. Progress is recorded against the displayed snapshot, so it describes what you read of *that* review run. On GitHub, marking a file viewed also ticks GitHub's own **Viewed** checkbox on that file, so your progress is visible to other reviewers and survives a switch back to the GitHub interface. On GitLab and Bitbucket the marker is stored by CodeRabbit only — the provider has no equivalent state to sync to — so it is yours alone and does not appear on the merge request or pull request. ## Share a link Change Stack links address a specific place in the artifact: the change itself, a primary view, a layer, a file, or a range. That precision is what makes a link worth pasting into a conversation — you can point a colleague at the eleven lines you are actually asking about rather than at the pull request. Two link behaviors surprise people, and both are worth knowing before you paste. A link without explicit snapshot parameters follows the **latest** snapshot, not the one you were looking at. Your colleague may open it next week and see different findings against different code. When snapshot identity matters, share a URL that carries the review-run and commit parameters. See [snapshots and freshness](/change-stack/snapshots). A bare Change Stack URL opens the first layer, while an explicit overview URL opens the Overview. If you want someone to land on the Overview, link to it explicitly rather than assuming the bare link will get them there. ### Public links A Change Stack artifact for a public repository can be opened through a shareable locator without an authenticated CodeRabbit session, which is what makes it usable in an open-source discussion or a bug report. Anonymous access is limited to public GitHub and GitLab artifacts; Bitbucket requires authentication, and Azure DevOps artifacts are read-only. See [provider support](/change-stack/provider-support). A signed public locator expires after 24 hours. A public link that has stopped working is almost always this — generate a fresh share link rather than assuming access was revoked. ## The activity timeline The timeline puts pull-request activity and review checkpoints on one chronological surface, grouped into categories you can filter. Five categories are on by default and carry the substance of what happened: **CodeRabbit** review activity, **commits**, submitted **reviews**, **comments**, and **pull request status** changes. Three more are off by default, and you turn them on when you are reconstructing a history rather than reading forward: **bots**, **housekeeping** for administrative changes, and **misc** for anything outside the named categories. The timeline pages through history at 30 events per request, up to 100. Only GitHub provides a native provider event history. On GitLab, Azure DevOps, and Bitbucket the timeline contains synthesized review checkpoints instead — it tells you what CodeRabbit did and when, not everything that happened on the pull request. ## What's next Choose how the diff is organized and laid out, expand context, and read rendered diffs for prose and images. Read what the Overview puts in front of you and decide what to fix first.