ahgraber/python-integrations-resilience
skills/python-integrations-resilience/SKILL.md
Use when building or reviewing external API integrations in Python — designing client boundaries, defining outbound reliability policy, or structuring contract tests. Also use when provider SDK details leak into domain logic, outbound calls lack timeout/retry policy, or failure paths are untested.
tools
Updated Mar 29, 2026
$ install --global
skillsauthnpx skillsauth add ahgraber/skills python-integrations-resilienceInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Mar 31, 2026, 8:36 PM56.7s4 files scanned
SKILL.md
- name:
- python-integrations-resilience
- description:
- |-
Python Integrations and Resilience
Overview
External integrations stay reliable when provider-specific details hide behind explicit client boundaries, and every outbound operation carries a defined reliability policy that is tested against both success and failure paths.
Treat these recommendations as preferred defaults. When project constraints demand deviation, call out tradeoffs and compensating controls (tests, observability, rollback).
When to Use
- Designing or reviewing client boundaries around external APIs or provider SDKs.
- Adding or auditing timeout, retry, or idempotency policy on outbound calls.
- Writing contract or resilience tests for provider integrations.
- Diagnosing contract drift between a client wrapper and the upstream provider.
- Refactoring domain logic that has coupled itself to a specific provider SDK.
When NOT to Use
- Pure in-process library calls with no network or I/O boundary.
- Internal module interfaces that carry no external contract risk.
- Performance tuning of already-isolated integrations (see
python-concurrency-performance).
Quick Reference
- Hide provider-specific details behind explicit client boundaries.
- Keep domain logic isolated from provider SDK specifics.
- Require explicit timeout/retry/idempotency policy for every outbound operation.
- Test both contract mapping and failure behavior directly.
Common Mistakes
- Letting provider types cross the boundary — returning raw SDK response objects into domain code couples the entire codebase to one provider.
- Implicit or missing timeouts — relying on library defaults (or no timeout at all) turns a slow upstream into a cascading failure.
- Retrying non-idempotent calls — retrying a POST without an idempotency key risks duplicate side effects.
- Testing only the happy path — skipping timeout, rate-limit, and malformed-response scenarios leaves the most likely production failures uncovered.
- Hardcoding retry policy — embedding backoff constants deep in client code prevents tuning without a redeploy.
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/client-patterns.mdreferences/request-reliability-policy.mdreferences/resilience-and-contract-testing.md
Related Skills
ahgraber/editorial-review
development
VerifiedTrustedCommunity
Use when the user wants rigorous, non-sycophantic editorial feedback on a draft, essay, blog post, or argument through back-and-forth dialogue — pressure-testing thesis, structure, argument, clarity, tone, and evidence. Triggers: "be my sparring partner", "pressure-test this draft", "poke holes in my argument", "is this ready to publish", "sharpen this post", "where is this weak". Not for one-shot copyediting, proofreading, or ghostwriting.
2SKILL.mdUpdated May 26, 2026
ahgraber/synthesize
testing
VerifiedTrustedCommunity
Use when distilling the through-line gist of one or more sources — the spine, argument, tension, or recurring frame running through a set of documents, notes, research, or transcripts, OR across the ideas within a single rich piece — into a few concise paragraphs. Triggers: "synthesize", "what's the through-line/gist", "extract the insight", "pull these together". Not for faithful summary or condensation that covers what a source says, nor for comparisons or catalogs where enumeration is the deliverable.
2SKILL.mdUpdated May 22, 2026
ahgraber/writing-tests
development
VerifiedTrustedCommunity
Use when writing or reviewing tests in any language, or diagnosing a suite that is slow, brittle, or hard to read. Triggers: "write tests", "how should I test this", "what kind of test", "test is flaky/fragile", "should I mock this", "test is hard to read". For Python-specific guidance see `python-testing`.
2SKILL.mdUpdated May 16, 2026
ahgraber/strudel
development
VerifiedTrustedCommunity
Use when writing, debugging, or explaining Strudel live-coding music patterns — mini-notation syntax, pattern functions (fast/slow/every/off/stack), synth/sample selection, audio effects, scale/chord/voicing API, or EDM production recipes. Triggers: "write a Strudel pattern", "how do I make a bassline in Strudel", "what does .every() do", "strudel drum beat", "strudel chord voicing", any Strudel code question.
2SKILL.mdUpdated May 16, 2026