📝 Update templated files

.github/CONTRIBUTING.md

@@ -4,4 +4,5 @@
 # Contributing
 
 Thank you for your interest in contributing to MQT Bench!
-An extensive contribution guide is available in our [documentation](https://mqt.readthedocs.io/projects/bench/en/latest/contributing.html).
+An extensive contribution guide is available in our
+[documentation](https://mqt.readthedocs.io/projects/bench/en/latest/contributing.html).

.github/SECURITY.md

@@ -9,14 +9,16 @@ Security updates are applied only to the most recent releases.
 
 ## Reporting a Vulnerability
 
-To report vulnerabilities, you can privately report a potential security issue
-via the GitHub security vulnerabilities feature. This can be done here:
+To report vulnerabilities,
+you can privately report a potential security issue via the GitHub security
+vulnerabilities feature.
+This can be done here:
 
-https://github.com/munich-quantum-toolkit/bench/security/advisories
+<https://github.com/munich-quantum-toolkit/bench/security/advisories>
 
 Please do **not** open a public issue about a potential security vulnerability.
 
 You can find more details on the security vulnerability feature in the GitHub
 documentation here:
 
-https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability
+<https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability>

.github/SUPPORT.md

@@ -3,17 +3,23 @@
 
 # Support
 
-If you are stuck with a problem using MQT Bench or have questions, please get in touch at our [Issues] or [Discussions].
+If you are stuck with a problem using MQT Bench or have questions,
+please get in touch at our [Issues] or [Discussions].
 We'd love to help.
 
 You can save time by following this procedure when reporting a problem:
 
 - Do try to solve the problem on your own first.
-- Search through past [Issues] and [Discussions] to see if someone else already had the same problem.
-- Before filing a bug report, try to create a minimal reproducible example (MRE) that reproduces the problem.
-  It is much easier to identify the cause for the problem if a handful of lines suffice to show that something is not working.
+- Search through past [Issues] and [Discussions] to see
+  if someone else already had the same problem.
+- Before filing a bug report,
+  try to create a minimal reproducible example (MRE)
+  that reproduces the problem.
+  It is much easier to identify the cause for the problem
+  if a handful of lines suffice to show that something is not working.
 
-You can also always reach us at [quantum.cda@xcit.tum.de](mailto:quantum.cda@xcit.tum.de).
+You can also always reach us at
+[quantum.cda@xcit.tum.de](mailto:quantum.cda@xcit.tum.de).
 
 [Issues]: https://github.com/munich-quantum-toolkit/bench/issues
 [Discussions]: https://github.com/munich-quantum-toolkit/bench/discussions

.github/pull_request_template.md

@@ -4,7 +4,12 @@ Please include a summary of the change and, if applicable, which issue is fixed.
 Please also include relevant motivation and context.
 List any dependencies that are required for this change.
 
-Fixes #(issue) <!--- Replace `(issue)` with the issue number fixed by this pull request. If this PR does not fix an issue, please remove this line. -->
+<!---
+Replace `(issue)` with the issue number fixed by this pull request.
+If this PR does not fix an issue, please remove the line.
+-->
+
+Fixes #(issue)
 
 ## Checklist
 

.github/release-drafter.yml

@@ -33,7 +33,7 @@ categories:
       - "github-actions"
       - "pre-commit"
       - "submodules"
-change-template: "- $TITLE ([#$NUMBER]($URL)) ([**@$AUTHOR**](https://github.com/$AUTHOR))"
+change-template: "- $TITLE ([#$NUMBER]($URL)) (**@$AUTHOR**)"
 change-title-escapes: '\<*_&'
 exclude-labels:
   - "skip-changelog"

AGENTS.md

@@ -42,25 +42,43 @@
 ### General
 
 - MUST run `uvx nox -s lint` after every batch of changes.
-  This runs the full `prek` hook set from `.pre-commit-config.yaml` (including `ruff`, `typos`, `ty`, formatting, and metadata checks).
+  This runs the full `prek` hook set from `.pre-commit-config.yaml`
+  (including `ruff`, `typos`, `ty`, formatting, and metadata checks).
   All hooks must pass before submitting.
-- MUST add or update tests for every code change, even if not explicitly requested.
+- MUST add or update tests for every code change,
+  even if not explicitly requested.
 - MUST follow existing code style by checking neighboring files for patterns.
-- MUST update `CHANGELOG.md` and `UPGRADING.md` when changes are user-facing, breaking, or otherwise noteworthy.
-- MUST include a commit footer attribution in the form `Assisted-by: [Model Name] via [Tool Name]` (example: `Assisted-by: Claude Sonnet 4.6 via GitHub Copilot`) if AI tools are used to prepare a commit.
-- NEVER modify files that start with "This file has been generated from an external template. Please do not modify it directly."
-  These files are managed by [the MQT templates action](https://github.com/munich-quantum-toolkit/templates) and changes will be overwritten.
+- MUST update `CHANGELOG.md` and `UPGRADING.md` when changes are user-facing,
+  breaking, or otherwise noteworthy.
+- MUST include a commit footer attribution in the form
+  `Assisted-by: [Model Name] via [Tool Name]` (example:
+  `Assisted-by: Claude Sonnet 4.6 via GitHub Copilot`) if AI tools are used to
+  prepare a commit.
+- NEVER modify files that start with "This file has been generated from an
+  external template.
+  Please do not modify it directly."
+  These files are managed by
+  [the MQT templates action](https://github.com/munich-quantum-toolkit/templates)
+  and changes will be overwritten.
 - PREFER running targeted tests over the full test suite during development.
 
 ### Python
 
 - MUST use Google-style docstrings
-- PREFER running a single Python version over the full test suite during development.
-- PREFER fixing reported warnings over suppressing them (e.g., with `# noqa` comments for ruff); only add ignore rules when necessary and document why.
-- PREFER fixing typing issues reported by `ty` before adding suppression comments (`# ty: ignore[code]`); suppressions are sometimes necessary for incompletely typed libraries (e.g., Qiskit).
+- PREFER running a single Python version over the full test suite during
+  development.
+- PREFER fixing reported warnings over suppressing them
+  (e.g., with `# noqa` comments for ruff);
+  only add ignore rules when necessary and document why.
+- PREFER fixing typing issues reported by `ty`
+  before adding suppression comments
+  (`# ty: ignore[code]`);
+  suppressions are sometimes necessary for incompletely typed libraries
+  (e.g., Qiskit).
 
 ## Self-Review Checklist
 
 - Did `uvx nox -s lint` pass without errors?
 - Are all changes covered by at least one automated test?
-- Are `CHANGELOG.md` and `UPGRADING.md` updated when changes are user-facing, breaking, or otherwise noteworthy?
+- Are `CHANGELOG.md` and `UPGRADING.md` updated when changes are user-facing,
+  breaking, or otherwise noteworthy?

docs/ai_usage.md

@@ -3,24 +3,33 @@
 
 # AI Usage Guidelines
 
-We acknowledge that AI tools (Large Language Models, code completion engines like GitHub Copilot, etc.) have become helpful assistants for many developers.
-We allow the use of these tools to assist with contributions, provided that their use is transparent, responsible, and that a **human remains in the loop** at all times.
+We acknowledge that AI tools
+(Large Language Models, code completion engines like GitHub Copilot, etc.)
+have become helpful assistants for many developers.
+We allow the use of these tools to assist with contributions,
+provided that their use is transparent, responsible,
+and that a **human remains in the loop** at all times.
 
-This guide outlines our policy on AI-assisted contributions to ensure code quality, maintainability, and legal compliance.
+This guide outlines our policy on AI-assisted contributions to ensure code
+quality, maintainability, and legal compliance.
 
 ## Core Principles
 
 ### 1. You are Responsible
 
 **You are responsible for every line of code you submit.**
 
-Regardless of whether code was written by you or generated by an AI tool, you are the author and are fully accountable for the contribution. You must:
+Regardless of whether code was written by you or generated by an AI tool,
+you are the author and are fully accountable for the contribution.
+You must:
 
 - Fully understand the code you are submitting.
-- Be able to explain the reasoning behind the code and how it interacts with the rest of the codebase.
+- Be able to explain the reasoning behind the code
+  and how it interacts with the rest of the codebase.
 - Verify that the code is correct, efficient, and follows our coding standards.
 
-**Do not blindly copy-paste AI-generated code.** If you cannot explain it, do not submit it.
+**Do not blindly copy-paste AI-generated code.**
+If you cannot explain it, do not submit it.
 
 ### 2. Human in the Loop
 
@@ -29,82 +38,139 @@ Regardless of whether code was written by you or generated by an AI tool, you ar
 When using AI tools, you must be the driver.
 The AI is the assistant.
 
-- **Review:** You must read and review all AI-generated code or text before submitting it.
-- **Edit:** AI-generated code often requires significant editing to meet project standards and correctness.
-- **Verify:** Ensure the code actually solves the problem and doesn't introduce subtle bugs or security vulnerabilities.
+- **Review:** You must read and review all AI-generated code or text
+  before submitting it.
+- **Edit:** AI-generated code often requires significant editing to meet project
+  standards and correctness.
+- **Verify:** Ensure the code actually solves the problem
+  and doesn't introduce subtle bugs or security vulnerabilities.
 
 ### 3. Communication
 
-**Do not use AI tools to generate issue descriptions, pull request comments, or code reviews.**
+**Do not use AI tools to generate issue descriptions, pull request comments, or
+code reviews.**
 
 We value your personal input and communication.
-LLMs are notoriously unreliable and can produce "smart-sounding" but incorrect or irrelevant claims ("hallucinations").
+LLMs are notoriously unreliable and can produce "smart-sounding" but incorrect
+or irrelevant claims ("hallucinations").
 Phrase your communications in your own words.
-It is more important that we can follow your reasoning than that the text sounds "perfect".
+It is more important that we can follow your reasoning than
+that the text sounds "perfect".
 
 ### 4. Transparency and Disclosure
 
-Transparency helps the community understand the role of these tools and develop best practices.
+Transparency helps the community understand the role of these tools
+and develop best practices.
 
 **We encourage you to disclose any AI assistance.**
-This helps us understand how these tools are being used and identify potential issues.
+This helps us understand how these tools are being used
+and identify potential issues.
 You can disclose this information in the following ways:
 
-- **Commit Messages**: Add a trailer to your commit message in the form `Assisted-by: [Model Name] via [Tool Name]` (example: `Assisted-by: Claude Sonnet 4.6 via GitHub Copilot`)
-- **PR Description**: Mention the tool (name and version) and how it was used in the PR description.
+- **Commit Messages**: Add a trailer to your commit message in the form
+  `Assisted-by: [Model Name] via [Tool Name]` (example:
+  `Assisted-by: Claude Sonnet 4.6 via GitHub Copilot`)
+- **PR Description**: Mention the tool
+  (name and version) and how it was used in the PR description.
 
 ### 5. Licensing and Copyright
 
-You are responsible for ensuring that your contribution does not violate any third-party licenses or copyrights.
+You are responsible for ensuring
+that your contribution does not violate any third-party licenses or copyrights.
 
-- **Originality**: Your submission must be your own original work of authorship.
-- **Training Data**: Be aware that some AI tools may generate code that is substantially similar to their training data. You must ensure that you have the right to contribute the generated code under [our license](https://github.com/munich-quantum-toolkit/bench/blob/main/LICENSE.md).
+- **Originality**:
+  Your submission must be your own original work of authorship.
+- **Training Data**: Be aware that some AI tools may generate code
+  that is substantially similar to their training data.
+  You must ensure that you have the right to contribute the generated code under
+  [our license](https://github.com/munich-quantum-toolkit/bench/blob/main/LICENSE).
 
 ## Extractive Contributions
 
-Processing pull requests and comments for MQT Bench requires significant maintainer time and energy.
-Sending unreviewed AI output to open-source projects shifts the burden of verifying correctness from the contributor to the maintainer.
-We classify such contributions as "extractive" because they consume more community resources than they provide in value.
-
-Our **golden rule** is that a contribution should be valuable enough to justify the review effort.
-Nadia Eghbal captures this concept in her book _[Working in Public](https://press.stripe.com/working-in-public)_:
-
-> "When attention is being appropriated, producers need to weigh the costs and benefits of the transaction. To assess whether the appropriation of attention is net-positive, it's useful to distinguish between _extractive_ and _non-extractive_ contributions. Extractive contributions are those where the marginal cost of reviewing and merging that contribution is greater than the marginal benefit to the project's producers. In the case of a code contribution, it might be a pull request that's too complex or unwieldy to review, given the potential upside." — Nadia Eghbal
-
-Before AI tools became widespread, open-source project maintainers would often review all changes sent to the project simply because submitting a pull request was a sign of interest from a potential long-term contributor.
-However, AI tools now allow the rapid generation of large volumes of code, which can easily overwhelm maintainers if submitted without careful review.
-Our policy exists to ensure that maintainer time is spent on high-quality interactions rather than debugging AI-generated code.
+Processing pull requests and comments
+for MQT Bench requires significant maintainer time and energy.
+Sending unreviewed AI output to open-source projects shifts the burden of
+verifying correctness from the contributor to the maintainer.
+We classify such contributions as "extractive"
+because they consume more community resources than they provide in value.
+
+Our **golden rule** is that a contribution should be valuable enough to justify
+the review effort.
+Nadia Eghbal captures this concept in her book
+_[Working in Public](https://press.stripe.com/working-in-public)_:
+
+> "When attention is being appropriated,
+> producers need to weigh the costs and benefits of the transaction.
+> To assess whether the appropriation of attention is net-positive,
+> it's useful to distinguish between _extractive_
+> and _non-extractive_ contributions.
+> Extractive contributions are those where the marginal cost of reviewing
+> and merging that contribution is greater than the marginal benefit to the
+> project's producers.
+> In the case of a code contribution,
+> it might be a pull request that's too complex or unwieldy to review,
+> given the potential upside." — Nadia Eghbal
+
+Before AI tools became widespread,
+open-source project maintainers would often review all changes sent to the
+project simply because submitting a pull request was a sign of interest from a
+potential long-term contributor.
+However, AI tools now allow the rapid generation of large volumes of code,
+which can easily overwhelm maintainers if submitted without careful review.
+Our policy exists to ensure
+that maintainer time is spent on high-quality interactions rather than debugging
+AI-generated code.
 
 ### Sustainable Open Source
 
-The Munich Quantum Toolkit (MQT) is committed to remaining free, open-source, and permissively licensed.
-We want to build a welcoming community where aspiring quantum software engineers can learn and grow.
+The Munich Quantum Toolkit (MQT) is committed to remaining free, open-source,
+and permissively licensed.
+We want to build a welcoming community
+where aspiring quantum software engineers can learn and grow.
 Reviewing contributions is a key part of this mentorship.
 
-However, to keep the project sustainable, we must prioritize non-extractive contributions.
-By thoroughly reviewing and understanding your AI-assisted code before submission, you ensure that your contribution is a net positive for the project.
-This helps us maintain a healthy ecosystem where both the software and its contributors can thrive.
+However, to keep the project sustainable,
+we must prioritize non-extractive contributions.
+By thoroughly reviewing and understanding your AI-assisted code
+before submission, you ensure that your contribution is a net positive
+for the project.
+This helps us maintain a healthy ecosystem where both the software
+and its contributors can thrive.
 
 ## Prohibited Uses
 
-- **"Good First Issues"**: Do not use AI tools to solve issues labeled as "good first issue". These are intended as learning opportunities for new contributors. Automating them defeats the purpose.
-- **Spam**: Do not use AI to generate low-quality or repetitive comments/reviews ("AI Slop").
-- **Unreviewed Code**: Submitting code that you, as a human, have not reviewed and tested yourself.
+- **"Good First Issues"**:
+  Do not use AI tools to solve issues labeled as "good first issue".
+  These are intended as learning opportunities for new contributors.
+  Automating them defeats the purpose.
+- **Spam**: Do not use AI to generate low-quality or repetitive comments/reviews
+  ("AI Slop").
+- **Unreviewed Code**: Submitting code that you, as a human,
+  have not reviewed and tested yourself.
 
 ## Summary
 
-We want to foster a welcoming community where developers can learn and grow. AI tools can be great for productivity, but they should not replace critical thinking or the learning process.
-If a maintainer judges that a contribution relies too heavily on unverified AI generation or lacks sufficient human understanding ("extractive contribution"), we may request that you revise it or close the PR.
+We want to foster a welcoming community where developers can learn and grow.
+AI tools can be great for productivity,
+but they should not replace critical thinking or the learning process.
+If a maintainer judges that a contribution relies too heavily on unverified AI
+generation or lacks sufficient human understanding ("extractive contribution"),
+we may request that you revise it or close the PR.
 
 ---
 
-Parts of this guide were inspired by or adapted from the contribution guidelines of
+Parts of this guide were inspired by
+or adapted from the contribution guidelines of
 
 - [Astral],
-- [Qiskit],
-- [LLVM], including the sources therein, such as [Fedora Council Policy Proposal: Policy on AI-Assisted Contributions (fetched 2026-03-12)][fedora], which is licensed under the [Creative Commons Attribution 4.0 International License][cca].
-
-with the help of Gemini 3 Pro (Preview). The links above serve as attribution.
+- [Qiskit], and
+- [LLVM], including the sources therein, such as
+  [Fedora Council Policy Proposal: Policy on AI-Assisted Contributions (fetched 2026-03-12)][fedora],
+  which is licensed under the
+  [Creative Commons Attribution 4.0 International License][cca],
+
+with the help of Gemini 3 Pro (Preview).
+The links above serve as attribution.
 
 [Astral]: https://github.com/astral-sh/uv/blob/c89a78ec085077f6344b0439ddf07fdad7336310/CONTRIBUTING.md
 [Qiskit]: https://github.com/Qiskit/qiskit/blob/cd8701690723d3d9602fac63fe0bd7ea618799be/CONTRIBUTING.md#use-of-ai-tools