Back to home

Docs

User guideget productive fast

How to use CodeCritic from sign-up to GitHub Action.

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:

  1. Go to New review (you must be logged in).
  2. Paste your code into the editor or type it directly.
  3. Optionally add a title to help identify the review later.
  4. Language is auto-detected by default; you can change it if needed.
  5. Submit and wait for analysis to finish.
  6. You will be redirected to the review details page when complete.

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. GitHub Action

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

  1. Copy your API key from the Dashboard (Settings → API key).
  2. In the repo: Settings → Secrets and variables → Actions.
  3. Add a secret named CODECRITIC_API_KEY with your key.
  4. 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)

7. 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.

8. 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.

9. Settings

In the Dashboard, open Settings to:

  • View or regenerate your API key (Action and API access).
  • Enable or disable pay-per-use, where available.
  • Manage notification preferences.
  • Configure two-factor authentication (2FA).

10. Support

If you need help: