Python runtime operations
Use when building or reviewing service, job, or CLI runtime behavior in Python — designing startup validation, shutdown sequences, observability, and structured logging. Also use when startup crashes from late config, shutdown leaves orphaned processes, terminal states are implicit, or logs lack structure.From its SKILL.md
npx -y skills add ahgraber/skills --skill python-runtime-operationsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.3 KB, 581 tokens by cl100k_base, as published. Nobody here has run it
Python Runtime Operations
Overview
Every service, worker, and CLI entrypoint must validate its environment before doing real work, shut down cleanly under all exit paths, and emit structured signals that make runtime behavior observable. Treat these as preferred defaults — deviate when project constraints demand it, but call out tradeoffs and compensating controls.
When to Use
- Startup fails late because config is validated after work begins.
- Shutdown leaves open connections, orphaned subprocesses, or incomplete transactions.
- Job retries run forever with no dead-letter or terminal-state handling.
- Logs are unstructured, missing correlation IDs, or inconsistent across services.
- Health and readiness probes are missing or misleading.
- Signal handling (SIGTERM, SIGINT) is absent or racy.
When NOT to Use
- Pure library or data-model code with no process lifecycle concerns.
- Build, packaging, or CI/CD pipeline configuration.
- Algorithm or business-logic design with no runtime surface.
Quick Reference
- Validate all runtime config at startup; fail fast with clear errors before doing real work.
- Register signal handlers and ensure graceful shutdown with bounded cleanup timeouts.
- Make retry limits, backoff, and dead-letter/terminal-state behavior explicit in every job system.
- Emit structured logs (JSON) with consistent severity levels and correlation IDs.
- Expose health, readiness, and liveness probes that reflect actual dependency state.
- Track core runtime signals: startup latency, queue depth, error rates, shutdown duration.
Common Mistakes
- Validating config lazily — checking environment variables or secrets on first use instead of at startup, causing failures minutes or hours into a run.
- Unbounded cleanup — shutdown handlers that wait forever on draining connections or flushing buffers, turning a clean restart into a hung process.
- Silent retry exhaustion — retrying failed jobs indefinitely without logging terminal failures or routing to a dead-letter queue.
- Logging without structure — using plain-text
printor unstructuredlogging.infocalls that cannot be parsed, filtered, or correlated in production. - Health probes that lie — returning 200 OK from a health endpoint without checking downstream dependencies, masking cascading failures.
Scope Note
- Treat these recommendations as preferred defaults for common cases, not universal rules.
- If a default conflicts with project constraints or worsens the outcome, suggest a better-fit alternative and explain why it is better for this case.
- When deviating, call out tradeoffs and compensating controls (tests, observability, migration, rollback).
Invocation Notice
- Inform the user when this skill is being invoked by name:
python-design-modularity.
References
references/runtime-behavior.mdreferences/logging-metrics-tracing.mdreferences/process-lifecycle-and-cleanup.md
What ships with it: 3 files
4.2 KB alongside SKILL.md
references/
Gives 0 of the 12 instructions most operations skills give in 581 tokens
Counted across 483 of the 484 authors here whose files we hold, read 2026-08-07
- Collect monitoring data throughout the simulationin 14 of 483, across 6 files
- Set the random seed for reproducibilityin 14 of 483, across 6 files
- Validate simulations against analytical solutionsin 12 of 483, across 4 files
- Clarify goals, constraints, and inputsin 11 of 483, across 2 files
- Implement contract tests for integration pointsin 11 of 483, across 2 files
- Implement strangler fig infrastructure with API gatewayin 11 of 483, across 2 files
- Audit modernized components for security vulnerabilitiesin 11 of 483, across 2 files
- Avoid Python blocking calls in processesin 10 of 483, across 3 files
- Use resource context managers for automatic cleanupin 9 of 483, across 2 files
- Maintain consistent time unitsin 9 of 483, across 2 files
- Validate outcomes against success criteriain 8 of 483, across 1 file
- Analyze the legacy codebase for technical debtin 8 of 483, across 1 file
Said here and by no other author read
- validate all runtime config at startup
- register signal handlers for graceful shutdown
- bound cleanup timeouts during shutdown
- make retry limits and dead-letter behavior explicit
- emit structured JSON logs with correlation IDs
- expose health, readiness, and liveness probes
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.