agentleFS
maksimzayatsmaksimzayats/diwire/AGENTS.md

diwire

AGENTS.md254 starsChanged 18 days agoMITView on GitHub

This repository is a Python 3.10+ library. Use strict linting, typing, and testing standards. Prefer uv for all tooling and keep changes compatible with the current public API. - Run all tests (coverage): make test - Run a single test file: uv run pytest tests/unit/internal/test_container.py - Run a single test: uv run pytest tests/unit/internal/test_container.py::test_register - Run tests with keyword filter: uv run pytest -k "dependency" tests/ - Coverage (recommended for new work): uv run pytest tests/ --benchmark-skip --cov=src/diwire --cov-report=term-missing -…

  • Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.

    Of the AGENTS.md files we read, the 31,439 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

  • In this repositoryOne other file it gives its agents.

The file

Show its rules and text

We split this AGENTS.md into the rules it gives an agent

34 rules. About 0 are common, 19 are distinctive, and 15 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈19

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 15

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always keep linting and type-checking clean.

    line 21
  2. Very specific:

    Run all tests (coverage): make test

    line 29
  3. Very specific:

    Run a single test file: uv run pytest tests/unit/internal/test_container.py

    line 30
  4. Very specific:

    Run a single test: uv run pytest tests/unit/internal/test_container.py::test_register

    line 31
  5. Very specific:

    Run tests with keyword filter: uv run pytest -k "dependency" tests/

    line 32
  6. Distinctive:

    Do not edit that region by hand.

    line 50
  7. Distinctive:

    Use ASCII unless the file already contains non-ASCII characters.

    line 59
  8. Distinctive:

    No relative imports in library code (Ruff tidy-imports bans them).

    line 63
  9. Very specific:

    Prefer explicit imports from diwire modules.

    line 64
  10. Very specific:

    Avoid unused imports; __init__.py is allowed to re-export.

    line 66
  11. Distinctive:

    All new public APIs must be fully typed.

    line 71
  12. Very specific:

    If Any is unavoidable, document why and keep scope minimal.

    line 73
  13. Very specific:

    Use typing.Protocol or collections.abc for public contracts.

    line 74
  14. Very specific:

    Prefer Final for constants that should not change.

    line 75
  15. Distinctive:

    Test names should describe the behavior and expectation.

    line 83
  16. Distinctive:

    Prefer explicit error messages over implicit failures.

    line 88
  17. Very specific:

    Avoid catching Exception unless re-raising with context.

    line 89
  18. Distinctive:

    When adding new errors, update tests and docs/examples as needed.

    line 90
  19. Very specific:

    Write README.md for library users who need to choose, install, and use diwire.

    line 100
  20. Distinctive:

    Keep its introduction focused on the library's purpose and user benefits.

    line 101
  21. Distinctive:

    Put CI setup, dependency workarounds, coverage exclusions, test commands, and agent workflow details in contributor documentation or PR …

    line 102
  22. Distinctive:

    Add compatibility limits only when they affect library users.

    line 104
  23. Very specific:

    Use pytest fixtures from tests/conftest.py for shared setup.

    line 112
  24. Distinctive:

    Prefer small, focused tests over large integration tests.

    line 113
  25. Distinctive:

    Keep tests deterministic; avoid time-based assertions unless necessary.

    line 114
  26. Distinctive:

    Always ensure linting and type-checking run clean with no errors.

    line 124
  27. Distinctive:

    Every new change must preserve 100% test coverage.

    line 125
  28. Very specific:

    After making changes, always run make lint and make test and report results.

    line 126
  29. Distinctive:

    Do not add new lint ignores without justification.

    line 138
  30. Distinctive:

    Keep public API backward compatible unless explicitly requested.

    line 139
  31. Distinctive:

    Avoid adding new dependencies unless required for functionality.

    line 141
  32. Distinctive:

    Update or add tests whenever behavior changes.

    line 142
  33. Very specific:

    No Cursor rules found (.cursor/rules/ or .cursorrules).

    line 146
  34. Very specific:

    No GitHub Copilot instructions found (.github/copilot-instructions.md).

    line 147

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

Agent Notes for diwire

This repository is a Python 3.10+ library. Use strict linting, typing, and testing standards. Prefer uv for all tooling and keep changes compatible with the current public API.

Quick commands

  • Install deps (dev): uv sync --group dev
  • Format: make format
  • Lint (all): make lint
  • Test (all): make test

Build

  • Build wheel/sdist: uv build
  • Clean build artifacts manually if needed (no scripted clean target)

Lint and type checks

  • Always keep linting and type-checking clean; do not proceed with changes that introduce errors.
  • Ruff lint: uv run ruff check .
  • Ruff auto-fix (limited): uv run ruff check --fix-only .
  • Ruff format: uv run ruff format .
  • mypy (strict): uv run mypy .

