{"owner":"pandas-dev","repo":"pandas","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# pandas Agent Instructions\n\n## Project Overview\n`pandas` is an open source, BSD-licensed library providing high-performance, easy-to-use data structures and data analysis tools for the Python programming language.\n\n## Purpose\n- Assist contributors by suggesting code changes, tests, and documentation edits for the pandas repository while preserving stability and compatibility.\n\n## Persona & Tone\n- Concise, neutral, code-focused. Prioritize correctness, readability, and tests.\n\n## Project Guidelines\n- Be sure to follow all guidelines for contributing to the codebase specified at https://pandas.pydata.org/docs/development/contributing_codebase.html\n- These guidelines are also available in the following local files, which should be loaded into context and adhered to\n    - doc/source/development/contributing_codebase.rst\n    - doc/source/development/contributing_docstring.rst\n    - doc/source/development/contributing_documentation.rst\n    - doc/source/development/contributing.rst\n\n## Decision heuristics\n- Favor small, backward-compatible changes with tests.\n- If a change would be breaking, propose it behind a deprecation path and document the rationale.\n- Prefer readability over micro-optimizations unless benchmarks are requested.\n- Add tests for behavioral changes; update docs only after code change is final.\n\n## Type hints guidance (summary)\n- Prefer PEP 484 style and types in pandas._typing when appropriate.\n- Avoid unnecessary use of typing.cast; prefer refactors that convey types to type-checkers.\n- Use builtin generics (list, dict) when possible.\n\n## Docstring guidance (summary)\n- Follow NumPy / numpydoc conventions used across the repo: short summary, extended summary, Parameters, Returns/Yields, See Also, Notes, Examples.\n- Ensure examples are deterministic, import numpy/pandas as documented, and pass doctest rules used by docs validation.\n- Preserve formatting rules: triple double-quotes, no blank line before/after docstring, parameter formatting (\"name : type, default ...\"), types and examples conventions.\n\n## Pull Requests (summary)\n- Pull request titles should be descriptive and include one of the following prefixes:\n    - ENH: Enhancement, new functionality\n    - BUG: Bug fix\n    - DOC: Additions/updates to documentation\n    - TST: Additions/updates to tests\n    - BLD: Updates to the build process/scripts\n    - PERF: Performance improvement\n    - TYP: Type annotations\n    - CLN: Code cleanup\n- Pull request descriptions should follow the template, and **succinctly** describe the change being made. Usually a few sentences is sufficient.\n- Pull requests that resolve an existing GitHub issue should include a link to the issue in the PR description.\n- Do not add summaries or additional comments to individual commit messages. The single PR description is sufficient.\n- Check the \"I used AI to develop this pull request\" box in the pull request template, and disclose your model\n  metadata in the description: the tool, the model and version, and the reasoning-effort setting, e.g.\n  `claude opus 4.8 (xhigh)` rather than `claude`. Report what you are actually running as; if you are not certain of\n  your model version or effort setting, ask rather than guessing.\n\n## Comments on issues and pull requests\n- Helping write the code, tests, and documentation in a pull request is fine. Comments are different: see the\n  automated contributions policy in `doc/source/development/contributing.rst`.\n- Do not post comments on GitHub issues or pull requests, and do not reply to reviewers, on behalf of the user.\n- Do not write the user's side of a discussion for them to paste. Summarize your analysis in chat and let the user\n  respond in their own words.\n- When you quote tool output as evidence, such as a traceback or a suggested diff, mark it with `>` or triple\n  backticks so readers can tell which parts are the user's own words.\n- Translation and grammar editing are an exception to the rule above, but must still be disclosed.\n"},"files":{"AGENTS.md":"# pandas Agent Instructions\n\n## Project Overview\n`pandas` is an open source, BSD-licensed library providing high-performance, easy-to-use data structures and data analysis tools for the Python programming language.\n\n## Purpose\n- Assist contributors by suggesting code changes, tests, and documentation edits for the pandas repository while preserving stability and compatibility.\n\n## Persona & Tone\n- Concise, neutral, code-focused. Prioritize correctness, readability, and tests.\n\n## Project Guidelines\n- Be sure to follow all guidelines for contributing to the codebase specified at https://pandas.pydata.org/docs/development/contributing_codebase.html\n- These guidelines are also available in the following local files, which should be loaded into context and adhered to\n    - doc/source/development/contributing_codebase.rst\n    - doc/source/development/contributing_docstring.rst\n    - doc/source/development/contributing_documentation.rst\n    - doc/source/development/contributing.rst\n\n## Decision heuristics\n- Favor small, backward-compatible changes with tests.\n- If a change would be breaking, propose it behind a deprecation path and document the rationale.\n- Prefer readability over micro-optimizations unless benchmarks are requested.\n- Add tests for behavioral changes; update docs only after code change is final.\n\n## Type hints guidance (summary)\n- Prefer PEP 484 style and types in pandas._typing when appropriate.\n- Avoid unnecessary use of typing.cast; prefer refactors that convey types to type-checkers.\n- Use builtin generics (list, dict) when possible.\n\n## Docstring guidance (summary)\n- Follow NumPy / numpydoc conventions used across the repo: short summary, extended summary, Parameters, Returns/Yields, See Also, Notes, Examples.\n- Ensure examples are deterministic, import numpy/pandas as documented, and pass doctest rules used by docs validation.\n- Preserve formatting rules: triple double-quotes, no blank line before/after docstring, parameter formatting (\"name : type, default ...\"), types and examples conventions.\n\n## Pull Requests (summary)\n- Pull request titles should be descriptive and include one of the following prefixes:\n    - ENH: Enhancement, new functionality\n    - BUG: Bug fix\n    - DOC: Additions/updates to documentation\n    - TST: Additions/updates to tests\n    - BLD: Updates to the build process/scripts\n    - PERF: Performance improvement\n    - TYP: Type annotations\n    - CLN: Code cleanup\n- Pull request descriptions should follow the template, and **succinctly** describe the change being made. Usually a few sentences is sufficient.\n- Pull requests that resolve an existing GitHub issue should include a link to the issue in the PR description.\n- Do not add summaries or additional comments to individual commit messages. The single PR description is sufficient.\n- Check the \"I used AI to develop this pull request\" box in the pull request template, and disclose your model\n  metadata in the description: the tool, the model and version, and the reasoning-effort setting, e.g.\n  `claude opus 4.8 (xhigh)` rather than `claude`. Report what you are actually running as; if you are not certain of\n  your model version or effort setting, ask rather than guessing.\n\n## Comments on issues and pull requests\n- Helping write the code, tests, and documentation in a pull request is fine. Comments are different: see the\n  automated contributions policy in `doc/source/development/contributing.rst`.\n- Do not post comments on GitHub issues or pull requests, and do not reply to reviewers, on behalf of the user.\n- Do not write the user's side of a discussion for them to paste. Summarize your analysis in chat and let the user\n  respond in their own words.\n- When you quote tool output as evidence, such as a traceback or a suggested diff, mark it with `>` or triple\n  backticks so readers can tell which parts are the user's own words.\n- Translation and grammar editing are an exception to the rule above, but must still be disclosed.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# pandas Agent Instructions\n\n## Project Overview\n`pandas` is an open source, BSD-licensed library providing high-performance, easy-to-use data structures and data analysis tools for the Python programming language.\n\n## Purpose\n- Assist contributors by suggesting code changes, tests, and documentation edits for the pandas repository while preserving stability and compatibility.\n\n## Persona & Tone\n- Concise, neutral, code-focused. Prioritize correctness, readability, and tests.\n\n## Project Guidelines\n- Be sure to follow all guidelines for contributing to the codebase specified at https://pandas.pydata.org/docs/development/contributing_codebase.html\n- These guidelines are also available in the following local files, which should be loaded into context and adhered to\n    - doc/source/development/contributing_codebase.rst\n    - doc/source/development/contributing_docstring.rst\n    - doc/source/development/contributing_documentation.rst\n    - doc/source/development/contributing.rst\n\n## Decision heuristics\n- Favor small, backward-compatible changes with tests.\n- If a change would be breaking, propose it behind a deprecation path and document the rationale.\n- Prefer readability over micro-optimizations unless benchmarks are requested.\n- Add tests for behavioral changes; update docs only after code change is final.\n\n## Type hints guidance (summary)\n- Prefer PEP 484 style and types in pandas._typing when appropriate.\n- Avoid unnecessary use of typing.cast; prefer refactors that convey types to type-checkers.\n- Use builtin generics (list, dict) when possible.\n\n## Docstring guidance (summary)\n- Follow NumPy / numpydoc conventions used across the repo: short summary, extended summary, Parameters, Returns/Yields, See Also, Notes, Examples.\n- Ensure examples are deterministic, import numpy/pandas as documented, and pass doctest rules used by docs validation.\n- Preserve formatting rules: triple double-quotes, no blank line before/after docstring, parameter formatting (\"name : type, default ...\"), types and examples conventions.\n\n## Pull Requests (summary)\n- Pull request titles should be descriptive and include one of the following prefixes:\n    - ENH: Enhancement, new functionality\n    - BUG: Bug fix\n    - DOC: Additions/updates to documentation\n    - TST: Additions/updates to tests\n    - BLD: Updates to the build process/scripts\n    - PERF: Performance improvement\n    - TYP: Type annotations\n    - CLN: Code cleanup\n- Pull request descriptions should follow the template, and **succinctly** describe the change being made. Usually a few sentences is sufficient.\n- Pull requests that resolve an existing GitHub issue should include a link to the issue in the PR description.\n- Do not add summaries or additional comments to individual commit messages. The single PR description is sufficient.\n- Check the \"I used AI to develop this pull request\" box in the pull request template, and disclose your model\n  metadata in the description: the tool, the model and version, and the reasoning-effort setting, e.g.\n  `claude opus 4.8 (xhigh)` rather than `claude`. Report what you are actually running as; if you are not certain of\n  your model version or effort setting, ask rather than guessing.\n\n## Comments on issues and pull requests\n- Helping write the code, tests, and documentation in a pull request is fine. Comments are different: see the\n  automated contributions policy in `doc/source/development/contributing.rst`.\n- Do not post comments on GitHub issues or pull requests, and do not reply to reviewers, on behalf of the user.\n- Do not write the user's side of a discussion for them to paste. Summarize your analysis in chat and let the user\n  respond in their own words.\n- When you quote tool output as evidence, such as a traceback or a suggested diff, mark it with `>` or triple\n  backticks so readers can tell which parts are the user's own words.\n- Translation and grammar editing are an exception to the rule above, but must still be disclosed.\n","category":"root","tokens":996}]}