Require regenerating docs/ir/attributes.rst with its script, bring it up to date, and test it

.agents/contributing-changes.md

@@ -151,7 +151,8 @@ fails on both is the environment's.
 - User-facing features get a page under `docs/advanced/` (see `da.rst`, `auto.rst`, `bramfactor.rst` for the
   expected length and tone) and a link from the relevant index.
 - New layer attributes should carry a `description=` taken from `hls4ml/utils/attribute_descriptions.py`;
-  `docs/attr_doc_gen.py` turns those into the attribute tables in the documentation.
+  `docs/attr_doc_gen.py` turns those into `docs/ir/attributes.rst`, which you regenerate as
+  [CONTRIBUTING.md](../CONTRIBUTING.md) describes.
 - The PR description itself must document the change and the expected behaviour — that is item one of the
   contribution guidelines.
 

.agents/optimizer-passes.md

@@ -133,6 +133,9 @@ too — a quiet omission, not a loud one.
 The user writes the name in pascal case in the config (`ParallelizationFactor`); it arrives as snake case
 (`parallelization_factor`) in `layer.attributes`, and templates read it from there by the same name.
 
+Give the attribute a `description=` from `hls4ml/utils/attribute_descriptions.py`, and regenerate
+`docs/ir/attributes.rst` as [CONTRIBUTING.md](../CONTRIBUTING.md) describes.
+
 ## Worked example in the tree: the distributed arithmetic strategy
 
 A strategy implemented end to end as passes, useful as a template to copy. The machinery it uses is core to

AGENTS.md

@@ -73,6 +73,8 @@ the person opening the pull request, and tell them what remains to be confirmed.
   `pre-commit run --hook-stage manual --all-files`, which is what CI runs and which catches packaging
   problems the default hooks do not.
 - Add or update a test under `test/pytest/`. For a bug fix, the test should fail without the fix.
+- If the change touches layer attributes, regenerate `docs/ir/attributes.rst` as
+  [CONTRIBUTING.md](CONTRIBUTING.md) describes.
 - Check the whole diff yourself, hunk by hunk, before presenting it. Remove debug output, commented-out code
   and stray changes.
 - Do not commit generated HLS projects, model files or logs.

CONTRIBUTING.md

@@ -16,10 +16,11 @@ We use GitHub pull requests for this purpose.
 Consult [GitHub Help](https://help.github.com/articles/about-pull-requests/) for more information on using pull requests.
 
 1. In the pull request description, clearly document all changes made and the expected behavior.
-1. If you are introducing new functionality, add at least one unit test under the `test` folder and make sure it passes before you submit the pull request.
-1. Similarly, if you are fixing a bug, add at least one unit test under the `test` folder such that the main branch fails the test and your branch passes the test.
-1. Install and run `pre-commit` on the files that you have edited.
-1. Submit the pull request to the [main](https://github.com/fastmachinelearning/hls4ml) branch.
+2. If you are introducing new functionality, add at least one unit test under the `test` folder and make sure it passes before you submit the pull request.
+3. Similarly, if you are fixing a bug, add at least one unit test under the `test` folder such that the main branch fails the test and your branch passes the test.
+4. Install and run `pre-commit` on the files that you have edited.
+5. `docs/ir/attributes.rst` is generated. If you add layers or backends, or change layer attributes or their descriptions, regenerate it by running `python ../attr_doc_gen.py` from the `docs/ir` folder, and commit the result. Do not edit it by hand.
+6. Submit the pull request to the [main](https://github.com/fastmachinelearning/hls4ml) branch.
 
 Pull requests are **squash-merged**, so the individual commits on your branch are not preserved.
 You do not need to curate them, but the pull request title and description become the permanent record of