Tests

  • Run all tests (coverage): make test
  • Run a single test file: uv run pytest tests/unit/internal/test_container.py
  • Run a single test: uv run pytest tests/unit/internal/test_container.py::test_register
  • Run tests with keyword filter: uv run pytest -k "dependency" tests/
  • Coverage (recommended for new work): uv run pytest tests/ --benchmark-skip --cov=src/diwire --cov-report=term-missing

Repo structure

  • Library source: src/diwire/
  • Tests: tests/
    • Unit tests (public API): tests/unit/public/
    • Unit tests (internal/private behavior): tests/unit/internal/
    • Integrations (by dependency): tests/integrations/
    • Docs validation: tests/docs/
  • Docs: docs/
  • Runnable examples (embedded in docs): docs/howto/examples/

Examples README generation

  • The section between <!-- BEGIN: AUTO-GENERATED EXAMPLES --> and <!-- END: AUTO-GENERATED EXAMPLES --> in examples/README.md is generated from Python files in examples/ex_*.
  • Do not edit that region by hand.
  • Regenerate it with: uv run python -m tools.generate_examples_readme or make examples-readme.

Style and formatting

  • Line length: 100 (Ruff).
  • Quotes: double quotes (Ruff format).
  • Indent: 4 spaces.
  • Format with Ruff before linting.
  • Use ASCII unless the file already contains non-ASCII characters.

Imports

  • No relative imports in library code (Ruff tidy-imports bans them).
  • Prefer explicit imports from diwire modules.
  • Combine as imports when appropriate (combine-as-imports = true).
  • Avoid unused imports; __init__.py is allowed to re-export.

Typing and types

  • Python minimum version is 3.10 (use | unions, list[str], etc.).
  • All new public APIs must be fully typed.
  • mypy is strict; keep types precise and avoid Any.
  • If Any is unavoidable, document why and keep scope minimal.
  • Use typing.Protocol or collections.abc for public contracts.
  • Prefer Final for constants that should not change.

Naming conventions

  • Classes: PascalCase.
  • Functions and variables: snake_case.
  • Constants: UPPER_SNAKE_CASE.
  • Public API names should be stable and descriptive.
  • Test names should describe the behavior and expectation.

Error handling

  • Raise library-specific exceptions from src/diwire/exceptions.py.
  • Prefer explicit error messages over implicit failures.
  • Avoid catching Exception unless re-raising with context.
  • When adding new errors, update tests and docs/examples as needed.

Docstrings and docs

  • Ruff enforces many docstring rules, but D100/D103/etc. are ignored.
  • Public APIs should still include clear docstrings.
  • Example code in docs/howto/examples/ can be lighter-weight and may include prints.

Public README

  • Write README.md for library users who need to choose, install, and use diwire.
  • Keep its introduction focused on the library's purpose and user benefits.
  • Put CI setup, dependency workarounds, coverage exclusions, test commands, and agent workflow details in contributor documentation or PR notes, not in the public README.
  • Add compatibility limits only when they affect library users. Explain the user impact in the relevant usage section and link to detailed documentation when needed.

Testing guidelines

  • Aim for maximum coverage and edge cases for all new features.
  • Maintain 100% coverage overall; every change must keep coverage at 100%.
  • Tests live in tests/ and mirror module naming when possible.
  • Use pytest fixtures from tests/conftest.py for shared setup.
  • Prefer small, focused tests over large integration tests.
  • Keep tests deterministic; avoid time-based assertions unless necessary.
  • Public API signatures are frozen by tests/unit/public/test_public_api_signatures.py and the committed golden file tests/unit/public/public_api_signatures_expected.txt to catch accidental signature changes across user-visible exports.
  • Refresh the public API signatures snapshot intentionally with: DIWIRE_UPDATE_API_SIGNATURES=1 uv run pytest tests/unit/public/test_public_api_signatures.py.

Quality gates

  • Always ensure linting and type-checking run clean with no errors.
  • Every new change must preserve 100% test coverage.
  • After making changes, always run make lint and make test and report results.
  • At the very end of implementation, run make test-e2e-fastapi as the final verification step and report the result.

Ruff configuration highlights

  • select = ["ALL"] with targeted ignores.
  • Tests allow assert, unused args, and some pytest patterns.
  • Documentation examples live under docs/howto/examples/.
  • container.py has intentional complexity exemptions.

Agent behavior

  • Do not add new lint ignores without justification.
  • Keep public API backward compatible unless explicitly requested.
  • Preserve existing formatting and file organization.
  • Avoid adding new dependencies unless required for functionality.
  • Update or add tests whenever behavior changes.

Notes about additional rules

  • No Cursor rules found (.cursor/rules/ or .cursorrules).
  • No GitHub Copilot instructions found (.github/copilot-instructions.md).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.