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

# Coding agents

> Let a coding agent configure Archal while keeping your harness, evaluator, and application architecture intact.

Archal is designed to be set up and operated by the coding agent already
working in your repository. The agent drives the process, but the human still
chooses the test boundary and approves destructive state changes.

## Pair once

Open **Dashboard > Setup**, choose the coding-agent target, and paste the
generated prompt into Claude Code, Codex, Cursor, or Windsurf.

The prompt connects the CLI and installs five repository-local skills:

| Skill             | Responsibility                                                      |
| ----------------- | ------------------------------------------------------------------- |
| `archal-setup`    | Pair, install, verify, and stop before application changes          |
| `archal-session`  | Discover environments and control sandbox lifecycle                 |
| `archal-state`    | Inspect, validate, load, diff, and reset explicit state             |
| `archal-ci`       | Fit Archal into an existing test or CI workflow                     |
| `archal-diagnose` | Isolate auth, fidelity, state, routing, usage, and cleanup failures |

Checksums must pass for all five. A successful setup ends with `Archal is
connected and ready`.

## Let the agent inspect before it edits

A good first request gives the coding agent a real workflow, not a vague goal:

```text theme={null}
Inspect our existing Slack and Datadog clients and the integration tests that
exercise them. Show me the matching Archal environments and five starting
states for each. Propose the smallest disposable sandbox that proves one real
workflow. Keep our current test runner and observability provider.
```

The coding agent should discover:

* where provider base URLs and credentials enter the application
* which tests need stateful behavior
* which environment operations are actually supported
* whether a curated sample already matches the test
* the smallest safe code and configuration change

## Authority boundaries

The protected Archal credential controls sandbox lifecycle. Do not put it in a
prompt or expose it to the agent under test. The code being tested receives
only the short-lived provider credentials returned for its environments.

State reads and validation are safe discovery operations. Loading or resetting
state overwrites data. The `archal-state` skill requires explicit approval for
the named sandbox, environment, and artifact unless the user deliberately
configured a newly created disposable CI sandbox.

## Archal does not own the harness

Keep Braintrust, LangSmith, custom graders, traces, and test runners in place.
Archal provides stateful provider environments. Your coding agent connects
those environments to the harness you already trust.

## Adding CI

The setup skill never edits CI. After one useful manual proof, ask the agent to
prepare a CI plan that names the files, triggers, environments, sample hashes,
TTL, parallelism, secret boundary, cleanup behavior, and maximum expected cost.

Review that plan before allowing the agent to edit a workflow. See [CI and test
suites](/integrations/ci) for the current safety requirements and product limits.