{"owner":"readthedocs","repo":"readthedocs.org","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AI Instructions for Read the Docs\n\nThis file lives in the `common` repo,\nand is copied to each produciton repo.\nAgents don't work with symlinks or submodules,\nso this is best for now.\n\n## Project Overview\n\nRead the Docs is a documentation hosting platform that builds and hosts documentation for open source projects.\nIt supports multiple documentation tools (Sphinx, MkDocs, etc.) and automatically builds documentation from Git repositories.\n\n**Technology Stack:**\n- Python 3.x\n- Django web framework\n- Docker and Docker Compose for development\n- PostgreSQL database\n- Elasticsearch for search\n- Redis for caching and Celery for background tasks\n\n## Commits\n\n* Use short descriptive commit messages\n* Only provide simple context, and don't be overly verbose\n* Always run `pre-commit run --files <changed files>` before committing to ensure code passes all checks\n\n## Pull Requests\n\n* Make the PR description maximum useful for humans, context first and most important.\n* Always open pull requests as drafts\n* Put a footer note that this was generated by the AI agent in use\n* Use feature branches for all changes\n* Don't include a \"Changes\" section, since the PR content is self-explanatory\n* Don't include Test Plan unless absolutely necessary.\n* Link related issues in the PR description, if there are any in the chat context\n* Prefix pull request titles, example `Api:`, `Builds:`, or `Docs:`.\n\n## Package Management\n\n- Always use `uv` for Python package management and virtual environment operations\n- Use `uv pip install` instead of `pip install`\n- Use `uv run` to execute Python scripts in the virtual environment\n\n## Docs\n\n* Follow the style guide at https://github.com/readthedocs/readthedocs.org/blob/main/docs/dev/style-guide.rst.\n* Always use the marketing name used in the public-facing docs, and not the internal code names referenced in code.\n* The ``user`` directory is public docs, and ``dev`` is dev-focused. Most of what we do is focus on the user-facing docs.\n\n## Website copy\n\n- Direct, second-person voice. No jargon. Less is more.\n- Focus on user benefit, not abstract positioning.\n- Don't repeat facts within a section; use standard terminology (e.g. \"files changed\", \"pull request\").\n\n## Testing\n\n- Use `pytest` as the testing framework\n- Use the `assert foo == bar` style for assertions\n- Write succinct, focused tests that test one thing at a time\n- Use descriptive test names that explain what is being tested\n- Place tests in appropriate test files following the project structure\n- Always keep the test db with ``pytest --reuse-db`` to speed up test runs\n\n### Running tests locally\n\nTests do **not** require Docker — they run via `tox` with SQLite and `readthedocs.settings.test`.\nDocker Compose is only for the development server.\n\n```bash\n# Validate migrations (run after any migration change)\ntox -e migrations\n\n# Run linting and formatting checks\ntox -e pre-commit\n\n# Run the main test suite (search, proxito, and embed_api tests are excluded by default)\ntox -e py312 -- --nomigrations\n\n# Run tests matching a keyword (faster) — use -k because --pyargs readthedocs is hardcoded\ntox -e py312 -- -k \"<keyword>\" --reuse-db --nomigrations\n\n# Run only search tests (requires Elasticsearch sidecar in CI, skip locally unless available)\ntox -e search\n```\n\n### Migration validation\n\nAlways run `tox -e migrations` after adding or modifying migration files. This runs\n`manage.py makemigrations --check --dry-run` and catches missing or inconsistent migrations\nbefore they cause `IntegrityError` failures at deploy time.\n\n## Code Quality\n\n- Follow PEP 8 style guidelines\n- Use Django conventions and best practices\n- Use type hints for function signatures\n- Write clear, concise docstrings for public functions and classes\n- Run linters and formatters using `tox -e pre-commit` before committing code\n\n## Front-end\n\n- Most templates/css/js are in a separate repository (https://github.com/readthedocs/ext-theme/).\n\n## Security\n\n- Follow Django security best practices\n- Be aware of OWASP top 10 vulnerabilities\n- Use Django's built-in security features (CSRF, XSS protection, etc.)\n"},"files":{"AGENTS.md":"# AI Instructions for Read the Docs\n\nThis file lives in the `common` repo,\nand is copied to each produciton repo.\nAgents don't work with symlinks or submodules,\nso this is best for now.\n\n## Project Overview\n\nRead the Docs is a documentation hosting platform that builds and hosts documentation for open source projects.\nIt supports multiple documentation tools (Sphinx, MkDocs, etc.) and automatically builds documentation from Git repositories.\n\n**Technology Stack:**\n- Python 3.x\n- Django web framework\n- Docker and Docker Compose for development\n- PostgreSQL database\n- Elasticsearch for search\n- Redis for caching and Celery for background tasks\n\n## Commits\n\n* Use short descriptive commit messages\n* Only provide simple context, and don't be overly verbose\n* Always run `pre-commit run --files <changed files>` before committing to ensure code passes all checks\n\n## Pull Requests\n\n* Make the PR description maximum useful for humans, context first and most important.\n* Always open pull requests as drafts\n* Put a footer note that this was generated by the AI agent in use\n* Use feature branches for all changes\n* Don't include a \"Changes\" section, since the PR content is self-explanatory\n* Don't include Test Plan unless absolutely necessary.\n* Link related issues in the PR description, if there are any in the chat context\n* Prefix pull request titles, example `Api:`, `Builds:`, or `Docs:`.\n\n## Package Management\n\n- Always use `uv` for Python package management and virtual environment operations\n- Use `uv pip install` instead of `pip install`\n- Use `uv run` to execute Python scripts in the virtual environment\n\n## Docs\n\n* Follow the style guide at https://github.com/readthedocs/readthedocs.org/blob/main/docs/dev/style-guide.rst.\n* Always use the marketing name used in the public-facing docs, and not the internal code names referenced in code.\n* The ``user`` directory is public docs, and ``dev`` is dev-focused. Most of what we do is focus on the user-facing docs.\n\n## Website copy\n\n- Direct, second-person voice. No jargon. Less is more.\n- Focus on user benefit, not abstract positioning.\n- Don't repeat facts within a section; use standard terminology (e.g. \"files changed\", \"pull request\").\n\n## Testing\n\n- Use `pytest` as the testing framework\n- Use the `assert foo == bar` style for assertions\n- Write succinct, focused tests that test one thing at a time\n- Use descriptive test names that explain what is being tested\n- Place tests in appropriate test files following the project structure\n- Always keep the test db with ``pytest --reuse-db`` to speed up test runs\n\n### Running tests locally\n\nTests do **not** require Docker — they run via `tox` with SQLite and `readthedocs.settings.test`.\nDocker Compose is only for the development server.\n\n```bash\n# Validate migrations (run after any migration change)\ntox -e migrations\n\n# Run linting and formatting checks\ntox -e pre-commit\n\n# Run the main test suite (search, proxito, and embed_api tests are excluded by default)\ntox -e py312 -- --nomigrations\n\n# Run tests matching a keyword (faster) — use -k because --pyargs readthedocs is hardcoded\ntox -e py312 -- -k \"<keyword>\" --reuse-db --nomigrations\n\n# Run only search tests (requires Elasticsearch sidecar in CI, skip locally unless available)\ntox -e search\n```\n\n### Migration validation\n\nAlways run `tox -e migrations` after adding or modifying migration files. This runs\n`manage.py makemigrations --check --dry-run` and catches missing or inconsistent migrations\nbefore they cause `IntegrityError` failures at deploy time.\n\n## Code Quality\n\n- Follow PEP 8 style guidelines\n- Use Django conventions and best practices\n- Use type hints for function signatures\n- Write clear, concise docstrings for public functions and classes\n- Run linters and formatters using `tox -e pre-commit` before committing code\n\n## Front-end\n\n- Most templates/css/js are in a separate repository (https://github.com/readthedocs/ext-theme/).\n\n## Security\n\n- Follow Django security best practices\n- Be aware of OWASP top 10 vulnerabilities\n- Use Django's built-in security features (CSRF, XSS protection, etc.)\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AI Instructions for Read the Docs\n\nThis file lives in the `common` repo,\nand is copied to each produciton repo.\nAgents don't work with symlinks or submodules,\nso this is best for now.\n\n## Project Overview\n\nRead the Docs is a documentation hosting platform that builds and hosts documentation for open source projects.\nIt supports multiple documentation tools (Sphinx, MkDocs, etc.) and automatically builds documentation from Git repositories.\n\n**Technology Stack:**\n- Python 3.x\n- Django web framework\n- Docker and Docker Compose for development\n- PostgreSQL database\n- Elasticsearch for search\n- Redis for caching and Celery for background tasks\n\n## Commits\n\n* Use short descriptive commit messages\n* Only provide simple context, and don't be overly verbose\n* Always run `pre-commit run --files <changed files>` before committing to ensure code passes all checks\n\n## Pull Requests\n\n* Make the PR description maximum useful for humans, context first and most important.\n* Always open pull requests as drafts\n* Put a footer note that this was generated by the AI agent in use\n* Use feature branches for all changes\n* Don't include a \"Changes\" section, since the PR content is self-explanatory\n* Don't include Test Plan unless absolutely necessary.\n* Link related issues in the PR description, if there are any in the chat context\n* Prefix pull request titles, example `Api:`, `Builds:`, or `Docs:`.\n\n## Package Management\n\n- Always use `uv` for Python package management and virtual environment operations\n- Use `uv pip install` instead of `pip install`\n- Use `uv run` to execute Python scripts in the virtual environment\n\n## Docs\n\n* Follow the style guide at https://github.com/readthedocs/readthedocs.org/blob/main/docs/dev/style-guide.rst.\n* Always use the marketing name used in the public-facing docs, and not the internal code names referenced in code.\n* The ``user`` directory is public docs, and ``dev`` is dev-focused. Most of what we do is focus on the user-facing docs.\n\n## Website copy\n\n- Direct, second-person voice. No jargon. Less is more.\n- Focus on user benefit, not abstract positioning.\n- Don't repeat facts within a section; use standard terminology (e.g. \"files changed\", \"pull request\").\n\n## Testing\n\n- Use `pytest` as the testing framework\n- Use the `assert foo == bar` style for assertions\n- Write succinct, focused tests that test one thing at a time\n- Use descriptive test names that explain what is being tested\n- Place tests in appropriate test files following the project structure\n- Always keep the test db with ``pytest --reuse-db`` to speed up test runs\n\n### Running tests locally\n\nTests do **not** require Docker — they run via `tox` with SQLite and `readthedocs.settings.test`.\nDocker Compose is only for the development server.\n\n```bash\n# Validate migrations (run after any migration change)\ntox -e migrations\n\n# Run linting and formatting checks\ntox -e pre-commit\n\n# Run the main test suite (search, proxito, and embed_api tests are excluded by default)\ntox -e py312 -- --nomigrations\n\n# Run tests matching a keyword (faster) — use -k because --pyargs readthedocs is hardcoded\ntox -e py312 -- -k \"<keyword>\" --reuse-db --nomigrations\n\n# Run only search tests (requires Elasticsearch sidecar in CI, skip locally unless available)\ntox -e search\n```\n\n### Migration validation\n\nAlways run `tox -e migrations` after adding or modifying migration files. This runs\n`manage.py makemigrations --check --dry-run` and catches missing or inconsistent migrations\nbefore they cause `IntegrityError` failures at deploy time.\n\n## Code Quality\n\n- Follow PEP 8 style guidelines\n- Use Django conventions and best practices\n- Use type hints for function signatures\n- Write clear, concise docstrings for public functions and classes\n- Run linters and formatters using `tox -e pre-commit` before committing code\n\n## Front-end\n\n- Most templates/css/js are in a separate repository (https://github.com/readthedocs/ext-theme/).\n\n## Security\n\n- Follow Django security best practices\n- Be aware of OWASP top 10 vulnerabilities\n- Use Django's built-in security features (CSRF, XSS protection, etc.)\n","category":"root","tokens":1028}]}