> For the complete documentation index, see [llms.txt](https://docs.currents.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.currents.dev/getting-started/setup-with-an-agent.md).

# Set Up with an AI Agent

Set up Currents with Claude Code, Cursor, Codex or another coding agent, locally and in CI

Paste this prompt into your coding agent, in the repository with your tests:

```
Set up this repository to report test results to Currents. Read https://docs.currents.dev/getting-started/setup-with-an-agent.md and follow it.
```

To add Currents to CI in a repository that already reports from a local machine:

```
Add Currents to this repository's CI. Read https://docs.currents.dev/getting-started/setup-with-an-agent.md and follow the "Add Currents to CI" section.
```

The rest of this page is written for the agent. It points to the setup guide for each framework and adds the steps those guides leave to the reader.

## 1. Ask for the Project ID and Record Key

Ask the user for both values. Currents shows them right after the user creates a project. Later, the Project ID is in [Project Settings](https://docs.currents.dev/dashboard/projects/project-settings.md) and the Record Key is under **Record Keys** in the organization menu ([Record Key](https://docs.currents.dev/guides/record-key.md)).

Read both from environment variables: `CURRENTS_PROJECT_ID` and `CURRENTS_RECORD_KEY`. Where a guide writes a project ID or key into a file, use the environment variable instead. Never commit the Record Key.

## 2. Follow the guide for the framework

| Framework                                                     | How to tell                                | Guide                                                                                                                 |
| ------------------------------------------------------------- | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------- |
| Playwright                                                    | `@playwright/test` in `package.json`       | [Quick Start](https://docs.currents.dev/getting-started/your-first-playwright-run.md)                                 |
| Jest                                                          | `jest` in `package.json`                   | [Your First Jest Run](https://docs.currents.dev/getting-started/other-frameworks/jest/your-first-jest-run.md)         |
| Vitest                                                        | `vitest` in `package.json`                 | [Your First Vitest Run](https://docs.currents.dev/getting-started/other-frameworks/vitest/your-first-vitest-run.md)   |
| Cypress                                                       | `cypress` in `package.json`                | [Your First Cypress Run](https://docs.currents.dev/getting-started/other-frameworks/cypress/you-first-cypress-run.md) |
| Node test runner                                              | `node --test` in the test script           | [@currents/node-test-reporter](https://docs.currents.dev/resources/reporters/currents-node-test-reporter.md)          |
| Anything that writes JUnit XML: WebdriverIO, Postman (Newman) | A JUnit reporter in the test configuration | [JUnit](https://docs.currents.dev/getting-started/other-frameworks/others.md)                                         |

Make every change the guide lists, using the repository's package manager. If the repository has more than one test suite, for example Playwright end-to-end tests and Jest unit tests, set up each one and run each one in step 3.

For Cypress, check the version first. Currents doesn't support Cypress 13 and later; see [Compatibility](https://docs.currents.dev/getting-started/other-frameworks/cypress/integrating-with-cypress/compatibility.md). Tell the user instead of changing their Cypress version.

## 3. Run the tests once

Run the tests with both variables set, for example:

```bash
CURRENTS_PROJECT_ID=<project-id> CURRENTS_RECORD_KEY=<record-key> npx playwright test
```

The run reached Currents when the output has a link to it:

* Playwright prints `Run URL: https://app.currents.dev/run/...` when the run starts.
* Jest, Vitest and JUnit print the link when `currents run upload` finishes.

Give the user the link. If there is none, follow [Missing Runs](https://docs.currents.dev/guides/missing-runs.md).

## Add Currents to CI

1. Find the CI provider from the repository files, such as `.github/workflows/`, `.gitlab-ci.yml`, `.circleci/config.yml`, `Jenkinsfile`, `azure-pipelines.yml`, `.buildkite/`, `buildspec.yml` (AWS CodeBuild) or `.harness/`.
2. Follow its guide from [CI Setup](https://docs.currents.dev/getting-started/ci-setup.md). For Jest and Vitest, use the CI Setup page under that framework.
3. Ask the user to store `CURRENTS_RECORD_KEY` as a CI secret and `CURRENTS_PROJECT_ID` as a CI variable or secret. Reference them by those names in the CI configuration.
4. If a guide's container image shows as an expression such as `space.vars.PW_IMAGE_ROUTE`, use `mcr.microsoft.com/playwright:v<version>-noble`, where `<version>` is the `@playwright/test` version in the repository.
5. After the user pushes the change, check that the CI log has the run link from step 3.

Secrets are not available to every job. In GitHub Actions, pull requests from forks get no secrets, so their runs don't reach Currents. [Missing Runs](https://docs.currents.dev/guides/missing-runs.md) lists the same limit for other providers.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.currents.dev/getting-started/setup-with-an-agent.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
