Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/mathisk2095/jko-claude-plugins/python-backend-expertnpx skills add mathisk2095/jko-claude-plugins --skill python-backend-expertgit clone --depth 1 https://github.com/mathisk2095/jko-claude-pluginsWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00183 | $0.02642 |
| Opus 5 | $0.00092 | $0.01321 |
| Sonnet 5 | $0.00037 | $0.00528 |
| Haiku 4.5 | $0.00018 | $0.00264 |
Grade A, and why
python-backend-expert scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 175 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write production-grade Python backends. Not scripts. Not notebooks. Not prototypes. Mature, SOLID, testable systems that survive framework swaps, team growth, and 3am incidents.
Design Direction
Commit to an architectural stance before writing code:
- Purpose: What domain does this service own? What is its single bounded context?
- Boundaries: Where does the domain end and infrastructure begin? Draw the line.
- DI Strategy: How do dependencies flow? Constructor injection, framework DI, or container?
- Data Flow: Request -> Controller -> Service -> Repository -> Domain Entity -> Response DTO. Never skip layers.
CRITICAL: The architecture serves the domain, not the framework. If replacing Litestar with FastAPI would require rewriting business logic, the boundaries are wrong.
Architecture
Consult architecture reference for hexagonal patterns, layer rules, and directory structure.
Dependencies point inward. Domain imports nothing from infrastructure. Controllers are thin. Services orchestrate. Repositories hide persistence. The composition root wires everything together.
DO: Separate domain entities from ORM models with explicit mapping
DO: Use Protocol or ABC for all ports -- repository interfaces, encryption, email, external APIs
DO: Keep controllers under 150 lines -- they parse input, call a service, shape output
DON'T: Import SQLAlchemy in your domain layer
DON'T: Put business logic in route handlers -- that's a fat controller (AP-01)
DON'T: Let framework types (Request, Response, AsyncSession) leak into services
SOLID Principles
Consult SOLID reference for Python-specific patterns and file size guidelines.
Every class has one reason to change. New behavior arrives via new code, not modified old code. Subtypes honor parent contracts. Interfaces stay small. High-level modules depend on abstractions.
DO: Split services by domain -- UserService, OrderService, not AppService
DO: Use Protocol for structural typing at boundaries -- no inheritance required
DO: Inject abstractions, never concretions
DON'T: Create god modules >500 lines -- split by responsibility
DON'T: Add raise NotImplementedError stubs -- that's ISP violation, split the interface
DON'T: Pass concrete repository classes through your service constructors
What ships with it
13 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
- references/ai-slop.md 11 KB
- references/anti-patterns.md 8.5 KB
- references/api-design.md 5.8 KB
- references/architecture.md 4.0 KB
- references/async-patterns.md 5.3 KB
- references/dependency-injection.md 5.5 KB
- references/error-handling.md 4.9 KB
- references/modern-python.md 9.6 KB
- references/project-structure.md 9.8 KB
- references/repository-patterns.md 6.9 KB
- references/solid-principles.md 6.0 KB
- references/sqlalchemy.md 5.8 KB
- references/testing.md 4.6 KB
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 175 lines · 183 tokens per session scan A 0fda8fa2775c
python-backend-expert is a skill published in the GitHub repository mathisk2095/jko-claude-plugins (3 stars, last pushed 4d ago), licensed MIT. It adds 183 tokens to every session and 2,642 once invoked, about $0.0009 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
swiftui-expert
This skill should be used when SwiftUI work requires judgment about Observation and state ownership, view identity or lifecycle, navigation, app-target concurrency, persistence, Apple-platform behavior, accessibility, performance, or architecture. Trigger on "review this SwiftUI screen", "why isn't this view…
python-project
Scaffold and modernize a Python project with uv. Sets up the src/ layout; a pyproject.toml on uv's native uvbuild backend; runtime deps plus a dev dependency group (PEP 735) pinning developer tooling like ruff, ty (or pyright), and pytest; a committed uv.lock and pinned interpreter; a thin main entry point; and a…
python-typing
Python static typing and type annotations, checked with a static type checker — ty (Astral) or pyright (Microsoft/Pylance). Use when adding, writing, or reviewing type hints or annotations on Python functions, methods, parameters, or return values; adding return type annotations across a module; fixing or resolving…
python-style
Modern Python house style: ruff is the single formatter and linter (replacing black, isort, flake8, pylint, pyupgrade) with an opinionated lint select set, plus idioms ruff cannot enforce — pathlib over os.path, module-level logging instead of print, specific chained exceptions, dataclasses for data, comprehensions…
python-testing
Python test authoring and review with pytest. Use when writing, adding, generating, or reviewing Python tests or unit tests for a function, module, or class; running pytest or a single test (the -k flag and other invocation flags for a Makefile or CI); parametrizing test cases into the table-driven pattern; setting up…
milp-modeling-gurobi
When the user wants to build, solve, and debug mixed-integer linear programs in Python with Gurobi — creating variables, writing constraint-builder functions, setting objectives and parameters, handling solver status, and extracting solutions safely. Also use when the user mentions "gurobipy," "build a MIP model,"…