-
Notifications
You must be signed in to change notification settings - Fork 191
Add option for ignore all system exit codes #2017
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
69f3b19
Add option for ignore all system exit codes
rchiodo 30046f4
Change to Pavel's suggestion
rchiodo 919710b
More checking
rchiodo 176ab2e
Fix whitespace
rchiodo 7b6873b
Add test for range scenario
rchiodo 960c164
Review feedback
rchiodo File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. | ||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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`. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. |
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot generated:
📍 .github/skills/django/SKILL.md (and all 7 skill files)
The Rules reviewer found these skill files are under
.github/skills/instead of the repo-canonical.claude/skills/directory. The customization loader is scoped to.claude/skills/*/SKILL.md, so these files won't be discovered. Move all seven to.claude/skills/<name>/SKILL.mdand updatePythonSelfImproving.selfEval.json'sskillsDiraccordingly.