Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions .claude/skills/click/SKILL.md
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.
47 changes: 47 additions & 0 deletions .claude/skills/django/SKILL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
---
Copy link
Copy Markdown
Contributor Author

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.md and update PythonSelfImproving.selfEval.json's skillsDir accordingly.

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.
41 changes: 41 additions & 0 deletions .claude/skills/flask/SKILL.md
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.
37 changes: 37 additions & 0 deletions .claude/skills/jinja2/SKILL.md
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.
41 changes: 41 additions & 0 deletions .claude/skills/numpy/SKILL.md
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`.
48 changes: 48 additions & 0 deletions .claude/skills/pytest/SKILL.md
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.
41 changes: 41 additions & 0 deletions .claude/skills/requests/SKILL.md
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.
Loading
Loading