1. Getting started

To use CodeCritic, you need an account. You can sign up in two ways:

Email and password: Register with your email address and create a password.
OAuth: Sign in with GitHub, Google, or X for quick access.

After registration, you can log in anytime from the homepage. Agree to our Terms of Service and Privacy Policy when creating your account.

2. Code review in the app

The simplest way to get a review is through the web app:

Go to New review (you must be logged in).
Paste code into the editor, upload one or more files, or combine both.
For uploads, set each file to To review (code under analysis) or Context only (supporting files such as types, helpers, or tests).
Optionally add a title and a short description (what to focus on, what to ignore).
Language is auto-detected by default; you can change it if needed.
Submit and wait for analysis to finish.
You will be redirected to the review details page when complete.

Context-only files are attached to the review for the model but are not treated as changed code. The results page lists which context paths were included when you upload helpers.

Each review consumes credits according to your plan or pay-per-use settings. Check usage in the Dashboard before submitting.

3. Understanding results

After a review completes, you will typically see:

Quality score (0–100): An overall read on the submission.
Categories: Feedback grouped by type (bugs, security, style, performance, and so on).
Issues and suggestions: Specific items with explanations and, where applicable, suggested code.

Past reviews appear in the Dashboard under Reviews. Open any row for full detail.

4. Review chains, Mark as done, and Dismiss

On a completed review, each issue and suggestion can reflect your choice. Two actions behave differently and tie into review chains when you iterate.

What is a review chain?

A chain is a sequence of reviews that belong to the same workstream: for example, you finish a review in the app, edit the code, and submit again from the same review page, or your GitHub Action runs again on the same pull request after new commits. Linked reviews share a chain root so CodeCritic can keep context (including what you dismissed) across runs.

Mark as done

Use Mark as done when you have read, fixed, or accepted a finding and want to track progress. The item stays visible in the list, and counters show how many issues or suggestions you have marked. This is for your workflow on the current result. It does not add the finding to the list we send back into the model on the next review in the chain.

You can Undo done if you change your mind.

Dismiss

Use Dismiss when a finding does not apply, is a false positive, or you deliberately choose not to act on it. Dismissed items are collapsed in the UI (you can show them again with the dismissed toggle). For the whole chain, we store that choice and pass a compact summary of dismissed findings into the next review in the chain so the model is instructed not to repeat the same feedback unless the new code clearly brings the problem back.

That guidance is best-effort: the model may still surface a similar point with different wording, and very long dismissal histories may only include the most recent items in the prompt. You can Undo dismiss to restore the finding as active.

Quick comparison

Done - visible, progress tracking, not sent as "do not repeat" to the next chained review.
Dismiss - collapsed by default, remembered on the chain, influences the next review in that chain.

5. Trust focus

Trust focus is a second analysis pass that runs as part of the same review you already start from the app, API, or GitHub. It does not use an extra review from your monthly quota. It complements the main score and issues with a merge-trust angle: what passing CI might still hide, what to verify by hand, and where the model has limited context.

On the review details page you will typically see:

Merge trust level (low / medium / high): A compact risk read for merging, with a short rationale.
What green CI can miss: For example, when tests, linters, or lockfiles changed so green checks do not mean what they usually do.
Assumptions, invariants, failure modes: Implicit expectations, boundaries (auth, data, APIs), and concrete "if this is wrong, users see…" style outcomes.
Verification ladder: Suggested steps or checks in a sensible order before you ship.
Blind spots: Honest limits of the analysis when only a snippet or diff was sent (no full repo, prod config, or runtime).
Technical signals from diff: Expandable JSON summarizing path categories (tests, CI configs, lint config, lockfiles, and similar) and simple flags the engine detected. The AI uses this to stay grounded; it is not a second opinion from a separate product.

For pull requests, the optional PR comment includes a short Trust focus block (risk line, rationale, and a few bullets) so the thread stays readable.

Trust focus works for pasted code as well as for git diffs. For a small snippet, expect stronger emphasis on blind spots because there is less surrounding context.

If Trust focus fails for a run, the main review still completes; you may see a short notice instead of the full block.

Turning Trust focus on or off: On Pro and Enterprise, open Dashboard → Settings → Review Settings and use the Trust focus toggle. It is off by default until you enable it.

Turning Trust focus off (operators): On the API and workers that run reviews, set the environment variable TRUST_FOCUS_ENABLED=false (this overrides everything else). Alternatively, create or update the system setting trust_focus_enabled as a boolean false in the settings table, or via the admin settings API if you use it.

6. Review policies

Review policies steer how the AI reviews code beyond generic bug hunting. You set team standards, path rules, security bar, style strictness, and focus areas once; CodeCritic injects them into the review prompt and surfaces violations as separate Policy findings in the app and on GitHub PR comments. Policies are guidance for humans - they do not fail CI or block merges by themselves.

Where to configure

Open Dashboard → Settings → Review Settings. Everything lives on one page:

