TestsSûr9494/100
Td Tox (Ansible)
Reference for running lint, test, build, and doc commands via tox. Agents MUST use tox for all quality gates — never invoke pytest, ruff, mypy, prek, or shell scripts directly. This skill is the canonical lookup table for which tox environment to use.
ou envoie-le directement à ton agent.
Installer dans ton projet
$ curl -fsSL https://arboristhree.xyz/cli/install-skill.mjs -o /tmp/arboris-install-skill.mjs && node /tmp/arboris-install-skill.mjs td-tox__ansible-team-devtools__agents-skills-33336ff809cbAnsible
ansible/team-devtools
Contenu à copier
--- name: td-tox description: > Reference for running lint, test, build, and doc commands via tox. Agents MUST use tox for all quality gates — never invoke pytest, ruff, mypy, prek, or shell scripts directly. This skill is the canonical lookup table for which tox environment to use. argument-hint: "[environment-name]" user-invocable: true metadata: origin: Ansible author: Ansible DevTools Team version: 1.0.0 --- > **[Team DevTools]** Running `td-tox` — from [ansible/team-devtools](https://github.com/ansible/team-devtools/tree/main/.agents/skills/td-tox) Print the line above verbatim as the first output when this skill is invoked. # tox — Sole Developer & Agent Orchestration Tool ## Usage ```text /td-tox # Show full environment reference /td-tox lint # How to run lint /td-tox py # How to run tests /td-tox docs # How to build docs /td-tox <env> # Lookup any tox environment ``` tox is the **only** way to run lint, test, build, and doc commands in this project. Do not invoke `pytest`, `ruff`, `mypy`, `prek`, or shell scripts directly. Every task maps to a `tox -e <env>` command. ## Hard Rules 1. **Never run `pytest` directly.** Use `tox -e py`. 2. **Never run `ruff`, `mypy`, or `prek` directly.** Use `tox -e lint`. 3. **Pass extra arguments after `--`.** Example: `tox -e py -- -k test_example`. 4. **In CI, use `uvx --with tox-uv tox -e <env>`** instead of installing tox. ## Environment Reference ### Quality gates | Environment | What it runs | When to use | |-------------|-------------|-------------| | `tox -e lint` | `prek run --all-files` (ruff, mypy, biome, tombi, codespell, ansible-lint) | Before every commit. Verification step for all tasks. | ### Test suites | Environment | What it runs | When to use | |-------------|-------------|-------------| | `tox -e py` | `pytest` with coverage (threshold varies per repo) | After any code change. | | `tox -e py -- -k <pattern>` | Single test or test pattern | Debugging a specific test. | | `tox -e py -- --no-cov` | Tests without coverage overhead | Quick iteration. | | `tox -e devel` | Tests with newest deps (no lock, prereleases allowed) | Verifying forward compatibility. | ### Documentation | Environment | What it runs | When to use | |-------------|-------------|-------------| | `tox -e docs` | `mkdocs build --strict` | After doc changes. | ### Packaging | Environment | What it runs | When to use | |-------------|-------------|-------------| | `tox -e pkg` | `python -m build` + `twine check --strict` | Before release. Verify package metadata. | ### Dependency management | Environment | What it runs | When to use | |-------------|-------------|-------------| | `tox -e deps` | `prek run deps` + `prek autoupdate` + `tox -e lint` | Bumping all dependencies. | ### Default set Running `tox` with no `-e` flag executes the default environment list defined in the repo's `pyproject.toml` or `tox.ini`. This is the full quality gate. **Note:** Not all environments listed above are available in every repo. Run `tox l` to discover the environments available in the current repository. ## Common Agent Workflows ### "I changed Python code, what do I run?" ```bash tox -e lint # check style + types tox -e py # run tests ``` ### "I changed documentation" ```bash tox -e docs # build and verify docs ``` ### "I need to run one specific test" ```bash tox -e py -- -k test_example tox -e py -- test/test_example.py::test_specific_function ``` ### "I want to verify everything before a PR" ```bash tox -e lint tox -e py ``` ### "List all available environments" ```bash tox l ``` ## Installation ```bash uv tool install tox --with tox-uv ``` ## Configuration Tox configuration typically lives in `pyproject.toml` under `[tool.tox]` or in a standalone `tox.ini`. Environment definitions, extras, pass-through env vars, and commands are all there. Do not scatter test/lint invocations across Makefiles, scripts, or workflow YAML.
Colle ce Markdown dans ton agent ou utilise les boutons ci-dessus pour l’écrire dans ton projet.
Ce que fait Td Tox (Ansible)
Applique les pratiques du skill td-tox__ansible-team-devtools__agents-skills-33336ff809cb.
Comment utiliser Td Tox (Ansible)
1
Copie le prompt
Un clic copie le prompt packagé (ou l'envoie à ton agent).
2
L'agent installe le skill
Il ajoute le SKILL.md et ses ressources à ton projet.
3
Activation automatique
Le skill s'active dès que le contexte correspond.
Déclencheurs pour Td Tox (Ansible)
Dis simplement à ton agent quelque chose comme :
Applique le skill td-tox__ansible-team-devtools__agents-skills-33336ff809cb à cette tâche
Utilise td-tox__ansible-team-devtools__agents-skills-33336ff809cb pour améliorer cette implémentation
Passe en revue ce sujet avec td-tox__ansible-team-devtools__agents-skills-33336ff809cb
Skills liés à Td Tox (Ansible)
Add New Op (Alibaba)
为 MNN 框架新增算子。包含 Schema 定义、形状计算、几何计算、后端实现、单元测试的完整 TDD 流程。分 5 步执行,每步有独立测试标准。ai-regression-testing
Regression testing strategies for AI-assisted development. Sandbox-mode API testing without database dependencies, automated bug-check workflows, and patterns to catch AI blind spots where the same model writes and reviews code. Use when adding regression coverage to AI-assisted code, or when the same model both wrote and reviewed a change.Analyze Test Report (PyTorch)
Analyze torch-tensorrt local test results and drive failures to a fix. Use when the user pastes a test report / summary, asks why tests failed, asks to triage or fix failing tests, or mentions the JUnit/test-summary output from `just tests-report` / `just test-summary`. Covers where the JUnit XMLs live, how to read the consolidated report, how to reproduce a single failure, and how to categorize (real bug vs torch-API change vs OOM/skip vs flake).