github.com/ocaml/dune (link)

# Copilot Instructions

For full development guidance, see [AGENTS.md](../AGENTS.md).

## Common Commands

The setup workflow prepares Copilot's development environment. Run repository
commands directly:

```bash
dune build @check          # Quick build (recommended)
dune build @install        # Full build
dune runtest dir/          # Run tests in a directory
dune runtest dir/test.t    # Run a specific cram test
dune fmt                   # Auto-format code (run before committing)
dune promote              

@AGENTS.md

---
name: review-check
description: >-
  Review Dune commits, PRs, or working tree changes using the repository
  review checklist. Use when the user asks for review-check, review checklist,
  or a code review that should follow doc/dev/prompts/review-check.md.
---

Before reviewing, read `doc/dev/prompts/review-check.md` from the repository
root and follow it as the checklist.

Treat that file as authoritative. Do not duplicate the checklist here.

# Rules for Cram Tests

- Reuse helpers using setup scripts

- Utilities used inside of a test but are otherwise unrelated should be built
  outside of the test suite. See the `utils` directly for examples of such utilities

- To inspect direct output, lean towards using the trace using `$ dune trace cat`.

- Remove non-reproducible trace information using `$ jq`.

- Before adding new tests, search around the existing tests for duplicates and to find the best
  place to put this test.

- Do not use `--displ

# Changelog entries

Document every notable user-visible change with a changelog fragment. Do not
edit `CHANGES.md` directly. Add the fragment under the appropriate directory:

- `added/` for a new user-visible feature or behavior
- `changed/` for a change to existing user-visible behavior
- `fixed/` for a bug fix that restores the expected behavior
- `unreleased/` only in special cases; normally use one of the other categories

Skip implementation-only changes. Also skip non-notable changes even when they

# Tests

Read README.md for a description of the tests.

# Rules For Writing Tests

- Prefer blackbox tests written in cram over unit tests.

- For unit tests, prefer writing `[%expect{|..|}]` blocks over assertions

- Only write unit tests for parts of the code that does not require mocking

- Instead of adding a `For_tests` module, consider writing the test right in the
  library using ppx_expect.

- Rules may not contain OCaml stacktraces. Disable stack trace collection or
  filter out the stack trace fo

# AGENTS.md

This file provides guidance to AI agents (Claude Code, Codex, etc) when working with
the Dune codebase.

## General Rules

- Every commit must be pass the following check `$ dune build @check @fmt @runtest`.
  Commits that introduce a failing test should also pass this check even if the
  test introduces failure

- Unless otherwise stated, prefer to create commits for every logical change
  that you make. When in a `jj` repo, detected by the presence of `.jj/`, use
  the `jj` tool create commit