Review policies (account defaults) - your baseline for all reviews.
Repository policy overrides - optional per-repo rules when GitHub is connected (pick a repository, enable override, save). Without GitHub, use the link on that block to connect in Integrations.

Account defaults save with Save Settings (together with pay-per-use and Trust focus). Repository overrides use Save repository policies after you select a repo.

What applies when

Paste and API reviews - account defaults only. The review details page shows Applied: Account review policy in the policy snapshot.
GitHub Action and webhook PR reviews - account defaults, merged with a repository override when you configured one for that owner/repo. Snapshot shows repository as the source when an override is active.

Repository overrides are partial: only fields you set replace or extend account defaults; everything else inherits.

Policy fields (account and repo)

Team standards (custom instructions): Free-text rules for your team (for example service objects in app/services, no raw SQL in controllers). The model treats violations as policy findings, not generic nits.
Excluded paths: Glob patterns for generated or low-signal files (vendor/**, lockfiles, node_modules/**, and so on). The AI is told not to report issues on excluded paths; the server also filters stray hits when paths are known.
Paths that require test changes: If code under these globs changes without matching test updates in the diff, the model reports a policy finding (for example app/services/**).
Style strictness: Relaxed keeps style mostly in suggestions; Balanced is the default product behavior; Strict elevates naming and format issues toward should-fix.
Security bar: Standard vs Strict - in strict mode, auth, crypto, PII, and injection on touched lines more often get blocking-level priority.
Review focus: Per area (security, performance, style, tests, error handling) choose emphasize, normal, or de-emphasize. Account default de-emphasizes style slightly.

Policy findings in results

Regular issues are bugs, security, and quality independent of your written standards. Policy findings reference a rule (with a title badge) when the model believes your configured policy was violated.

In the review UI: a dedicated Policy findings block and a filter to show policy findings only.
On GitHub PRs: an optional Policy findings section in the comment, grouped by fix priority like other findings.
Expand Applied policy on the review page to see the snapshot (account vs repository, effective rules at review time).

For pasted snippets without file paths, path-based rules are best-effort; the prompt tells the model to skip path policy findings when paths are unknown.

What policies do not do (yet)

No automatic merge blocking or required-check status from policy alone.
No running ESLint, RuboCop, or other linters - only LLM plus path heuristics.
No org-wide shared defaults across companies (account + repo only in the current release).
No named policy profiles or picker on New Review for paste - one account default applies; profiles are on the roadmap.

See also: Roadmap (live vs planned policy work) and section GitHub Action for PR setup.

7. GitHub Action

CodeCritic can review pull requests via a GitHub Action. Setup at a high level:

Copy your API key from the Dashboard (Settings → API key).
In the repo: Settings → Secrets and variables → Actions.
Add a secret named CODECRITIC_API_KEY with your key.
Add .github/workflows/codecritic.yml with content like:

name: CodeCritic Review
on:
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: CodeCritic-Reviews/review-action@v1
        with:
          api_key: ${{ secrets.CODECRITIC_API_KEY }}

When you open or update a pull request, the workflow runs and can post the review as a comment. Common inputs:

api_url - API endpoint (default: https://api.code-critic.com)
wait_for_completion - Wait for the review to finish (default: true)
post_comment - Post results as a PR comment (default: true)
timeout - Max wait in seconds (default: 600)

8. VS Code or Cursor

The CodeCritic extension lets you run reviews from the editor: selection, whole file, picked files, or a folder (text files only, with size limits). Results open in a panel inside the editor (score, issues, suggestions, Trust focus, Done / Dismiss) using the same billing rules as the app.

API key: Use CodeCritic: Set API key and paste the key from Dashboard → Settings → API key. The extension sends Authorization: Bearer <your API key> to /v1/code_reviews on the API host (default https://api.code-critic.com), same billing as the web app (your key is not a JWT; the API accepts either).

Optional: Set codecritic.apiBaseUrl if you use a non-default API host. Review preferences (Trust focus, pay-per-use) stay in the web Settings.

9. Billing and usage

CodeCritic offers subscription plans and optional pay-per-use credits:

Plans: Tiers with different monthly review limits. See Pricing for current options.
Pay-per-use: Extra credits when you exceed plan limits, where enabled in Settings.
Billing: Subscription and payment methods on the Billing page.
Transactions: History on the Transactions page.

10. Settings

In the Dashboard, open Settings to:

View or regenerate your API key (Action and API access).
Enable or disable pay-per-use and Trust focus, where available.
Set review policies (account defaults and GitHub repo overrides).
Manage notification preferences.
Configure two-factor authentication (2FA).

11. AI review rollout (team playbook)

If you are standardizing how the team uses automated review, start with the public playbook AI code review best practices. It covers pilot scope, merge ownership, and what to measure beyond raw speed, with links to limitations and pricing.

For a longer narrative aimed at leads and security stakeholders, read How to run AI code review inside a real team workflow on the CodeCritic blog.

12. Support

If you need help:

Email: support@code-critic.com
GitHub: Issues for the review action
Status: API and system status
Legal: Terms · Privacy

User guideget productive fast