Repository: ethereum/execution-spec-tests
Pull request #1604: docs: add `CONTRIBUTING.md` and improve coding standards
Author: login: danceratopz
Labels: name: scope:docs
description: Scope: Documentation
name: type:feat
description: type: Feature
Created: 2025-05-14T22:15:05Z | Merged: 2025-05-20T14:00:19Z

## 🗒️ Description
This PR:
1. Adds a `CONTRIBUTING.md` file documenting:
    i. What kind of contributions we do and don't accept.
    ii. Help for first-time contributors.
    iii. Guidelines for (semantic) commit messages and their connection to repo labels.
    iv. PR Merge guidelines/checklist (changelog, checks, squash, commit messages).
2. Streamlines the various coding standards docs that were a bit scattered into:
    i. `docs/getting_started/code_standards.md`
    ii. `docs/getting_started/code_standards_details.md`
3. Updates the doc flow to copy `CONTRIBUTING.md` and `SECURITY.md` to docs/getting_started/ (see `docs/scripts/copy_repo_docs_to_mkdocs.py` and `mkdocs.yml`).

## 🔗 Related Issues
None

## ✅ Checklist

- [x] All: Set appropriate labels for the changes.
- [ ] All: Considered squashing commits to improve commit history.
- [x] All: Added an entry to [CHANGELOG.md](/ethereum/execution-spec-tests/blob/main/docs/CHANGELOG.md).
- [x] All: Considered updating the online docs in the [./docs/](/ethereum/execution-spec-tests/blob/main/docs/) directory.
- [x] Tests: Ran `mkdocs serve` locally and verified the auto-generated docs for new tests in the [Test Case Reference](https://eest.ethereum.org/main/tests/) are correctly formatted.




Diff:
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000000..e29f023b2c2
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,323 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information and versions**:
+    - Run `eest info` to get repo and tool versions and copy the information to the issue:
+
+        ```console
+        uv run eest info
+        ```
+
+    - Branch of execution-spec-tests you're using, if applicable.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Install `uv`**:
+
+    ```bash
+    curl -LsSf https://astral.sh/uv/install.sh | sh
+    ```
+
+4. **Set up your environment**:
+
+    ```bash
+    uv python install 3.12
+    uv python pin 3.12
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+5. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+6. **Make your changes** according to our [code standards](https://eest.ethereum.org/main/getting_started/code_standards).
+
+7. **For EVM Tests**: Review the cases in the [EIP checklist template](./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md).
+
+8. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+9. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+10. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+10. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+- A breaking change should be indicated by appending `!` directly after the type/scope.
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+This repository's main focus are the EL client tests in `./tests/` (`scope:tests`), but it contains many unit/module tests (`type:tests`) for the test generation frameworks and libraries in this repository. This can be a bit confusing, these examples demonstrate how we apply these labels and terms:
+
+```console
+# adds new EVM tests to tests/prague/eip7702_set_code_tx/
+feat(tests): add test cases for EIP-7702
+
+# a pure EVM test code refactor; no changes to test fixture JSON (at least not to fixture hashes, IDs might change if it's too difficult to preserve them).
+refactor(tests): split test setup across several fixtures
+
+# improve EVM test docstrings (these are included in HTML documentation):
+docs(tests): improve EIP-7623 docstrings
+
+# fix an EVM test
+fix(tests): EIP-7702 test authorization list nonce/gas
+
+# add unit tests for the `execute` command
+test(execute): add tests for output dir arguments
+
+# fix a broken unit test
+test(fill): fix broken unit test
+```
+
+Examples of messages and titles for other types and scopes:
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+```
+
+## Merging PRs
+
+We maintain high standards for our repository history to ensure it's clean, understandable, and properly documented. Maintainers should follow these guidelines when merging PRs:
+
+### Pre-Merge Checklist
+
+1. **Review the PR template checklist**
+
+    - Ensure all applicable items are checked.
+    - Items that aren't relevant can be deleted or marked as N/A.
+
+2. **Verify changelog entry**
+
+    - Every PR that impacts functionality should have a changelog entry.
+    - The entry should clearly but concisely describe the change.
+    - It must include a link to the PR in brackets (e.g., `([#1234](https://github.com/ethereum/execution-spec-tests/pull/1234))`).
+    - Add any breaking changes at the top of the upcoming release section.
+
+3. **Check PR title format**
+
+    - The PR title must follow the [conventional commit](https://www.conventionalcommits.org/en/v1.0.0/) format: `<type>(<scope>): <description>`.
+    - This title will be used (suggested automatically by Github) as the squash commit message, so it's essential it's correct.
+    - Follow the same rules as commit messages (imperative tense, no period at end, etc.).
+    - Example: `feat(tests): add tests for EIP-7702 blob gas calculation`
+
+4. **Review PR description**:
+
+    - Ensure the PR description is accurate and up-to-date.
+
+5. **Add appropriate labels**:
+
+    - Ensure the PR has the appropriate labels matching its type and scope.
+
+6. **Consider other contributors/stakeholders**:
+
+    - Verify the PR has been reviewed and approved by any interested contributors and/or stakeholders.
+
+### Merge Strategy
+
+We **strongly prefer squash merging** over other strategies.
+
+Exceptions to the squash merge policy may include:
+
+- Large PRs with logically separate commits that should be preserved.
+- Work that spans multiple distinct features or fixes.
+
+### Squash Commit Details
+
+When performing a squash merge:
+
+1. **Include PR number in the commit title**
+
+    - Leave, respectively add, the PR number in parentheses at the end of the title.
+    - Example: `feat(tests): add tests for EIP-7702 gas calculation (#1234)`
+
+2. **Clean up the extended commit message**
+
+    - Delete all content in the extended message section EXCEPT:
+
+        - Any `Co-authored-by:` lines, which must be preserved to properly attribute work.
+        - The format should be `Co-authored-by: Full Name <email@example.com>`
diff --git a/README.md b/README.md
index ab8a84f7711..d6e42c0bc9d 100644
--- a/README.md
+++ b/README.md
@@ -104,6 +104,8 @@ Clone [execution-spec-tests](https://github.com/ethereum/execution-spec-tests) a
 ```console
 git clone https://github.com/ethereum/execution-spec-tests
 cd execution-spec-tests
+uv python install 3.11
+uv python pin 3.11
 uv sync --all-extras
 uv run solc-select use 0.8.24 --always-install
 ```
@@ -178,9 +180,15 @@ If you encounter issues during the installation process, please refer to the [In
 
 ## Contributing
 
-Contributions and feedback are welcome. Please see the [online documentation](https://eest.ethereum.org/main/writing_tests/) for this repository's coding standards and help on implementing new tests.
+Contributions and feedback are welcome. Please see our [Contributing Guidelines](CONTRIBUTING.md) for detailed information on how to contribute, and the [online documentation](https://eest.ethereum.org/main/writing_tests/) for this repository's coding standards and help on implementing new tests.
 
-We welcome earnest newcomers, no matter how small the contribution! However, we currently do not accept contributions that only fix spelling or grammatical errors in documentation, code or elsewhere. Pull requests should have reasonable substance or resolve an existing repository open issue; pull requests from obvious airdrop farmers will be closed upon review.
+We welcome earnest newcomers, no matter how small the contribution! However, we do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code or elsewhere
+- Pull requests from obvious airdrop farmers
+- Drive-by or vibe code contributions without proper engagement or context
+
+Pull requests should have reasonable substance or resolve an existing repository open issue.
 
 Care is required when adding PRs or issues for functionality that is live on Ethereum mainnet, please refer to the [Security Policy](SECURITY.md) for more information about reporting vulnerabilities and eligibility for the [bug bounty program](https://bounty.ethereum.org).
 
diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md
index 325b438d85a..1e771856ca2 100644
--- a/docs/CHANGELOG.md
+++ b/docs/CHANGELOG.md
@@ -31,6 +31,7 @@ The output behavior of `fill` has changed ([#1608](https://github.com/ethereum/e
 - ✨ Added the [EIP checklist template](https://eest.ethereum.org/main/writing_tests/checklist_templates/eip_testing_checklist_template/) that serves as a reference to achieve better coverage when implementing tests for new EIPs ([#1327](https://github.com/ethereum/execution-spec-tests/pull/1327)).
 - ✨ Added [Post-Mortems of Missed Test Scenarios](https://eest.ethereum.org/main/writing_tests/post_mortems/) to the documentation that serves as a reference list of all cases that were missed during the test implementation phase of a new EIP, and includes the steps taken in order to prevent similar test cases to be missed in the future ([#1327](https://github.com/ethereum/execution-spec-tests/pull/1327)).
 - ✨ Added a new `eest` sub-command, `eest info`, to easily print a cloned EEST repository's version and the versions of relevant tools, e.g., `python`, `uv` ([#1621](https://github.com/ethereum/execution-spec-tests/pull/1621)).
+- ✨ Add `CONTRIBUTING.md` for execution-spec-tests and improve coding standards documentation ([#1604](https://github.com/ethereum/execution-spec-tests/pull/1604)).
 
 ### 🧪 Test Cases
 
diff --git a/docs/dev/coding_style.md b/docs/dev/coding_style.md
index 37ae91433ff..6772746ca0b 100644
--- a/docs/dev/coding_style.md
+++ b/docs/dev/coding_style.md
@@ -1,19 +1,4 @@
 # Coding Style
 
-## Formatting and Line Length
-
-The Python code in execution-spec-tests is black formatted with a maximum line length of 100. Using VS Code with `editor.formatOnSave` is a big help to ensure files conform to the repo's coding style, see [VS Code Setup](../getting_started/setup_vs_code.md) to configure this and other useful settings.
-
-### Ignoring Bulk Change Commits
-
-The max line length was changed from 80 to 100 in Q2 2023. To ignore this bulk change commit in git blame output, use the `.git-blame-ignore-revs` file, for example:
-
-```console
-git blame --ignore-revs-file .git-blame-ignore-revs docs/gen_test_case_reference.py
-```
-
-To use the revs file persistently with `git blame`, run
-
-```console
-git config blame.ignoreRevsFile .git-blame-ignore-revs
-```
+!!! warning "Documentation Moved"
+    This documentation has been relocated to [Getting Started -> Code Standards](../getting_started/code_standards.md). Please use the new location for the most up-to-date information.
diff --git a/docs/dev/deps_and_packaging.md b/docs/dev/deps_and_packaging.md
index 26d618c9f7f..70d28adecce 100644
--- a/docs/dev/deps_and_packaging.md
+++ b/docs/dev/deps_and_packaging.md
@@ -7,10 +7,22 @@ Please use `uv>=0.7.0` to ensure `uv` writes `uv.lock` files with consistent fie
 ## Managing Dependencies
 
 We aim to provide specific [version specifiers](https://peps.python.org/pep-0440/#version-specifiers) for each of our direct and extra dependencies.
+
 !!! note "Packages should be managed via `uv`"
 
     Dependencies should be managed using `uv` on the command-line to ensure that version compatibility is ensured across all dependencies and that `uv.lock` is updated as required.
 
+    The docs below cover common operations, see the `uv` [documentation on managing dependencies](https://docs.astral.sh/uv/concepts/projects/dependencies/#multiple-sources) for more information.
+
+!!! info "Separate PRs are preferred when managing dependencies"
+
+    An upgrade of all pinned dependencies in `uv.lock` must be performed in a dedicated PR!
+    
+    For other dependency changes, they can be included in the PR that removed use of the library, for example. But if a version bump is made, without related source code changes, it should be done in a dedicated PR. This makes the change:
+
+    - Easier to track.
+    - Trivial to revert.
+
 ### Adding/modifying direct dependencies
 
 These are packages listed in the project's direct dependencies, i.e., in `pyproject.toml` `[project]` section:
@@ -67,3 +79,21 @@ docs = [
     ```
     uv add --optional lint "types-requests>=2.31,<2.33"
     ```
+
+## Upgrading Pinned Dependencies in `uv.lock`
+
+To upgrade all pinned dependencies in `uv.lock` to the latest version permitted by EEST's `project.toml` version specifiers run:
+
+```console
+uv lock --upgrade
+```
+
+Project-wide dependency upgrades must be made via a dedicated PR!
+
+To upgrade a single package run:
+
+```console
+uv lock --upgrade-package <package>
+```
+
+See [Locking and Syncing](https://docs.astral.sh/uv/concepts/projects/sync/#upgrading-locked-package-versions) in the `uv` docs for more information.
diff --git a/docs/getting_started/code_standards.md b/docs/getting_started/code_standards.md
new file mode 100644
index 00000000000..e81c774a02d
--- /dev/null
+++ b/docs/getting_started/code_standards.md
@@ -0,0 +1,96 @@
+# Code Standards
+
+This document outlines the coding standards and practices used in the @ethereum/execution-spec-tests repository.
+
+## Code and CI Requirements
+
+Code pushed to @ethereum/execution-spec-tests must fulfill the following checks in [CI](https://github.com/ethereum/execution-spec-tests/actions/workflows/tox_verify.yaml):
+
+| Type                   | Tox Command                                     | Explanation                                                                                                 |
+| ---------------------- | ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
+| Lint & code formatting | `uvx --with=tox-uv tox -e lint`                 | Python lint, format and module import check via `ruff`                                                      |
+| Typecheck              | `uvx --with=tox-uv tox -e typecheck`            | Objects that provide typehints pass type-checking via `mypy`.                                               |
+| Framework unit tests   | `uvx --with=tox-uv tox -e pytest`               | All framework unit tests must execute correctly.                                                            |
+| EL Client test cases   | `uvx --with=tox-uv tox -e tests-deployed`       | All client test cases for deployed forks can be generated.                                                  |
+| zkEVM EL Test cases    | `uvx --with=tox-uv tox -e tests-deployed-zkevm` | All client test cases specific to zkEVMs for deployed forks can be generated.                               |
+| HTML doc build         | `uvx --with=tox-uv tox -e mkdocs`               | Documentation generated without warnings.                                                                   |
+| Spellcheck             | `uvx --with=tox-uv tox -e spellcheck`           | Markdown spell-check (requires [additional dependency](code_standards_details.md#additional-dependencies)). |
+| Markdown lint          | `uvx --with=tox-uv tox -e markdownlint`         | Markdown lint (requires [additional dependency](code_standards_details.md#additional-dependencies)).        |
+
+!!! tip "Running checks easily"
+
+    Add an alias:
+
+    ```console
+    alias tox="uvx --with=tox-uv tox"
+    ```
+
+    Run all checks in parallel:
+
+    ```console
+    uvx --with=tox-uv tox run-parallel
+    ```
+
+    Run sequentially:
+
+    ```console
+    uvx --with=tox-uv tox
+    ```
+
+    Run specific, faster checks:
+
+    ```console
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+    Use [pre-commit hooks](./code_standards_details.md#pre-commit-hooks) that perform the fastest checks:
+
+    ```
+    uvx pre-commit install
+    ```
+
+!!! tip "Lint & code formatting: Using `ruff` and VS Code to help autoformat and fix module imports"
+
+    On the command-line, solve fixable issues with:
+
+    ```console
+    uv run ruff check --fix
+    ```
+
+    Use VS Code, see [VS Code Setup](../getting_started/setup_vs_code.md), to autoformat code, automatically organize Python module imports and highlight typechecking and spelling issues.
+
+!!! hint "Typechecking"
+
+    Adding the correct typehints can sometimes be tricky and there are exceptions that require manually disabling typechecking on a per-line basis. Please reach out to the maintainers if you need help, either [directly](../getting_started/getting_help.md) or in a PR.
+
+## Python Coding Preferences
+
+- **Line Length**: 100 characters maximum.
+- **Formatting**: Enforced by `ruff` (similar to `black`).
+- **Documentation**: All public functions and classes should have docstrings
+    - Docstrings should have a good one-line summary which uses the imperative ("Return" not "Returns").
+    - Add a blank line after the summary for multi-line docstrings.
+    - Single-line docstrings should have triple quotes on the same line.
+- **Imports**: Use explicit imports (no `from module import *`).
+- **Relative Imports**: Use relative imports within the same package
+- **Error Handling**: Use explicit exception types and meaningful error messages.
+- **Type Hints**: All functions should include type annotations.
+- **Variable Naming**:
+    - Use `snake_case` for variables, functions, and modules.
+    - Use `PascalCase` for classes.
+    - Use `UPPER_CASE` for constants.
+- **File Paths**: Strongly prefer `pathlib` over `os.path` for file system operations.
+
+## Editor Setup
+
+A correctly configured editor will automatically handle most formatting requirements. See [VS Code Setup](./setup_vs_code.md) for recommended settings.
+
+## Detailed Information
+
+See the [Detailed Code Standards](code_standards_details.md) page for more information on:
+
+- [Running tox environments](code_standards_details.md#running-tox-environments).
+    - Additional required [dependencies for markdownlint and spellchecking](code_standards_details.md#additional-dependencies).
+- [Pre-commit hooks setup](code_standards_details.md#pre-commit-hooks).
+- [Verifying test fixture changes](code_standards_details.md#verifying-fixture-changes).
+- [Ignoring bulk change commits](code_standards_details.md#ignoring-bulk-change-commits) in `git blame`.
diff --git a/docs/getting_started/code_standards_details.md b/docs/getting_started/code_standards_details.md
new file mode 100644
index 00000000000..eefc1e03a2a
--- /dev/null
+++ b/docs/getting_started/code_standards_details.md
@@ -0,0 +1,158 @@
+# Detailed Code Standards
+
+This page provides in-depth information about the code standards and verification processes in @ethereum/execution-spec-tests.
+
+## Running Tox Environments
+
+### Execution Options
+
+Run all `tox` environments in parallel:
+
+```console
+uvx --with=tox-uv tox run-parallel
+```
+
+Run environments sequentially with verbose output:
+
+```console
+uvx --with=tox-uv tox -v
+```
+
+List all available environments:
+
+```console
+uvx --with=tox-uv tox -av
+```
+
+### Specific Environment Commands
+
+Run specific environments using the `-e` flag:
+
+```console
+uvx --with=tox-uv tox -e lint,typecheck,spellcheck
+```
+
+#### For Test Case Changes (`./tests/`)
+
+```console
+uvx --with=tox-uv tox -e lint,typecheck,spellcheck,tests-deployed
+```
+
+#### For Framework and Library Changes (`./src/`)
+
+```console
+uvx --with=tox-uv tox -e lint,typecheck,spellcheck,pytest
+```
+
+#### For Documentation Changes (`./docs/`)
+
+```console
+uvx --with=tox-uv tox -e spellcheck,markdownlint,mkdocs
+```
+
+!!! note "Tox Virtual Environment"
+Checks performed by `tox` are sandboxed in their own virtual environments (created automatically in the `.tox/` subdirectory). These can be used to debug errors encountered during `tox` execution.
+
+### Additional Dependencies
+
+Some checks require external (non-Python) packages:
+
+#### For `spellcheck`
+
+```console
+sudo apt-get install aspell aspell-en
+```
+
+#### For `markdownlint`
+
+```console
+sudo apt install nodejs
+sudo npm install markdownlint-cli2 --global
+```
+
+Or use a specific node version using `nvm`.
+
+## Pre-commit Hooks
+
+Certain `tox` environments can be run automatically as git pre-commit hooks to ensure that your changes meet the project's standards before committing.
+
+### Installation
+
+```console
+uvx pre-commit install
+```
+
+For more information, see [Pre-commit Hooks Documentation](../dev/precommit.md).
+
+## Formatting and Line Length
+
+The Python code in @ethereum/execution-spec-tests is formatted with `ruff` with a line length of 100 characters.
+
+### Ignoring Bulk Change Commits
+
+The maximum line length was changed from 80 to 100 in Q2 2023. To ignore this bulk change commit in git blame output, use the `.git-blame-ignore-revs` file:
+
+```console
+git blame --ignore-revs-file .git-blame-ignore-revs docs/gen_test_case_reference.py
+```
+
+To use the revs file persistently with `git blame`:
+
+```console
+git config blame.ignoreRevsFile .git-blame-ignore-revs
+```
+
+## Building and Verifying Docs Locally
+
+To quickly build and browse the HTML documentation locally run:
+
+=== "bash"
+
+    ```console
+    export FAST_DOCS=True
+    uv run mkdocs serve
+    ```
+
+=== "fish"
+
+    ```console
+    set -x FAST_DOCS True
+    uv run mkdocs serve
+    ```
+
+Setting `FAST_DOCS` to `False` additionally builds the "[Test Case Reference](https://eest.ethereum.org/main/tests/)" Section.
+
+## Verifying Fixture Changes
+
+When writing a PR that modifies either the framework or test cases, verify that changes don't cause issues with existing test cases.
+
+All filled fixtures contain a `hash` field in the `_info` object, which is used to verify that the fixture hasn't changed.
+
+### Using the Hasher Tool
+
+The `hasher` command can be used to bulk-verify the hashes of fixtures in a directory.
+
+| Flag             | Description                                                       |
+| ---------------- | ----------------------------------------------------------------- |
+| `--files` / `-f` | Prints a combined hash per JSON fixture file.                     |
+| `--tests` / `-t` | Prints the hash of every test vector in JSON fixture files.       |
+| `--root` / `-r`  | Prints a combined hash for all JSON fixture files in a directory. |
+
+For a quick comparison between two fixture directories:
+
+```console
+hasher --root fixtures/
+hasher --root fixtures_new/
+```
+
+To identify which files are different:
+
+```console
+diff <(hasher --files fixtures/) <(hasher --files fixtures_new/)
+```
+
+For a granular comparison:
+
+```console
+diff <(hasher --tests fixtures/) <(hasher --tests fixtures_new/)
+```
diff --git a/docs/getting_started/installation.md b/docs/getting_started/installation.md
index 70703e58c2e..d48bc269923 100644
--- a/docs/getting_started/installation.md
+++ b/docs/getting_started/installation.md
@@ -24,13 +24,15 @@ If installed via `curl`, `uv` will download Python for your target platform if o
 
 ## Installation Commands
 
-Clone [execution-spec-tests](https://github.com/ethereum/execution-spec-tests) and install its dependencies.
+Clone [execution-spec-tests](https://github.com/ethereum/execution-spec-tests) and install its dependencies. We recommend using Python 3.12, the following uses `uv` to download and configures 3.12 to be the Python version used in execution-spec-tests:
 
 === "All x86-64 platforms and ARM64 macOS"
 
     ```console
     git clone https://github.com/ethereum/execution-spec-tests
     cd execution-spec-tests
+    uv python install 3.12
+    uv python pin 3.12
     uv sync --all-extras
     uv run solc-select use 0.8.24 --always-install
     ```
@@ -39,6 +41,8 @@ Clone [execution-spec-tests](https://github.com/ethereum/execution-spec-tests) a
 
     ```console
     git clone https://github.com/ethereum/execution-spec-tests
+    uv python install 3.12
+    uv python pin 3.12
     cd execution-spec-tests
     uv sync --all-extras
     ```
diff --git a/docs/navigation.md b/docs/navigation.md
index b90b652237e..32be4a9949c 100644
--- a/docs/navigation.md
+++ b/docs/navigation.md
@@ -1,8 +1,13 @@
 <!-- markdownlint-disable MD007 MD041 (MD007=ul-indent MD041=first-line-heading) -->
+<!-- Contributing and Security: included via mkdocs-gen-files and docs/include_contributing.py -->
   * [Home](index.md)
   * Getting Started
       * [Installation](getting_started/installation.md)
       * [Installation Troubleshooting](getting_started/installation_troubleshooting.md)
+      * [Contributing](getting_started/contributing.md)
+      * [Security Policy](getting_started/security.md)
+      * [Code Standards](getting_started/code_standards.md)
+      * [Detailed Code Standards](getting_started/code_standards_details.md)
       * [VS Code Setup](getting_started/setup_vs_code.md)
       * [Repository Overview](getting_started/repository_overview.md)
       * [Getting Help](getting_started/getting_help.md)
diff --git a/docs/scripts/copy_repo_docs_to_mkdocs.py b/docs/scripts/copy_repo_docs_to_mkdocs.py
new file mode 100644
index 00000000000..e77004cb140
--- /dev/null
+++ b/docs/scripts/copy_repo_docs_to_mkdocs.py
@@ -0,0 +1,64 @@
+"""Include EEST's CONTRIBUTING.md and SECURITY.md in the HTML documentation."""
+
+import logging
+import re
+from pathlib import Path
+
+import mkdocs_gen_files
+
+logger = logging.getLogger("mkdocs")
+
+
+def copy_markdown_file(source_path, destination_path, fix_links=True):
+    """Copy a markdown file to the destination, fixing links if requested."""
+    source_file = Path(source_path)
+    destination_file = Path(destination_path)
+
+    if not source_file.is_file():
+        raise FileNotFoundError(
+            f"Error: Source file '{source_file}' not found in current directory."
+        )
+
+    try:
+        with mkdocs_gen_files.open(destination_file, "w") as destination:
+            with open(source_file, "r") as f:
+                for line in f.readlines():
+                    if fix_links:
+                        # Fix absolute website links to relative docs links
+                        line = re.sub(
+                            r"https://eest\.ethereum\.org/main/([^)\s]+)", r"../\1.md", line
+                        )
+
+                        # Fix SECURITY.md link
+                        line = re.sub(
+                            r"\[Security Policy\]\(SECURITY\.md\)",
+                            r"[Security Policy](security.md)",
+                            line,
+                        )
+
+                        # Fix EIP checklist template link
+                        line = re.sub(
+                            r"\[EIP checklist template\]\(./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md\)",  # noqa: E501
+                            r"[EIP checklist template](../writing_tests/checklist_templates/eip_testing_checklist_template.md)",  # noqa: E501
+                            line,
+                        )
+
+                    destination.write(line)
+    except Exception as e:
+        raise Exception(f"Error copying file {source_file} to {destination_file}") from e
+
+    logger.info(f"Copied {source_file} to {destination_file}.")
+
+
+def include_contributing_in_docs():
+    """Copy CONTRIBUTING.md to ./docs/ to include in HTML docs."""
+    copy_markdown_file("CONTRIBUTING.md", "getting_started/contributing.md")
+
+
+def include_security_in_docs():
+    """Copy SECURITY.md to ./docs/getting_started/ to include in HTML docs."""
+    copy_markdown_file("SECURITY.md", "getting_started/security.md")
+
+
+include_contributing_in_docs()
+include_security_in_docs()
diff --git a/docs/gen_test_case_reference.py b/docs/scripts/gen_test_case_reference.py
similarity index 100%
rename from docs/gen_test_case_reference.py
rename to docs/scripts/gen_test_case_reference.py
diff --git a/docs/writing_tests/code_standards.md b/docs/writing_tests/code_standards.md
index afc23707e51..54ca891f694 100644
--- a/docs/writing_tests/code_standards.md
+++ b/docs/writing_tests/code_standards.md
@@ -1,23 +1,4 @@
 # Code Standards
 
-The Python code in the tests subdirectory `./tests` must fulfill the following checks:
-
-|   | Command                 | Explanation                                                              |
-|---|-------------------------|--------------------------------------------------------------------------|
-| 1 | `ruff check tests`      | Python lint, format and imports check.                                   |
-| 2 | `mypy tests`            | Objects that provide typehints pass type-checking via mypy.              |
-| 3 | `fill`                  | All tests must execute correctly.                                        |
-| 4 | `mkdocs build --strict` | Documentation generated without warnings.                                |
-| 5 | `pyspelling`            | Markdown spell-check.                                                    |
-| 6 | `markdownlint-cli2`     | Markdown lint check.                                                     |
-
-A correctly configured editor (see [VS Code Setup](../getting_started/setup_vs_code.md)) will ensure that most points are resolved automatically upon file save.
-
-Additionally, if you skip type hints, they won't be checked; we can help you add these in the PR.
-
-These checks must pass in order for the execution-spec-tests Github Actions to pass upon pushing to remote.
-
-!!! info "Running the checks with tox"
-    All these checks can be executed locally in a single command, `tox`, see [Verifying Changes](./verifying_changes.md).
-
-    If you need help, [get in touch](../getting_started/getting_help.md)!
+!!! warning "Documentation Moved"
+    This documentation has been relocated to [Code Standards](../getting_started/code_standards.md). Please use the new location for the most up-to-date information.
diff --git a/docs/writing_tests/verifying_changes.md b/docs/writing_tests/verifying_changes.md
index ff6c35a7d3e..d36f784270e 100644
--- a/docs/writing_tests/verifying_changes.md
+++ b/docs/writing_tests/verifying_changes.md
@@ -1,117 +1,4 @@
 # Verifying Changes
 
-The `tox` tool is used by execution-spec-tests to perform various checks on the codebase such as linting, type checking and spell-checking. The `tox` command can be executed locally to ensure that Github CI checks pass upon pushing to the repository.
-
-!!! note "Using automatic pre-commit checks"
-    Some `tox` environments can be ran as a git pre-commit hook, see [Enabling Pre-Commit Checks](../dev/precommit.md).
-
-## Running `tox`
-
-### Execution
-
-Run all `tox` environments in parallel with:
-
-```console
-uvx --with=tox-uv tox run-parallel
-```
-
-or, with sequential test environment execution and verbose output as:
-
-```console
-uvx --with=tox-uv tox
-```
-
-As some environments are rather slow, the next section describes how to run them individually.
-
-!!! note "Tox Virtual Environment"
-    The checks performed by `tox` are sandboxed in their own virtual environments (which are created automatically in the `.tox/` subdirectory). These can be used to debug errors encountered during `tox` execution.
-
-### Listing the Available Environments
-
-Get a list of all the available `tox` environments:
-
-```console
-uvx --with=tox-uv tox -av
-```
-
-## Executing `tox` Environments Individually
-
-A selection of preferred environments may be executed via the `-e` flag:
-
-```console
-uvx --with=tox-uv tox -e lint,typecheck,spellcheck
-```
-
-### Environments required for test case changes (`./tests/`)
-
-```console
-uvx --with=tox-uv tox -e lint,typecheck,spellcheck,tests-deployed
-```
-
-### Environments required for test framework and library changes (`./src/`)
-
-```console
-uvx --with=tox-uv tox -e lint,typecheck,spellcheck,pytest
-```
-
-### Environment required for documentation changes (`./docs/`)
-
-```console
-uvx --with=tox-uv tox -e spellcheck,markdownlint,mkdocs
-```
-
-### Additional Required Dependencies for `spellcheck` and `markdownlint`
-
-The `spellcheck` and `markdownlint` environments require external (non-python) packages. To avoid disruption to external contributors, these environments run in a "soft fail" mode if these dependencies are not available.
-
-Additional, optional prerequisites:
-
-1. `pyspelling`:
-
-    ```console
-    sudo apt-get install aspell aspell-en
-    ```
-
-2. `markdownlint-cli2`:
-
-    ```console
-    sudo apt install nodejs
-    sudo npm install markdownlint-cli2 --global
-    ```
-
-    Or use a specific node version using `nvm`, for example.
-
-### Verifying Fixture Changes
-
-When writing a PR that modifies either the framework or test cases, it is important to verify that the changes do not cause any issues with the existing test cases.
-
-All filled fixtures contain a `hash` field in the `_info` object, which is the hash of the json string of the fixture. This hash can be used to verify that the fixture has not changed.
-
-The `hasher` command can be used to bulk-verify the hashes of all fixtures in a directory.
-
-It has the following options:
-
-| Flag | Description |
-|--------------|-------------|
-| `--files` / `-f` | Prints a single combined hash per each JSON fixture file recursively contained in a directory. |
-| `--tests` / `-t` | Prints the hash of every single test vector in every JSON fixture file recursively contained in a directory. |
-| `--root` / `-r` | Prints a single combined hash for all JSON fixture files recursively contained in a directory. |
-
-For a quick comparison between two fixture directories, the `--root` option can be used and if the output matches, it means the fixtures in the directories are identical:
-
-```console
-hasher --root fixtures/
-hasher --root fixtures_new/
-```
-
-If the output does not match, the `--files` option can be used to identify which files are different:
-
-```console
-diff <(hasher --files fixtures/) <(hasher --files fixtures_new/)
-```
-
-And the `--tests` option can be used for an even more granular comparison:
-
-```console
-diff <(hasher --tests fixtures/) <(hasher --tests fixtures_new/)
-```
+!!! warning "Documentation Moved"
+    This documentation has been relocated to [Detailed Code Standards](../getting_started/code_standards_details.md). Please use the new location for the most up-to-date information.
diff --git a/mkdocs.yml b/mkdocs.yml
index 0014dbc2034..600dbbc08fb 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -11,6 +11,8 @@ plugins:
       exclude:
         - tests/*
         - navigation.md
+        - getting_started/contributing.md
+        - getting_started/security.md
   - glightbox
   - mkdocstrings:
       handlers:
@@ -23,11 +25,14 @@ plugins:
   - social
   - gen-files:
       scripts:
-        - docs/gen_test_case_reference.py
+        - docs/scripts/copy_repo_docs_to_mkdocs.py
+        - docs/scripts/gen_test_case_reference.py
   - literate-nav:
       nav_file: navigation.md
 
 watch:
+  - CONTRIBUTING.md
+  - SECURITY.md
   - src/
   - tests/
 
diff --git a/tox.ini b/tox.ini
index 078ea213715..66f97e7bf2d 100644
--- a/tox.ini
+++ b/tox.ini
@@ -15,7 +15,7 @@ runner = uv-venv-lock-runner
 package = editable
 wheel_build_env = .pkg
 solc_version = 0.8.24
-python_source_dirs = src tests docs .github/scripts
+python_source_dirs = src tests .github/scripts
 
 [testenv:lint]
 description = Lint and code formatting checks (ruff)
@@ -41,13 +41,16 @@ commands = python -c "import src.cli.tox_helpers; src.cli.tox_helpers.markdownli
 
 [testenv:mkdocs]
 description = Build documentation in strict mode (mkdocs)
-extras = docs
+extras = docs,lint
 setenv =
     GEN_TEST_DOC_VERSION = "tox"
     # Required for `cairosvg` so tox can find `libcairo-2`.
     # https://squidfunk.github.io/mkdocs-material/plugins/requirements/image-processing/?h=cairo#cairo-library-was-not-found
     DYLD_FALLBACK_LIBRARY_PATH = /opt/homebrew/lib
-commands = mkdocs build --strict
+commands = 
+    ruff check --no-fix --show-fixes docs/scripts
+    ruff format --diff docs/scripts
+    mkdocs build --strict
 
 [testenv:pytest]
 description = Run library and framework unit tests (pytest)
diff --git a/whitelist.txt b/whitelist.txt
index f9df5a90936..8dfc9f54d66 100644
--- a/whitelist.txt
+++ b/whitelist.txt
@@ -998,4 +998,9 @@ isogeny
 codomain
 nametag
 CFI'd
-opcode's
\ No newline at end of file
+opcode's
+backticked
+Typecheck
+autoformat
+Typechecking
+zkEVMs


Reviews:
user: login: chfast
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T07:52:28Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T07:57:19Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T07:57:49Z
user: login: chfast
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T07:58:44Z
user: login: chfast
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T08:00:30Z
user: login: felix314159
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-15T08:10:17Z
user: login: felix314159
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-15T08:15:15Z
user: login: felix314159
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-05-15T08:18:22Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T08:50:42Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T08:50:57Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T08:51:54Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T09:18:10Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T09:19:37Z
user: login: raxhvl
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T14:48:05Z
user: login: raxhvl
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T14:49:30Z
user: login: raxhvl
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T14:53:24Z
user: login: marioevz
body: LGTM, I just left a suggestion about python 3.11, because I think we should suggest 3.12 instead.
state: APPROVED
author_association: MEMBER
submitted_at: 2025-05-15T14:56:56Z
user: login: marioevz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T18:26:12Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T06:47:26Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T06:49:34Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T06:51:30Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T07:35:43Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T07:37:31Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T07:50:03Z
user: login: danceratopz
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T07:50:21Z
user: login: raxhvl
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T07:53:45Z
user: login: winsvega
body: I would need to study this formats actually. it will take time to memorize

state: APPROVED
author_association: NONE
submitted_at: 2025-05-19T09:01:42Z

Review comments:
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
+
+6. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+7. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+8. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+9. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+new(tests): add test cases for EIP-7702
path: CONTRIBUTING.md
user: login: chfast
body: This is still confusing for me. By the table above, there is no `new` type. Should it be `feat(tests)`?

In general you should put more focus on the work for adding / modifying / fixing `tests`.
created_at: 2025-05-15T07:52:24Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
+
+6. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+7. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+8. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+9. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+new(tests): add test cases for EIP-7702
path: CONTRIBUTING.md
user: login: danceratopz
body: Oh, oops, thanks. Yes, this should be:
```
feat(tests): add test cases for EIP-7702 
```
Does that make it less confusing?

> In general you should put more focus on the work for adding / modifying / fixing tests.

Thanks. It's a bit tricky, but you're right.
created_at: 2025-05-15T07:57:19Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
+
+6. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+7. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+8. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+9. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+new(tests): add test cases for EIP-7702
path: CONTRIBUTING.md
user: login: danceratopz
body: ```suggestion
feat(tests): add test cases for EIP-7702
```
created_at: 2025-05-15T07:57:49Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
+
+6. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+7. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+8. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+9. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+new(tests): add test cases for EIP-7702
path: CONTRIBUTING.md
user: login: chfast
body: Yes, thanks.
created_at: 2025-05-15T07:58:44Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
+
+6. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+7. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+8. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+9. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+new(tests): add test cases for EIP-7702
path: CONTRIBUTING.md
user: login: chfast
body: Maybe put the `feat(tests)` example at the top. And consider adding 1–2 more. What would be the case for `fix(tests)` and `refactor(tests)`?
created_at: 2025-05-15T08:00:30Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
path: CONTRIBUTING.md
user: login: felix314159
body: I woud like to add sth like:
```
uv self update
uv python install 3.11.12
uv python pin 3.11.12
```
Should lead to better reproducibility
created_at: 2025-05-15T08:10:17Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
path: CONTRIBUTING.md
user: login: felix314159
body: Can we add sth like "if you are writing a new test ensure to consider edge cases described in this [template](https://eest.ethereum.org/main/writing_tests/checklist_templates/eip_testing_checklist_template/#eip-execution-layer-testing-checklist-template)"
created_at: 2025-05-15T08:15:15Z
author_association: COLLABORATOR
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
+
+6. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+7. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+8. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+9. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+new(tests): add test cases for EIP-7702
+```
path: CONTRIBUTING.md
user: login: danceratopz
body: ```suggestion
#### Examples

This repository's main focus are the EL client tests in `./tests/` (`scope:tests`), but it contains many unit/module tests (`type:tests`) for the test generation frameworks and libraries in this repository. This can be a bit confusing, these examples demonstrate how we apply these labels and terms:

```console
# adds new EVM tests to tests/prague/eip7702_set_code_tx/
feat(tests): add test cases for EIP-7702

# a pure EVM test code refactor; no changes to test fixture JSON (at least not to fixture hashes, IDs might change if it's too difficult to preserve them).
refactor(tests): split test setup across several fixtures

# improve EVM test docstrings (these are included in HTML documentation):
docs(tests): improve EIP-7623 docstrings

# fix an EVM test
fix(tests): EIP-7702 test authorization list nonce/gas

# add unit tests for the `execute` command
test(execute): add tests for output dir arguments

# fix a broken unit test
test(fill): fix broken unit test
```
```
created_at: 2025-05-15T08:50:42Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
+
+6. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+7. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+8. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+9. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+new(tests): add test cases for EIP-7702
+```
+
path: CONTRIBUTING.md
user: login: danceratopz
body: ```suggestion

Examples of messages and titles for other types and scopes:

```console
feat(eest): add new test generator command
fix(forks): resolve `Cancun` initialization issue
docs(fill): describe new command-line args
refactor(tools): improve code organization in bytecode helpers
test(pytest): add tests for logging plugin
chore(deps): update dependency versions
```

```
created_at: 2025-05-15T08:50:57Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
+
+6. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+7. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+8. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+9. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+new(tests): add test cases for EIP-7702
path: CONTRIBUTING.md
user: login: danceratopz
body: Great suggestion, please see suggestion below: https://github.com/ethereum/execution-spec-tests/pull/1604#discussion_r2090639683
created_at: 2025-05-15T08:51:54Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
path: CONTRIBUTING.md
user: login: danceratopz
body: I don't think we should point users to update `uv` to the latest version unless we want them to test the latest `uv` for us :laughing: but pinning a specific `python` version is a great idea, thanks! Added! 

I think it's enough to pin to `3.11` though, as `python` releases are typically very stable and should not introduce breaking changes AND this allows user to get potential security fixes.

See [c697e7d](https://github.com/ethereum/execution-spec-tests/pull/1604/commits/c697e7d54395022245cc546531885846ba27b5e4).
created_at: 2025-05-15T09:18:09Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
path: CONTRIBUTING.md
user: login: danceratopz
body: Good suggestion. It's just a nudge for now, once all the test IDs have been added as markers, we can tell users to add them.

See [6a411c4](https://github.com/ethereum/execution-spec-tests/pull/1604/commits/6a411c4ebfddd9ffe64ff260074d67b61c233f55).
created_at: 2025-05-15T09:19:37Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
path: CONTRIBUTING.md
user: login: raxhvl
body: I'm wondering if at some point we should add a `eest info` cli that may prints this out:
```
EEST v4.5.0 (7abf18e)

Python: 3.12.3
uv: 0.6.14
OS : Windows 10
```
This could be helpful for quick debugging, say if `uv` is out of date. We could also create a bug report template that asks to provide the output of this command.
created_at: 2025-05-15T14:48:05Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv python install 3.11
+    uv python pin 3.11
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our [code standards](https://eest.ethereum.org/main/getting_started/code_standards).
+
+6. **For EVM Tests**: Review the cases in the [EIP checklist template](./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md).
+
+7. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+8. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+9. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+10. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
path: CONTRIBUTING.md
user: login: raxhvl
body: Also an entry to changelog, describing what kind of changes requires it.
created_at: 2025-05-15T14:49:29Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv python install 3.11
+    uv python pin 3.11
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our [code standards](https://eest.ethereum.org/main/getting_started/code_standards).
+
+6. **For EVM Tests**: Review the cases in the [EIP checklist template](./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md).
+
+7. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+8. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+9. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+10. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
path: CONTRIBUTING.md
user: login: raxhvl
body: Do we follow [conventional commits](https://www.conventionalcommits.org/en/v1.0.0/)? Using [`!` for breaking change](https://www.conventionalcommits.org/en/v1.0.0/#commit-message-with--to-draw-attention-to-breaking-change) could be helpful.
```
feat(eest)!: add new test generator command
```
created_at: 2025-05-15T14:53:24Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv python install 3.11
+    uv python pin 3.11
path: CONTRIBUTING.md
user: login: marioevz
body: I'd go straight to 3.12, since I feel we should deprecate 3.10/3.11 at some point sooner rather than later.
created_at: 2025-05-15T14:55:44Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv python install 3.11
+    uv python pin 3.11
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our [code standards](https://eest.ethereum.org/main/getting_started/code_standards).
+
+6. **For EVM Tests**: Review the cases in the [EIP checklist template](./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md).
+
+7. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+8. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+9. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+10. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
path: CONTRIBUTING.md
user: login: marioevz
body: This is great, didn't know there was a standard for this!
created_at: 2025-05-15T18:26:12Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv python install 3.11
+    uv python pin 3.11
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our [code standards](https://eest.ethereum.org/main/getting_started/code_standards).
+
+6. **For EVM Tests**: Review the cases in the [EIP checklist template](./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md).
+
+7. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+8. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+9. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+10. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
path: CONTRIBUTING.md
user: login: danceratopz
body: #1619
created_at: 2025-05-19T06:47:26Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv python install 3.11
+    uv python pin 3.11
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our [code standards](https://eest.ethereum.org/main/getting_started/code_standards).
+
+6. **For EVM Tests**: Review the cases in the [EIP checklist template](./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md).
+
+7. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+8. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+9. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+10. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
path: CONTRIBUTING.md
user: login: danceratopz
body: We should add this and adhere to the standard, thanks! I've always just gone by https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716
created_at: 2025-05-19T06:49:34Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv python install 3.11
+    uv python pin 3.11
path: CONTRIBUTING.md
user: login: danceratopz
body: Thanks for bringing this up, it went through my mind, but didn't due to warnings we haven't fixed (yet - we should be more diligent with this). But actually for 3.12, I think we have! #1414 
created_at: 2025-05-19T06:51:30Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
path: CONTRIBUTING.md
user: login: danceratopz
body: https://github.com/ethereum/execution-spec-tests/issues/1619
created_at: 2025-05-19T07:35:43Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,283 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our code standards.
+
+6. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+7. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+8. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+9. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
+
+```console
+<type>(<scope>): <description>
+```
+
+#### Rules
+
+- The format should be lowercase except for object names, which should be back-ticked (e.g., `FixtureCollector`).
+- The description should be clear and concise.
+- No period at the end of the title/message.
+- Use the imperative ("add" not "added" or "adds").
+
+#### Types
+
+The following commit types are used in this repository:
+
+| `<type>`       | Repo Label      | Description                                                  |
+| -------------- | --------------- | ------------------------------------------------------------ |
+| `feat`         | `type:feat`     | A new feature                                                |
+| `bug` or `fix` | `type:bug`      | A bug/bug fix (`bug` in issue; `fix` in commit/PR)           |
+| `docs`         | `type:docs`     | Documentation changes                                        |
+| `style`        | -               | Formatting changes that don't affect code functionality      |
+| `refactor`     | `type:refactor` | Code changes that neither fix bugs nor add features          |
+| `test`         | `type:test`     | Add, refactor, modify an EEST library or framework unit test |
+| `chore`        | `type:chore`    | Routine tasks, dependency updates, etc.                      |
+
+#### Scopes
+
+The following scopes are used in this repository:
+
+| `<scope>` | Repo Label         | Description                                    |
+| --------- | ------------------ | ---------------------------------------------- |
+| `fill`    | `scope:fill`       | Changes to `fill` command                      |
+| `execute` | `scope:execute`    | Changes to the `execute` command               |
+| `consume` | `scope:consume`    | Changes to `consume` command suite             |
+| `pytest`  | `scope:pytest`     | Changes that effect all EEST pytest plugins    |
+| `evm`     | `scope:evm`        | Changes to the `evm_transition_tool` package   |
+| `forks`   | `scope:forks`      | Changes to `ethereum_test_forks` package       |
+| `tools`   | `scope:tools`      | Changes to `ethereum_test_tools` package       |
+| `fw`      | `scope:fw`         | Framework changes (evm\|tools\|forks\|pytest)  |
+| `tests`   | `scope:tests`      | Changes to EL client test cases in `./tests`   |
+| `docs`    | `scope:docs`       | Documentation flow changes                     |
+| `ci`      | `scope:ci`         | Continuous Integration changes                 |
+| `gentest` | `scope:gentest`    | Changes to `gentest` CLI command               |
+| `eest`    | `scope:eest`       | Changes to `eest` CLI command                  |
+| `make`    | `scope:make`       | Changes to `eest make` command                 |
+| `tooling` | `scope:tooling`    | Python tools changes (`uv`, `ruff`, `tox`,...) |
+| `deps`    | `scope:deps`       | Updates package dependencies                   |
+
+#### Examples
+
+```console
+feat(eest): add new test generator command
+fix(forks): resolve `Cancun` initialization issue
+docs(fill): describe new command-line args
+refactor(tools): improve code organization in bytecode helpers
+test(pytest): add tests for logging plugin
+chore(deps): update dependency versions
+new(tests): add test cases for EIP-7702
path: CONTRIBUTING.md
user: login: danceratopz
body: Suggestion added.
created_at: 2025-05-19T07:37:31Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv python install 3.11
+    uv python pin 3.11
path: CONTRIBUTING.md
user: login: danceratopz
body: Added in c574472
created_at: 2025-05-19T07:50:02Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
+3. **Include relevant information**:
+    - Branch and commit of execution-spec-tests you're using.
+    - For test failures, include the test case and failure details.
+    - Screenshots if applicable.
+
+## Pull Requests
+
+We welcome contributions via pull requests! This section will guide you through the process.
+
+### For First-Time Contributors
+
+1. **Fork the repository** by clicking the "Fork" button on the top right of the [GitHub repository page](https://github.com/ethereum/execution-spec-tests).
+
+2. **Clone your fork** to your local machine:
+
+    ```bash
+    git clone https://github.com/YOUR-USERNAME/execution-spec-tests.git
+    cd execution-spec-tests
+    ```
+
+3. **Set up your environment**:
+
+    ```bash
+    uv python install 3.11
+    uv python pin 3.11
+    uv sync --all-extras
+    uv run solc-select use 0.8.24 --always-install
+    ```
+
+    See [installation troubleshooting](https://eest.ethereum.org/main/getting_started/installation_troubleshooting) if you encounter issues.
+
+4. **Create a branch** for your changes:
+
+    ```bash
+    git checkout -b your-branch-name
+    ```
+
+5. **Make your changes** according to our [code standards](https://eest.ethereum.org/main/getting_started/code_standards).
+
+6. **For EVM Tests**: Review the cases in the [EIP checklist template](./docs/writing_tests/checklist_templates/eip_testing_checklist_template.md).
+
+7. **Verify your changes** by running the appropriate checks:
+
+    ```bash
+    uvx --with=tox-uv tox -e lint,typecheck
+    ```
+
+8. **Commit your changes** with meaningful commit messages (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+
+9. **Push your branch** to your GitHub fork:
+
+    ```bash
+    git push -u origin your-branch-name
+    ```
+
+10. **Create a pull request** by navigating to your fork on GitHub and clicking the "New Pull Request" button.
+
+### Branch Naming Conventions
+
+Branch names should follow this format:
+
+```text
+<type>/<short-description>
+```
+
+Where `<type>` matches the semantic commit types:
+
+- `feat/` - For new features.
+- `fix/` - For bug fixes.
+- `docs/` - For documentation changes.
+- `test/` - For adding or modifying tests.
+- `refactor/` - For code refactoring.
+- `chore/` - For maintenance tasks.
+
+Examples:
+
+```text
+feat/add-cancun-blob-tests
+fix/prague-consume-genesis
+docs/improve-installation-guide
+```
+
+### PR Review Process
+
+1. **Initial checks**: When you submit a PR, automated CI checks will run. Make sure all checks pass before requesting a review.
+
+2. **Requesting review**: Feel free to tag a maintainer or ask for review in a PR comment.
+
+3. **Review feedback**: Maintainers will review your code and may suggest changes. Please address all comments and engage in discussion if needed.
+
+4. **Iteration**: Make requested changes, push to your branch, and the PR will update automatically. No need to create a new PR.
+
+5. **Approval**: Once your changes are approved, a maintainer will merge your PR.
+
+### PR Expectations
+
+To increase the chances of your PR being merged quickly:
+
+- **Scope**: Keep PRs focused on a _single issue or feature_.
+- **CI checks**: Ensure all CI checks pass before requesting review; but do ask for help if you don't understand the fail!
+- **Clean history**: Use meaningful, atomic commits that can be easily understood.
+- **Tests**: Include tests for new functionality.
+- **Documentation**: Update documentation for new features or changes.
+- **Responsiveness**: Try to respond to review feedback within a reasonable time.
+
+### Code Standards and Enforced CI Checks
+
+We enforce lint, code formatting and unit test checks in our CI - for detailed code standards and enforcement checks, see our [Code Standards documentation](https://eest.ethereum.org/main/getting_started/code_standards).
+
+### Commits
+
+It's recommended to keep changes logically grouped into smaller, individual commits to make changes easier to review.
+
+### Commit Messages, Issue and PR Titles
+
+We use semantic commit messages and PR titles following the format:
path: CONTRIBUTING.md
user: login: danceratopz
body: Added in [0c596cf](https://github.com/ethereum/execution-spec-tests/pull/1604/commits/0c596cfdf18f2702093318898111c052786926b2).
created_at: 2025-05-19T07:50:21Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,287 @@
+# Contributing
+
+Contributions are welcome from anyone, regardless of whether you are just starting your Python journey, a web developer or a seasoned Execution Layer developer!
+
+We appreciate your help and appreciate your contributions!
+
+## Code of Conduct
+
+All contributors are expected to be excellent to each other; other behavior is not tolerated.
+
+## Communication
+
+We encourage questions and discussions about the project. If you need help with the codebase or have questions about implementation details, please don't hesitate to reach out in the `#el-testing` channel in the [Ethereum R&D Discord Server](https://discord.com/invite/qGpsxSA).
+
+For detailed information on how to get help, please see the [Getting Help](https://eest.ethereum.org/main/getting_started/getting_help) page in our documentation, which includes communication channels and contact information for project maintainers.
+
+## Contributions We Welcome
+
+As mentioned in the README's [Contributing section](https://github.com/ethereum/execution-spec-tests#contributing), we welcome earnest contributions that have reasonable substance or resolve existing repository issues.
+
+## Contributions We Don't Accept
+
+We do not accept:
+
+- Contributions that only fix spelling or grammatical errors in documentation, code, or elsewhere.
+- Drive-by or vibe code contributions without proper engagement or context.
+- Pull requests from airdrop farmers.
+
+I.e., pull requests should have reasonable substance and context.
+
+## Reporting Bugs
+
+We use GitHub Issues to track bugs. To report a bug, please follow these guidelines:
+
+### Before Reporting
+
+1. **Check existing issues**: Search [open issues](https://github.com/ethereum/execution-spec-tests/issues) to see if your problem has already been reported.
+2. **Try to reproduce**: Confirm you can reproduce the issue consistently.
+3. **Consider security implications**: For security vulnerabilities, please do NOT create a public issue (or PR). Instead, refer to our [Security Policy](SECURITY.md) for responsible disclosure guidelines.
+
+### Creating a Bug Report
+
+When creating a new issue:
+
+1. **Use a clear, descriptive title** that identifies the problem, (see [Commit Messages, Issues and PR Titles](#commit-messages-issue-and-pr-titles)).
+2. **Provide detailed reproduction steps**:
+    - Include the exact commands you ran.
+    - Share relevant console output.
+    - Specify your environment (OS, Python version, if relevant, `uv` version from `uv --version`).
path: CONTRIBUTING.md
user: login: raxhvl
body: #1621 adds the command, if you want update the docs.
created_at: 2025-05-19T07:53:45Z
author_association: MEMBER

PR comments:
user: login: danceratopz
created_at: 2025-05-15T07:19:09Z
body: @marioevz @spencer-tb @winsvega @felix314159:
- This PR formalizes commit and pr best practices.
- While we've generally followed these rules, please check that you agree, in particular with:
    - [Commit Messages, Issue and PR Titles](https://github.com/ethereum/execution-spec-tests/blob/docs-contributing/CONTRIBUTING.md#commit-messages-issue-and-pr-titles)
    - [Merging PRs](https://github.com/ethereum/execution-spec-tests/blob/docs-contributing/CONTRIBUTING.md#merging-prs)

@felix314159 sham that this didn't make it before you started, but perhaps you still have a fresh take on whether this information would be helpful to newcomers?
author_association: MEMBER
user: login: danceratopz
created_at: 2025-05-15T07:20:18Z
body: @chfast In the past you've understandably had questions about commit messages and PR titles. Does this addition help?
-  [Commit Messages, Issue and PR Titles](https://github.com/ethereum/execution-spec-tests/blob/docs-contributing/CONTRIBUTING.md#commit-messages-issue-and-pr-titles)

If you have time/interest, feel free to add a review.
author_association: MEMBER
user: login: felix314159
created_at: 2025-05-15T08:16:40Z
body: Thanks for doing this, I think it will be helpful for everyone but especially for those not yet familiar with collaborating on GitHub
author_association: COLLABORATOR
user: login: winsvega
created_at: 2025-05-19T21:08:50Z
body: Ah!
Is it possible to make a CI verification script that will yell the standards suggestions just like the linter in py?
author_association: NONE
user: login: danceratopz
created_at: 2025-05-20T06:35:08Z
body: > Ah! Is it possible to make a CI verification script that will yell the standards suggestions just like the linter in py?

This is a good idea, but it's tricky. You can't enforce a check when people commit locally (you can only encourage them to use `precommit`). You could use this: https://github.com/compilerla/conventional-pre-commit
I use `precommit` (https://eest.ethereum.org/main/dev/precommit/) so maybe I'll check it out.

But tbh, I hold the merge commit to `main` to much higher standards than local commits within a PR. 

I don't really mind if people don't follow conventional commits within a PR, although descriptive commits are always helpful.

But where I personally find it the most important, in squash commit messages to `main`, you can't enforce it in a nice way, as this action can be performed through the Github UI.

Feel free to explore though if you like.
author_association: MEMBER
user: login: danceratopz
created_at: 2025-05-20T09:44:55Z
body: > Ah! Is it possible to make a CI verification script that will yell the standards suggestions just like the linter in py?

@winsvega, @raxhvl also pointed me to this VS Code plugin (thanks!). Haven't tried it yet, but looks promising. I still prefer committing on the command-line, but perhaps I can learn some new tricks :laughing: 
https://marketplace.visualstudio.com/items?itemName=vivaxy.vscode-conventional-commits
author_association: MEMBER
user: login: winsvega
created_at: 2025-05-20T10:40:30Z
body: I mean we can even check using bash 
What is PR title. Is it following conventions.
What is commit title.
And so on
author_association: NONE
user: login: raxhvl
created_at: 2025-05-20T12:08:56Z
body: > But where I personally find it the most important, in squash commit messages to `main`, you can't enforce it in a nice way, as this action can be performed through the Github UI.

I thinks thats the best way to enforce it. https://www.conventionalcommits.org/en/v1.0.0/#do-all-my-contributors-need-to-use-the-conventional-commits-specification
author_association: MEMBER