code-review

# Review procedure for mixpanel-headless `REVIEW.md` sets the priorities, the evidence a finding needs, the severity scale, and what not to comment on. This skill is the procedure to apply it. ## 1. Collect the context 1. Read the PR description. List the changed areas: library, CLI, tests, conformance, replays, specs, plugin, docs, workflows. 2. For each changed area, read its file in `.github/instructions/`. If that file names a folder guide (a `CLAUDE.md` in the folder), read the guide too. Not every area has one. 3. Read `REVIEW.md`. ## 2. Check each finding before you post it 1. Find the line that shows the behavior. Do not infer behavior from a name, a docstring, or a comment. 2. Where you can, prove the finding: - `uv run python -c "..."` for a small behavior check. - `uv run pytest <file>::<test> -q` for one focused test. The unit tests run offline with mocks. 3. Never run tests under `tests/live/`, and never pass `-m live`. Those tests call the real Mixpanel API, and some of them write data. 4. Do not run `just check` or the full test suite. CI runs them. 5. If you cannot support the finding with a line or a check, do not post it. ## 3. Check public API changes For a new or changed public method, type, CLI command or flag, or `MP_*` variable, compare the code with: - `uv run mp help <Name>`: the built-in reference must describe the new behavior. - `src/mixpanel_headless/__init__.py`: a new package-level name needs an export. - `CHANGELOG.md`: an entry under `## Unreleased`. - The matching page in `docs/guide/`. - For an `MP_*` variable: the environment variable table in `CLAUDE.md`. ## 4. Post - Give each finding a severity from `REVIEW.md`. - For a bug, state the input that fails and the wrong result. - Prefer one precise comment to several speculative ones. - If the PR is clean, say so.