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.
- optimize-performanceSkill
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
- Distinctive: line 21
Always keep linting and type-checking clean.
- Very specific: line 29
Run all tests (coverage): make test
- Very specific: line 30
Run a single test file: uv run pytest tests/unit/internal/test_container.py
- Very specific: line 31
Run a single test: uv run pytest tests/unit/internal/test_container.py::test_register
- Very specific: line 32
Run tests with keyword filter: uv run pytest -k "dependency" tests/
- Distinctive: line 50
Do not edit that region by hand.
- Distinctive: line 59
Use ASCII unless the file already contains non-ASCII characters.
- Distinctive: line 63
No relative imports in library code (Ruff tidy-imports bans them).
- Very specific: line 64
Prefer explicit imports from diwire modules.
- Very specific: line 66
Avoid unused imports; __init__.py is allowed to re-export.
- Distinctive: line 71
All new public APIs must be fully typed.
- Very specific: line 73
If Any is unavoidable, document why and keep scope minimal.
- Very specific: line 74
Use typing.Protocol or collections.abc for public contracts.
- Very specific: line 75
Prefer Final for constants that should not change.
- Distinctive: line 83
Test names should describe the behavior and expectation.
- Distinctive: line 88
Prefer explicit error messages over implicit failures.
- Very specific: line 89
Avoid catching Exception unless re-raising with context.
- Distinctive: line 90
When adding new errors, update tests and docs/examples as needed.
- Very specific: line 100
Write README.md for library users who need to choose, install, and use diwire.
- Distinctive: line 101
Keep its introduction focused on the library's purpose and user benefits.
- Distinctive: line 102
Put CI setup, dependency workarounds, coverage exclusions, test commands, and agent workflow details in contributor documentation or PR …
- Distinctive: line 104
Add compatibility limits only when they affect library users.
- Very specific: line 112
Use pytest fixtures from tests/conftest.py for shared setup.
- Distinctive: line 113
Prefer small, focused tests over large integration tests.
- Distinctive: line 114
Keep tests deterministic; avoid time-based assertions unless necessary.
- Distinctive: line 124
Always ensure linting and type-checking run clean with no errors.
- Distinctive: line 125
Every new change must preserve 100% test coverage.
- Very specific: line 126
After making changes, always run make lint and make test and report results.
- Distinctive: line 138
Do not add new lint ignores without justification.
- Distinctive: line 139
Keep public API backward compatible unless explicitly requested.
- Distinctive: line 141
Avoid adding new dependencies unless required for functionality.
- Distinctive: line 142
Update or add tests whenever behavior changes.
- Very specific: line 146
No Cursor rules found (.cursor/rules/ or .cursorrules).
- Very specific: line 147
No GitHub Copilot instructions found (.github/copilot-instructions.md).
≈ “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.
Files
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/
- Unit tests (public API):
- 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 -->inexamples/README.mdis generated from Python files inexamples/ex_*. - Do not edit that region by hand.
- Regenerate it with:
uv run python -m tools.generate_examples_readmeormake 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
diwiremodules. - Combine
asimports when appropriate (combine-as-imports = true). - Avoid unused imports;
__init__.pyis 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
Anyis unavoidable, document why and keep scope minimal. - Use
typing.Protocolorcollections.abcfor public contracts. - Prefer
Finalfor 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
Exceptionunless 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.mdfor 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.pyfor 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.pyand the committed golden filetests/unit/public/public_api_signatures_expected.txtto 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 lintandmake testand report results. - At the very end of implementation, run
make test-e2e-fastapias 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.pyhas 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).
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
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.

