> ## Documentation Index
> Fetch the complete documentation index at: https://docs.acrity.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Quickstart

> Configure your first workspace, connect a repository, and run your first review in Acrity.

This guide shows the minimum path to start using Acrity in a workspace.

## Before you start

You need:

* Access to the Acrity Console.
* A user with Workspace admin permission in the workspace.
* Permission to install or authorize the code provider used by the team.
* At least one repository with active pull requests or merge requests.
* Optionally, administrative access to a work management tool such as Jira, Linear, or ClickUp.

## Recommended flow

```mermaid theme={null}
flowchart TD
  A[Select workspace] --> B[Connect provider]
  B --> C[Connect repositories]
  C --> D[Bootstrap ARCHITECTURE.md]
  D --> E[Adjust review policy]
  E --> F[Validate first PR/MR]
```

<Note>
  Connected Apps, Credentials, Connectors, Repositories, and Policy Engine require a Workspace admin (platform admins also have access).
</Note>

<Steps>
  <Step title="Select your workspace">
    Enter the Console and choose the workspace from the top selector.
  </Step>

  <Step title="Review language and members">
    In the workspace selector and workspace settings, confirm the default language, workspace admins, and users who need to track reviews.
  </Step>

  <Step title="Connect the code provider">
    Go to `Console > Connected Apps` when you can use OAuth or a GitHub App. Use `Console > Credentials` for manual credentials. Use `Console > Connectors` when the VCS is private, self-hosted, or on a restricted network.
  </Step>

  <Step title="Connect repositories">
    In `Console > Repositories`, select `Connect repository`, choose the authentication source, and confirm the repositories that should receive reviews.
  </Step>

  <Step title="Bootstrap ARCHITECTURE.md">
    Open the repository in `Console > Repositories > Repository detail` and start the ARCHITECTURE.md bootstrap. This gives reviews the project context they rely on. A repository is not ready for reviews until it has a bootstrapped ARCHITECTURE.md, so complete this step for every repository you connect.
  </Step>

  <Step title="Adjust the review policy">
    Use `Console > Policy Engine` for workspace rules and, when needed, adjust specific settings in `Console > Repositories > Repository detail`.
  </Step>

  <Step title="Validate the first PR or MR">
    Open or update a PR/MR in the code provider and track the review on the [Ops dashboard](/en/guides/ops-dashboard) — where reviews appear — and in the provider output. Use `Console > Audit Trail` only for technical event details and diagnostics.
  </Step>
</Steps>

## Quick decision: which connection type should you use?

| Scenario                                                                | Use                  |
| ----------------------------------------------------------------------- | -------------------- |
| GitHub Cloud with managed installation                                  | Connected GitHub App |
| GitLab, Bitbucket, Azure DevOps, Jira, Linear, or ClickUp through OAuth | Connected Apps       |
| Personal token, project token, or technical credential                  | Credentials          |
| Private VCS, self-hosted VCS, or no inbound access to the cloud         | Connectors           |

<Tip>
  Prefer Connected Apps when the provider supports them. They simplify authorization, reauthorization, and repository discovery.
</Tip>

## Production readiness checklist

* The workspace has at least two workspace admins.
* Important repositories appear as ready in `Console > Repositories`, each with a bootstrapped ARCHITECTURE.md.
* The workspace and repository languages are correct.
* The author policy blocks accounts that should not generate cost or review activity.
* API keys have minimum scope, expiration, and IP allowlist when applicable.
* Outbound webhooks use HMAC when the destination supports verification.
* Workspace admins reviewed the security pages before configuring production credentials.