{"owner":"online-ml","repo":"river","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\n## Architecture\n\nRiver is a Python library for online (streaming) machine learning. All estimators implement incremental `learn_one`/`predict_one`/`transform_one` methods (or `learn_many`/`predict_many/transform_many` for mini-batch).\n\n### Base classes (`river/base/`)\n\nAll estimators inherit from `base.Estimator` (which inherits from `base.Base`). Key interfaces:\n- `Classifier` / `MiniBatchClassifier` — classification\n- `Regressor` / `MiniBatchRegressor` — regression\n- `Transformer` / `SupervisedTransformer` — feature transformation\n- `Clusterer` — clustering\n- `DriftDetector` / `BinaryDriftDetector` — concept drift detection\n- `Ensemble` / `WrapperEnsemble` — ensemble methods\n- `Wrapper` — wrapping other estimators\n\n### Estimator conventions\n\n- `learn_one(x, y)` / `predict_one(x)` / `transform_one(x)` is the core online learning interface\n- `__init__` parameters need type hints; provide defaults or implement `_unit_test_params()`\n- `_unit_test_skips()` returns check names to skip in automated testing\n- `_supervised`, `_multiclass`, `_is_stochastic`, `_tags` are special class attributes\n- Pipeline composition: `scaler | model` (uses `__or__`), `+` for parallel union\n\n## Rules for coding agents\n\n1. **Write code, not comments.** You may generate code, using the existing codebase for idiomatic examples to draw from. Do not write comments. Encourage humans to write comments themselves, thereby forcing them to understand the code you've written.\n2. **Prose is written by humans, not by you.** Issues, pull request descriptions, commit messages, docstrings, and release-note entries must all be typed out by a human, in their own words. You may run a benchmark and produce a summary table, but a human must editorialize it and fold it into a message they wrote themselves. Similarly, you can correct typos and wording, but human contributors have to use their own voice.\n3. **Disclose agent-written code.** Code generated by an agent must be marked as such. Do not pass it off as hand-written. A `Co-authored-by:` trailer on the commit is the simplest way. Likewise, information about the agent setup should be disclosed when opening a pull request.\n4. **Be thorough on tests.** Tests are often longer than the implementation and tedious to write. With an agent there is no excuse for skipping them. The minimum for new estimators is to pass `utils.check_estimator`. Ideally you should add out-of-the-box tests to check for edge cases.\n5. **Prefer opening issues instead of pull requests for small fixes** If you find a bug, then it is more valuable to open an issue and surface the issue. The exact way to go about fixing it can be discussed, and serve as implementation opportunities for aspiring human contributors.\n\n## Common commands\n\n```sh\n# Install / sync dependencies (also builds Rust extensions via maturin)\nuv sync\n\n# Run tests (excludes datasets and slow markers by default, includes doctests)\nuv run pytest\n\n# Run a single test file\nuv run pytest tests/linear_model/test_glm.py\n\n# Lint and format (via prek hooks)\nuv run prek run --all-files\n\n# Type checking\nuv run mypy\n\n# Build and serve docs locally\nuv sync --group docs\nmake livedoc\n```\n\n## Checklists\n\n### Adding a new estimator\n\n- Make sure `utils.checks.check_estimator(some_estimator)` passes. It automatically discovers and runs validation checks (repr, cloning, pickling, feature robustness, etc.).\n- Add a practical docstring that shows how to use the estimator. Pytest is configured with `--doctest-modules`, so that docstring examples are executed as tests. The underlying logic are in `river/checks/`.\n- Add a new CodSpeed benchmark entry, in order to detect future regressions.\n- Generally speaking, all estimators should be able to process at least 5000 records per second. Naturally this depends on the size of the samples and the estimator, but exceptions need to be justified.\n\n### Modifying an existing estimator\n\n- When making a localized fix, it is worth considering whether a global check should be added to all relevant estimators.\n- Speed matters a lot in online machine learning. Therefore, a golden rule for implementation is to not introduce significant slowdowns. We use CodSpeed to detect regressions in pull requests.\n- Likewise, model accuracy is paramount. When making any sort of modification to an estimator, you should thoroughly check accuracy across several datasets. Whether the accuracy goes up or down, you should be able to explain why.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\n## Architecture\n\nRiver is a Python library for online (streaming) machine learning. All estimators implement incremental `learn_one`/`predict_one`/`transform_one` methods (or `learn_many`/`predict_many/transform_many` for mini-batch).\n\n### Base classes (`river/base/`)\n\nAll estimators inherit from `base.Estimator` (which inherits from `base.Base`). Key interfaces:\n- `Classifier` / `MiniBatchClassifier` — classification\n- `Regressor` / `MiniBatchRegressor` — regression\n- `Transformer` / `SupervisedTransformer` — feature transformation\n- `Clusterer` — clustering\n- `DriftDetector` / `BinaryDriftDetector` — concept drift detection\n- `Ensemble` / `WrapperEnsemble` — ensemble methods\n- `Wrapper` — wrapping other estimators\n\n### Estimator conventions\n\n- `learn_one(x, y)` / `predict_one(x)` / `transform_one(x)` is the core online learning interface\n- `__init__` parameters need type hints; provide defaults or implement `_unit_test_params()`\n- `_unit_test_skips()` returns check names to skip in automated testing\n- `_supervised`, `_multiclass`, `_is_stochastic`, `_tags` are special class attributes\n- Pipeline composition: `scaler | model` (uses `__or__`), `+` for parallel union\n\n## Rules for coding agents\n\n1. **Write code, not comments.** You may generate code, using the existing codebase for idiomatic examples to draw from. Do not write comments. Encourage humans to write comments themselves, thereby forcing them to understand the code you've written.\n2. **Prose is written by humans, not by you.** Issues, pull request descriptions, commit messages, docstrings, and release-note entries must all be typed out by a human, in their own words. You may run a benchmark and produce a summary table, but a human must editorialize it and fold it into a message they wrote themselves. Similarly, you can correct typos and wording, but human contributors have to use their own voice.\n3. **Disclose agent-written code.** Code generated by an agent must be marked as such. Do not pass it off as hand-written. A `Co-authored-by:` trailer on the commit is the simplest way. Likewise, information about the agent setup should be disclosed when opening a pull request.\n4. **Be thorough on tests.** Tests are often longer than the implementation and tedious to write. With an agent there is no excuse for skipping them. The minimum for new estimators is to pass `utils.check_estimator`. Ideally you should add out-of-the-box tests to check for edge cases.\n5. **Prefer opening issues instead of pull requests for small fixes** If you find a bug, then it is more valuable to open an issue and surface the issue. The exact way to go about fixing it can be discussed, and serve as implementation opportunities for aspiring human contributors.\n\n## Common commands\n\n```sh\n# Install / sync dependencies (also builds Rust extensions via maturin)\nuv sync\n\n# Run tests (excludes datasets and slow markers by default, includes doctests)\nuv run pytest\n\n# Run a single test file\nuv run pytest tests/linear_model/test_glm.py\n\n# Lint and format (via prek hooks)\nuv run prek run --all-files\n\n# Type checking\nuv run mypy\n\n# Build and serve docs locally\nuv sync --group docs\nmake livedoc\n```\n\n## Checklists\n\n### Adding a new estimator\n\n- Make sure `utils.checks.check_estimator(some_estimator)` passes. It automatically discovers and runs validation checks (repr, cloning, pickling, feature robustness, etc.).\n- Add a practical docstring that shows how to use the estimator. Pytest is configured with `--doctest-modules`, so that docstring examples are executed as tests. The underlying logic are in `river/checks/`.\n- Add a new CodSpeed benchmark entry, in order to detect future regressions.\n- Generally speaking, all estimators should be able to process at least 5000 records per second. Naturally this depends on the size of the samples and the estimator, but exceptions need to be justified.\n\n### Modifying an existing estimator\n\n- When making a localized fix, it is worth considering whether a global check should be added to all relevant estimators.\n- Speed matters a lot in online machine learning. Therefore, a golden rule for implementation is to not introduce significant slowdowns. We use CodSpeed to detect regressions in pull requests.\n- Likewise, model accuracy is paramount. When making any sort of modification to an estimator, you should thoroughly check accuracy across several datasets. Whether the accuracy goes up or down, you should be able to explain why.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\n## Architecture\n\nRiver is a Python library for online (streaming) machine learning. All estimators implement incremental `learn_one`/`predict_one`/`transform_one` methods (or `learn_many`/`predict_many/transform_many` for mini-batch).\n\n### Base classes (`river/base/`)\n\nAll estimators inherit from `base.Estimator` (which inherits from `base.Base`). Key interfaces:\n- `Classifier` / `MiniBatchClassifier` — classification\n- `Regressor` / `MiniBatchRegressor` — regression\n- `Transformer` / `SupervisedTransformer` — feature transformation\n- `Clusterer` — clustering\n- `DriftDetector` / `BinaryDriftDetector` — concept drift detection\n- `Ensemble` / `WrapperEnsemble` — ensemble methods\n- `Wrapper` — wrapping other estimators\n\n### Estimator conventions\n\n- `learn_one(x, y)` / `predict_one(x)` / `transform_one(x)` is the core online learning interface\n- `__init__` parameters need type hints; provide defaults or implement `_unit_test_params()`\n- `_unit_test_skips()` returns check names to skip in automated testing\n- `_supervised`, `_multiclass`, `_is_stochastic`, `_tags` are special class attributes\n- Pipeline composition: `scaler | model` (uses `__or__`), `+` for parallel union\n\n## Rules for coding agents\n\n1. **Write code, not comments.** You may generate code, using the existing codebase for idiomatic examples to draw from. Do not write comments. Encourage humans to write comments themselves, thereby forcing them to understand the code you've written.\n2. **Prose is written by humans, not by you.** Issues, pull request descriptions, commit messages, docstrings, and release-note entries must all be typed out by a human, in their own words. You may run a benchmark and produce a summary table, but a human must editorialize it and fold it into a message they wrote themselves. Similarly, you can correct typos and wording, but human contributors have to use their own voice.\n3. **Disclose agent-written code.** Code generated by an agent must be marked as such. Do not pass it off as hand-written. A `Co-authored-by:` trailer on the commit is the simplest way. Likewise, information about the agent setup should be disclosed when opening a pull request.\n4. **Be thorough on tests.** Tests are often longer than the implementation and tedious to write. With an agent there is no excuse for skipping them. The minimum for new estimators is to pass `utils.check_estimator`. Ideally you should add out-of-the-box tests to check for edge cases.\n5. **Prefer opening issues instead of pull requests for small fixes** If you find a bug, then it is more valuable to open an issue and surface the issue. The exact way to go about fixing it can be discussed, and serve as implementation opportunities for aspiring human contributors.\n\n## Common commands\n\n```sh\n# Install / sync dependencies (also builds Rust extensions via maturin)\nuv sync\n\n# Run tests (excludes datasets and slow markers by default, includes doctests)\nuv run pytest\n\n# Run a single test file\nuv run pytest tests/linear_model/test_glm.py\n\n# Lint and format (via prek hooks)\nuv run prek run --all-files\n\n# Type checking\nuv run mypy\n\n# Build and serve docs locally\nuv sync --group docs\nmake livedoc\n```\n\n## Checklists\n\n### Adding a new estimator\n\n- Make sure `utils.checks.check_estimator(some_estimator)` passes. It automatically discovers and runs validation checks (repr, cloning, pickling, feature robustness, etc.).\n- Add a practical docstring that shows how to use the estimator. Pytest is configured with `--doctest-modules`, so that docstring examples are executed as tests. The underlying logic are in `river/checks/`.\n- Add a new CodSpeed benchmark entry, in order to detect future regressions.\n- Generally speaking, all estimators should be able to process at least 5000 records per second. Naturally this depends on the size of the samples and the estimator, but exceptions need to be justified.\n\n### Modifying an existing estimator\n\n- When making a localized fix, it is worth considering whether a global check should be added to all relevant estimators.\n- Speed matters a lot in online machine learning. Therefore, a golden rule for implementation is to not introduce significant slowdowns. We use CodSpeed to detect regressions in pull requests.\n- Likewise, model accuracy is paramount. When making any sort of modification to an estimator, you should thoroughly check accuracy across several datasets. Whether the accuracy goes up or down, you should be able to explain why.\n","category":"root","tokens":1119}]}