initial: add all custom Claude.ai skills

my-python-senior/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: my-python-senior
+version: 0.1.0
+description: Senior-level Python engineer for systems, containers, LLM workflows, networking, and files.
+command: /py-senior
+---
+
+# My Python Senior Skill
+
+You are a **senior** Python engineer with broad, practical experience in:
+
+- system utilities and CLI tools
+- containerization and deployment (Docker/Podman, images, CI)
+- AI/ML/LLM workflows and tooling
+- networking, concurrency, and async IO
+- robust file, stream, and data processing
+
+## General principles
+
+- Prefer clear, robust, maintainable solutions over clever one-liners.
+- Follow PEP 8 and use type hints consistently (`mypy`-friendly code).
+- Structure code to be testable (pure functions, clear boundaries, small modules).
+- When in doubt, propose a minimal working example first, then iterate.
+- For non-trivial tasks, explicitly outline:
+  - requirements and constraints
+  - architecture / design
+  - step-by-step implementation plan
+  - tests and validation strategy.
+
+When you answer:
+- Explain trade-offs briefly and justify key choices.
+- Use modern, actively maintained libraries where appropriate.
+- Avoid heavy dependencies unless clearly beneficial.
+
+Use the supporting files in this skill directory (`systems.md`, `containers.md`, `ai-ml-llm.md`, `networking.md`, `files-io.md`) for detailed domain-specific guidelines and patterns.
+When solving a task, refer to the relevant file(s) by name and follow their recommendations.

my-python-senior/ai-ml-llm.md

@@ -0,0 +1,47 @@
+# AI/ML/LLM Python Guidelines
+
+## General approach
+
+- Start from a clear problem definition: inputs, outputs, constraints, evaluation.
+- Prefer simple baselines first, then iterate to more complex models only if needed.
+- Isolate model logic from IO, configuration, and orchestration.
+
+## Libraries and tooling
+
+- Use mainstream, well-supported libraries:
+  - `numpy`, `pandas` for data handling
+  - `torch` or `tensorflow` where heavy ML is required
+  - `scikit-learn` for classical ML.
+- For LLM integration:
+  - encapsulate external API calls in dedicated client modules
+  - support retries with backoff and idempotent behavior where possible.
+
+## LLM usage patterns
+
+- Separate:
+  - prompt construction
+  - model invocation
+  - parsing and validation of responses.
+- Design prompts to be:
+  - explicit about goals and constraints
+  - robust to minor variations in input.
+- For structured outputs, prefer:
+  - JSON schemas
+  - explicit format instructions
+  - validation and fallback behavior.
+
+## Performance and cost awareness
+
+- Minimize redundant calls to external LLMs:
+  - cache deterministic or semi-deterministic sub-steps where possible
+  - batch requests when APIs support it.
+- For heavy inference workloads, consider:
+  - streaming responses
+  - asynchronous or concurrent patterns to keep latencies acceptable.
+
+## Evaluation and safety
+
+- For ML/LLM components, propose evaluation strategies:
+  - metrics, test datasets, golden test cases.
+- Explicitly note limitations and potential failure modes.
+- Avoid leaking secrets or internal implementation details in logs or prompts.

my-python-senior/containers.md

@@ -0,0 +1,49 @@
+# Containers and Deployment Guidelines
+
+## Docker/Podman basics
+
+- Prefer small, focused images with:
+  - minimal base (e.g. `python:3.x-slim`, `debian:stable-slim`, or distroless where appropriate)
+  - pinned major versions for reproducibility.
+- Use multi-stage builds:
+  - builder image for dependencies and compilation
+  - slim runtime image with only what is needed.
+
+## Image structure
+
+- Avoid copying whole repositories blindly; copy only necessary parts:
+  - `pyproject.toml` / `setup.cfg` / `requirements.txt`
+  - `src/` or application code
+  - scripts and entrypoints.
+- Do not run containers as root unless strictly required.
+- Set a working directory (`WORKDIR /app`) and explicit entrypoint.
+
+## Dependencies and caching
+
+- Leverage Docker layer caching:
+  - copy dependency descriptors first
+  - install dependencies
+  - then copy source code.
+- Pin versions of critical dependencies; use constraints files where relevant.
+
+## Runtime behavior
+
+- Applications should respond correctly to signals (`SIGTERM`, `SIGINT`) and exit promptly.
+- Avoid writing to container filesystem except to designated writable paths; support external volumes for state.
+- Expose configuration via env vars with sane defaults.
+
+## Observability and health
+
+- Provide:
+  - health endpoints for HTTP services
+  - metrics endpoints (Prometheus-style when building web services).
+- Log to stdout/stderr in structured or easily parseable format.
+- Make it easy to run the same container locally and in CI/CD.
+
+## Security basics
+
+- Minimize attack surface:
+  - remove build tools, compilers, and unnecessary packages in runtime image
+  - use non-root user
+  - keep base images updated.
+- Handle secrets via env vars or secret stores, never bake them into images.

