Add option for ignore all system exit codes (#2017)

* Add option for ignore all system exit codes

* Change to Pavel's suggestion

* More checking

* Fix whitespace

* Add test for range scenario

* Review feedback

Author: rchiodo

.claude/skills/click/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: click
+description: Best practices for building CLI applications with Click including commands, groups, options, and testing.
+---
+
+# Skill: Click
+
+Best practices for building CLI applications with Click including commands, groups, options, and testing.
+
+## When to Use
+
+Apply this skill when building command-line interfaces with Click — commands, groups, options, arguments, and prompts.
+
+## Commands
+
+-   Use `@click.command()` for single commands, `@click.group()` for multi-command CLIs.
+-   Declare options with `@click.option()` and positional args with `@click.argument()`.
+-   Use `help=` on every option and command for auto-generated help text.
+-   Use `envvar=` to allow environment variable fallback for sensitive options.
+
+## Groups
+
+-   Organize subcommands with `@click.group()` and `group.add_command()`.
+-   Use `@click.pass_context` to share state between group and subcommands.
+
+## Type Safety
+
+-   Use Click's built-in types (`click.Path(exists=True)`, `click.Choice([...])`, `click.IntRange()`).
+-   Use callbacks for custom validation.
+
+## Testing
+
+-   Use `click.testing.CliRunner()` for testing commands without subprocess overhead.
+-   Assert on `result.exit_code` and `result.output`.
+-   Use `mix_stderr=False` to test stderr separately.
+
+## Pitfalls
+
+-   Don't use `sys.exit()` — use `click.exceptions.Exit` or return from the command.
+-   Don't use `print()` — use `click.echo()` for proper encoding handling.
+-   Always handle `KeyboardInterrupt` / abort prompts gracefully.

.claude/skills/django/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: django
+description: Best practices for Django web development including models, views, templates, and testing.
+---
+
+# Skill: Django
+
+Best practices for Django web development including models, views, templates, and testing.
+
+## When to Use
+
+Apply this skill when working with Django projects — models, views, URL routing, templates, forms, admin, and management commands.
+
+## Project Structure
+
+-   Follow the standard Django app layout: `models.py`, `views.py`, `urls.py`, `admin.py`, `tests.py`, `forms.py`.
+-   Keep each app focused on a single domain concept; avoid "god apps" with unrelated models.
+-   Use `settings/base.py`, `settings/dev.py`, `settings/prod.py` for environment-specific configuration.
+
+## Models
+
+-   Always define `__str__` on models for admin and debugging readability.
+-   Use `Meta.ordering` sparingly — it adds `ORDER BY` to every query. Prefer explicit `.order_by()` on querysets.
+-   Use database indexes (`db_index=True`, `Meta.indexes`) for fields that appear in `filter()` / `order_by()`.
+-   Prefer `CharField` with `choices` (or `TextChoices` / `IntegerChoices`) over bare strings for constrained fields.
+-   Use `F()` expressions and `Q()` objects for complex queries to avoid race conditions and improve readability.
+
+## Views
+
+-   Prefer class-based views (CBVs) for CRUD; prefer function-based views for one-off logic.
+-   Always explicitly set `queryset` or override `get_queryset()` — never rely on mutable class-level state.
+-   Use `select_related()` and `prefetch_related()` to avoid N+1 query problems.
+-   Set `LOGIN_URL` and use `@login_required` / `LoginRequiredMixin` consistently.
+
+## Testing
+
+-   Use `pytest-django` with `@pytest.mark.django_db` for database access.
+-   Prefer `TestCase` or `TransactionTestCase` only when explicit transaction control is needed; otherwise use pytest fixtures.
+-   Use `RequestFactory` or `Client` to test views without starting a server.
+-   Use `baker.make()` (model-bakery) or factories instead of manual model construction in tests.
+
+## Pitfalls
+
+-   Never do blocking I/O in async views without wrapping in `sync_to_async`.
+-   Avoid importing models at module level in `settings.py` or `urls.py` (circular imports).
+-   Never store secrets in `settings.py` — use environment variables.
+-   Avoid raw SQL unless the ORM genuinely cannot express the query.

.claude/skills/flask/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: flask
+description: Best practices for Flask web development including routing, blueprints, and testing.
+---
+
+# Skill: Flask
+
+Best practices for Flask web development including routing, blueprints, and testing.
+
+## When to Use
+
+Apply this skill when building Flask web applications or APIs — routing, blueprints, extensions, and testing.
+
+## Project Structure
+
+-   Use the application factory pattern (`create_app()`) to avoid global state and enable testing.
+-   Organize features into Blueprints; register them in the factory.
+-   Keep configuration in a `config.py` with classes like `DevelopmentConfig`, `ProductionConfig`.
+
+## Routing and Views
+
+-   Prefer explicit HTTP method decorators (`@app.get`, `@app.post`) over generic `@app.route` with `methods=[...]`.
+-   Validate request data early; return 400 errors for malformed input before processing.
+-   Use `flask.abort()` with appropriate HTTP codes rather than returning error responses manually.
+
+## Extensions
+
+-   Initialize extensions lazily with `ext.init_app(app)` inside the factory, not at module level.
+-   Common extensions: Flask-SQLAlchemy, Flask-Migrate, Flask-Login, Flask-WTF, Flask-CORS.
+
+## Testing
+
+-   Use `app.test_client()` for HTTP-level tests and `app.test_request_context()` for unit tests.
+-   Use pytest fixtures to create the app and client; scope appropriately (`session` for the app, `function` for the client).
+-   Set `TESTING=True` and use a separate test database.
+
+## Pitfalls
+
+-   Never use the development server (`app.run()`) in production — use Gunicorn or uWSGI.
+-   Avoid storing mutable state on the `app` object; use `g` for request-scoped data.
+-   Never hardcode `SECRET_KEY` — load from environment variables.

.claude/skills/jinja2/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: jinja2
+description: Best practices for template rendering with Jinja2 including environments, filters, autoescaping, and security.
+---
+
+# Skill: Jinja2
+
+Best practices for template rendering with Jinja2 including environments, filters, autoescaping, and security.
+
+## When to Use
+
+Apply this skill when rendering templates with Jinja2 — HTML pages, emails, configuration files, and code generation.
+
+## Environment
+
+-   Create a `jinja2.Environment(loader=..., autoescape=...)` once and reuse it.
+-   Use `FileSystemLoader` for file-based templates, `PackageLoader` for installed packages.
+-   Enable `autoescape=True` for HTML templates to prevent XSS.
+
+## Templates
+
+-   Use `{{ variable }}` for output, `{% if/for/block %}` for control flow.
+-   Use template inheritance (`{% extends 'base.html' %}`) for layout reuse.
+-   Define custom filters for reusable transformations.
+
+## Security
+
+-   **Always** enable `autoescape=True` when rendering HTML.
+-   Use `SandboxedEnvironment` for untrusted templates.
+-   Never render user input as template code — only as template data.
+-   Use `|e` filter explicitly when autoescape is off.
+
+## Pitfalls
+
+-   Don't use `Template(string)` directly — it bypasses the environment's loader and settings.
+-   Watch for undefined variable errors — use `undefined=StrictUndefined` during development.
+-   Avoid complex logic in templates — keep them focused on presentation.

.claude/skills/numpy/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: numpy
+description: Best practices for numerical computing with NumPy including arrays, broadcasting, and vectorization.
+---
+
+# Skill: NumPy
+
+Best practices for numerical computing with NumPy including arrays, broadcasting, and vectorization.
+
+## When to Use
+
+Apply this skill when doing numerical computing with NumPy — arrays, broadcasting, linear algebra, random sampling.
+
+## Arrays
+
+-   Use explicit dtypes (`np.float64`, `np.int32`) when creating arrays.
+-   Prefer `np.zeros`, `np.ones`, `np.empty`, `np.arange`, `np.linspace` over list-based construction.
+-   Use structured arrays or separate arrays instead of object arrays.
+
+## Vectorization
+
+-   Replace Python loops with vectorized NumPy operations wherever possible.
+-   Use broadcasting rules to operate on arrays of different shapes without explicit expansion.
+-   Use `np.where()` for conditional element-wise operations.
+
+## Memory
+
+-   Use `np.float32` instead of `np.float64` when precision is not critical to halve memory.
+-   Use views (`reshape`, slicing) instead of copies when data doesn't need mutation.
+-   Use `np.memmap` for arrays too large to fit in RAM.
+
+## Random
+
+-   Use `np.random.default_rng(seed)` (new Generator API) instead of `np.random.seed()`.
+-   Always seed random generators in tests for reproducibility.
+
+## Pitfalls
+
+-   Don't compare floats with `==`; use `np.allclose()` or `np.isclose()`.
+-   Beware of silent integer overflow in integer arrays.
+-   Avoid `np.matrix` — it's deprecated; use 2D `np.ndarray`.

.claude/skills/pytest/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: pytest
+description: Best practices for writing and organizing tests with pytest including fixtures, parametrize, and plugins.
+---
+
+# Skill: pytest
+
+Best practices for writing and organizing tests with pytest including fixtures, parametrize, and plugins.
+
+## When to Use
+
+Apply this skill when writing and organizing tests with pytest — fixtures, parametrize, markers, plugins, and test structure.
+
+## Test Organization
+
+-   Place tests in a `tests/` directory mirroring the source structure.
+-   Name test files `test_<module>.py` and test functions `test_<behavior>()`.
+-   Group related tests in classes only when they share fixtures/setup.
+
+## Fixtures
+
+-   Define fixtures at the narrowest scope needed (`function` > `class` > `module` > `session`).
+-   Use `conftest.py` for shared fixtures; put it at the appropriate directory level.
+-   Prefer factory fixtures over complex fixture inheritance.
+-   Use `yield` fixtures for setup/teardown; prefer `tmp_path` over `tempfile`.
+
+## Parametrize
+
+-   Use `@pytest.mark.parametrize` for data-driven tests with multiple inputs.
+-   Give test IDs (`ids=...`) for readable test output.
+-   Combine `parametrize` with fixtures for cross-product testing.
+
+## Assertions
+
+-   Use plain `assert` statements — pytest rewrites them for clear failure messages.
+-   Use `pytest.raises(ExceptionType, match=...)` for exception testing.
+-   Use `pytest.approx()` for floating-point comparisons.
+
+## Plugins
+
+-   Common plugins: `pytest-cov`, `pytest-mock`, `pytest-asyncio`, `pytest-xdist`, `pytest-timeout`.
+-   Use `pytest-mock`'s `mocker` fixture over raw `unittest.mock.patch`.
+
+## Pitfalls
+
+-   Don't use `session`-scoped fixtures for mutable state.
+-   Don't assert on implementation details — test observable behavior.
+-   Avoid test interdependence; each test should be runnable in isolation.

.claude/skills/requests/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: requests
+description: Best practices for HTTP client usage with Requests including sessions, error handling, and timeouts.
+---
+
+# Skill: Requests
+
+Best practices for HTTP client usage with Requests including sessions, error handling, and timeouts.
+
+## When to Use
+
+Apply this skill when making HTTP requests with the Requests library — sessions, auth, error handling, retries, and file uploads.
+
+## Sessions
+
+-   Use `requests.Session()` for connection pooling and persistent headers/cookies across multiple requests.
+-   Configure `session.headers` for default auth tokens and user-agent strings.
+-   Use `session.mount()` with `HTTPAdapter` for retry logic.
+
+## Error Handling
+
+-   Always call `response.raise_for_status()` to surface HTTP errors as exceptions.
+-   Always set `timeout=(connect_timeout, read_timeout)` — never use infinite timeouts.
+-   Handle `requests.ConnectionError`, `requests.Timeout`, and `requests.HTTPError` explicitly.
+
+## Retries
+
+-   Use `urllib3.util.Retry` with `HTTPAdapter` for automatic retries with backoff.
+-   Configure status-based retries for transient errors (429, 500, 502, 503, 504).
+
+## Security
+
+-   Never disable SSL verification (`verify=False`) in production.
+-   Pass credentials via environment variables, not hardcoded strings.
+-   Use `auth=` parameter for HTTP auth rather than manually setting headers.
+
+## Pitfalls
+
+-   Don't forget timeouts — they default to None (infinite wait).
+-   Don't use `requests.get()` for high-throughput — use sessions.
+-   Close responses from streaming requests (`stream=True`) to release connections.