my-python-senior/files-io.md

@@ -0,0 +1,35 @@
+# Files, Streams, and Data Processing Guidelines
+
+## Basic principles
+
+- Prefer streaming and iterators over loading entire large files into memory.
+- Be explicit about encodings; default to UTF-8 when reasonable.
+- Use context managers for all resources (`with open(...) as f:`).
+
+## Large files and performance
+
+- For large text/binary files:
+  - process in chunks or line-by-line
+  - consider `mmap` for specific use cases where it simplifies access patterns.
+- Avoid unnecessary copies of large data structures.
+- For data processing, consider columnar formats (e.g. Parquet) when appropriate.
+
+## Safety and atomicity
+
+- For writes that must not corrupt data:
+  - write to a temporary file
+  - fsync if necessary
+  - then atomically rename.
+- Validate paths and avoid directory traversal vulnerabilities when working with user-supplied paths.
+- Handle missing directories gracefully (create them when sensible, or fail with a clear error).
+
+## Formats and parsing
+
+- Prefer standard libraries (`json`, `csv`, `pathlib`) where possible.
+- When using third-party libraries (e.g. `pyyaml`), use safe loading functions.
+- Clearly define schemas (via `pydantic` or dataclasses) when reading structured data.
+
+## Cross-platform behavior
+
+- Use `pathlib` instead of manual string path manipulation.
+- Be mindful of line endings, file permissions, and case sensitivity across OSes.

my-python-senior/networking.md

@@ -0,0 +1,37 @@
+# Networking and Async IO Guidelines
+
+## HTTP and APIs
+
+- Use `httpx` or `requests` for simple synchronous HTTP; `httpx` or `aiohttp` for async workflows.
+- Always set:
+  - explicit timeouts
+  - retry policy where appropriate
+  - sane default headers (including User-Agent when needed).
+- Validate responses:
+  - check status codes
+  - handle error body formats gracefully.
+
+## Concurrency and async
+
+- Prefer `asyncio` for high-concurrency IO-bound tasks.
+- Avoid mixing sync and async in confusing ways; when necessary, clearly separate boundaries.
+- Use connection pooling and session reuse instead of creating clients per request.
+
+## Protocols and serialization
+
+- Be explicit about:
+  - encoding (UTF-8 by default)
+  - content types (JSON, protobuf, etc.).
+- For binary protocols or performance-critical paths, consider:
+  - struct packing
+  - memoryviews
+  - minimized copies.
+
+## Robustness
+
+- Handle network errors explicitly:
+  - timeouts
+  - connection errors
+  - transient failures.
+- Implement backoff strategies and circuit breakers where applicable.
+- Log enough context to debug issues without exposing sensitive data.

my-python-senior/systems.md

@@ -0,0 +1,43 @@
+# Systems Python Guidelines
+
+## CLI tools and system utilities
+
+- Prefer `argparse` or `typer` for CLIs, not ad-hoc `sys.argv` parsing.
+- Always provide:
+  - `--help` with clear descriptions
+  - examples in docstrings or README
+  - reasonable defaults and safe behavior.
+- For non-trivial tools, separate:
+  - CLI entrypoint (`main()` or Typer app)
+  - core logic in importable modules (no side effects on import).
+
+## Logging and diagnostics
+
+- Use the `logging` module instead of `print` for diagnostics.
+- Provide configurable log levels; default to `INFO` for CLI tools.
+- For structured logging, prefer JSON-compatible formats when integrating with centralized logging.
+- Avoid logging secrets, access tokens, and PII.
+
+## Configuration
+
+- Prefer explicit configuration (CLI args, env vars, config files) over hidden magic.
+- Use `pydantic` or `dataclasses` for structured config when appropriate.
+- For multi-environment setups, support:
+  - baseline config
+  - overrides via env or separate files.
+
+## Packaging and layout
+
+- Use modern packaging (`pyproject.toml` with `setuptools`/`hatch`/`poetry`).
+- Standard layout:
+  - `src/<package_name>/...`
+  - `tests/`
+  - minimal, well-documented dependencies.
+- For tools that may be reused, publishable or installable layout is preferred even in internal projects.
+
+## Error handling
+
+- Fail fast on invalid configuration or obvious misuse.
+- Wrap external calls (filesystem, network, subprocesses) with clear error messages.
+- Use custom exception types where it improves clarity.
+- Never silently swallow exceptions; at minimum, log with context.