anantbhandarkar
UserMake It Right — constraint-first backend reliability skills for AI coding agents. 3 tiers (generic → runtime → framework) across 9 runtimes; stops AI shipping confident-but-wrong backend code. Apache-2.0.
Categories
Indexed Skills (31)
mir-backend-beam-phoenix
Make It Right (Phoenix module). Phoenix + LiveView + Ecto + PostgreSQL specific reliability augmentation. Use alongside mir-backend and mir-backend-beam when the target stack is Phoenix — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: LiveView per-connection process memory scaling and temporary_assigns/streams for large collections, blocking the LiveView process in handle_event freezing the client, Ecto N+1 with unloaded associations raising DetachedInstanceError, migration safety on populated tables (create index concurrently, disable_ddl_transaction!, expand/contract for NOT NULL), PubSub fan-out backpressure, and idempotent handle_event for double-click races. TRIGGER only when the BEAM backend stack is Phoenix — building, reviewing, or debugging a Phoenix controller, LiveView, Ecto query, or migration. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-beam (BEAM runtime concerns: supervision, mailbox growth, GenServer bottlenecks, ETS, distributed
mir-backend-beam
Make It Right (BEAM runtime tier). Erlang VM / BEAM reliability footguns shared across every BEAM-based backend (Phoenix, Nerves, pure Erlang) — distinct from the generic backend gates and from any one framework's mechanics. Covers: let-it-crash + supervision tree design (restart strategies, poison-message crash-loops), unbounded mailbox growth and backpressure (GenStage/Broadway/synchronous call), hot GenServer as a serial bottleneck and when to use ETS instead, blocking handle_call timing out callers and queuing all others, isolated per-process heap and how to share state (messages / ETS / persistent_term), and distributed Erlang hazards (netsplits, :global name clashes, pairwise ordering). TRIGGER when the backend runtime is Elixir or Erlang — sits between mir-backend (generic) and the framework module (e.g. mir-backend-beam-phoenix). SKIP for Python, Node, Go, JVM, Rust, .NET, Ruby, PHP runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics (those live in the framework
mir-backend-dotnet-aspnetcore
Make It Right (ASP.NET Core module). ASP.NET Core + Minimal APIs + EF Core + Entity Framework migrations specific reliability augmentation. Use alongside mir-backend and mir-backend-dotnet when the target stack is ASP.NET Core or Minimal APIs — it carries the mechanical footguns the runtime-agnostic tiers deliberately omit: DI lifetime errors in practice (AddDbContext Scoped vs singleton capture, IHttpContextAccessor caveats), middleware pipeline ORDER (UseRouting → UseAuthentication → UseAuthorization → endpoints; wrong order silently disables auth), model binding overposting / mass assignment onto EF entities, response DTO discipline to prevent field leakage, EF Core N+1 (lazy loading raises in async contexts, use Include/projection/AsNoTracking), async-all-the-way in endpoints with CancellationToken from the request, object-level authorization (IDOR via valid token without resource check), antiforgery for cookie auth, and the Options pattern for config. TRIGGER only when the .NET backend stack uses ASP.NET
mir-backend-dotnet
Make It Right (.NET runtime tier). CLR/CoreCLR runtime reliability footguns shared across EVERY .NET backend framework (ASP.NET Core, Minimal APIs, gRPC, Blazor Server, SignalR, background services) — distinct from the generic backend gates and from any one framework's mechanics. Covers: sync-over-async deadlock and thread-pool starvation (.Result/.Wait()/.GetAwaiter().GetResult()), ConfigureAwait(false) in library code, ValueTask misuse, thread-pool saturation under load, IDisposable/using discipline, DbContext thread-safety and lifetime, DI captive dependency (Scoped/Transient injected into Singleton), CancellationToken propagation, and large-object heap pressure. TRIGGER when the backend runtime is .NET / CLR — any C# or F# service. SKIP for Node/JVM/Go/Rust/Python/Ruby/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics (those live in mir-backend-dotnet-<framework>).
mir-backend-go-echo
Make It Right (Echo module). Echo web framework reliability augmentation for Go backends. Use alongside mir-backend and mir-backend-go when the target stack is Echo — adds the mechanical footguns the runtime-agnostic tiers deliberately omit: echo.Context is request-scoped and must not be retained across the handler boundary or passed to a goroutine without copying values, Bind + Validator separation (Bind alone does not validate — you must install a custom Validator and call Validate explicitly), middleware ordering (Recover() before your middleware), HTTPErrorHandler for consistent error shape, and graceful shutdown via e.Shutdown(ctx). TRIGGER only when the Go backend uses the Echo framework — building, reviewing, or debugging an Echo handler, middleware, or router. Always loads TOGETHER WITH mir-backend (generic gates) and mir-backend-go (Go runtime concerns: goroutine leaks, context propagation, data races, channel rules, typed-nil, defer-in-loop, slice aliasing, error discipline, WaitGroup); this module
mir-backend-go-fiber
Make It Right (Fiber module). Fiber web framework reliability augmentation for Go backends. Use alongside mir-backend and mir-backend-go when the target stack is Fiber — adds the mechanical footguns the runtime-agnostic tiers deliberately omit: fiber.Ctx and all its values (Body, Params, Headers) are pooled and reused after the handler returns (retaining them causes data corruption across requests), fasthttp incompatibility with net/http middleware and ecosystem, the Immutable setting that controls whether returned strings reference reused buffers, and graceful shutdown via app.ShutdownWithContext. TRIGGER only when the Go backend uses the Fiber framework — building, reviewing, or debugging a Fiber handler, middleware, or route. Always loads TOGETHER WITH mir-backend (generic gates) and mir-backend-go (Go runtime concerns: goroutine leaks, context propagation, data races, channel rules, typed-nil, defer-in-loop, slice aliasing, error discipline, WaitGroup); this module only adds Fiber library mechanics. SKIP
mir-backend-go-gin
Make It Right (Gin module). Gin web framework reliability augmentation for Go backends. Use alongside mir-backend and mir-backend-go when the target stack is Gin — adds the mechanical footguns the runtime-agnostic tiers deliberately omit: *gin.Context is request-scoped and must be copied before passing to a spawned goroutine, binding and validation discipline (ShouldBindJSON + struct tags, separate request vs DB model), middleware ordering (Recovery before your handlers), missing graceful shutdown wiring (http.Server.Shutdown on SIGTERM), and route group auth guard placement. TRIGGER only when the Go backend uses the Gin framework — building, reviewing, or debugging a Gin handler, middleware, or router. Always loads TOGETHER WITH mir-backend (generic gates) and mir-backend-go (Go runtime concerns: goroutine leaks, context propagation, data races, channel rules, typed-nil, defer-in-loop, slice aliasing, error discipline, WaitGroup); this module only adds Gin library mechanics. SKIP for Fiber, Echo, chi, stdlib
mir-backend-go
Make It Right (Go runtime tier). Go 1.22+ runtime reliability footguns shared across every Go backend framework (Gin, Fiber, Echo, chi, stdlib net/http) — distinct from the generic backend gates and from any one framework's mechanics. Covers: goroutine leaks (the #1 Go reliability bug), context propagation and cancellation, data races on shared state, channel ownership rules, goroutine-level panic recovery, the nil-interface/nil-pointer trap, defer-in-loop resource buildup, slice aliasing and backing-array mutation, error wrapping discipline, and sync.WaitGroup misuse. TRIGGER when the backend runtime is Go — sits between mir-backend (generic) and the framework module (e.g. mir-backend-go-gin). SKIP for Python/Node/JVM/Rust/.NET/Ruby/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics (those live in the framework module).
mir-backend-jvm-micronaut
Make It Right (Micronaut module). Micronaut + Micronaut Data + Micronaut Security + Netty HTTP server reliability footguns specific to this framework stack. Covers: compile-time DI and AOT (no runtime reflection — missing bean is a compile error, not a runtime NPE), bean scope pitfalls (@Singleton default, don't hold request state), blocking the Netty event loop (use @ExecuteOn or reactive types), Micronaut Data repository transaction scoping, reactive types (RxJava / Reactor / Kotlin coroutines) and not blocking the event loop inside them, native-image / GraalVM considerations at the Micronaut layer, and compile-time AOP interceptor limitations. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-jvm (JVM runtime concerns: thread pools, virtual threads, GC, container heap, cold start, JMM visibility, ThreadLocal hygiene); this module only adds Micronaut library mechanics. TRIGGER only when the JVM backend stack is Micronaut — building, reviewing, or debugging a Micronaut controller, service, r
mir-backend-jvm-quarkus
Make It Right (Quarkus module). Quarkus + Hibernate ORM / Panache + RESTEasy / Reactive Routes + SmallRye Mutiny reliability footguns specific to this framework stack. Covers: build-time DI / annotation processing (reflection for GraalVM native image must be registered with @RegisterForReflection or fails only at native runtime), blocking the Vert.x I/O thread on reactive routes (annotate blocking work @Blocking), Mutiny async composition pitfalls (blocking inside Uni/Multi pipelines), build-time vs runtime config key differences, Dev Services, and native-image gotchas (dynamic proxies, serialization, resources). Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-jvm (JVM runtime concerns: thread pools, virtual threads, GC, container heap, cold start, JMM visibility, ThreadLocal hygiene); this module only adds Quarkus library mechanics. TRIGGER only when the JVM backend stack is Quarkus — building, reviewing, or debugging a Quarkus REST resource, CDI bean, Panache entity, Mutiny pipeline, or n
mir-backend-jvm-spring
Make It Right (Spring Boot module). Spring Boot + Spring Data JPA/Hibernate + Spring Security + Spring MVC/WebFlux reliability footguns specific to this framework stack. Covers: @Transactional self-invocation (same-bean call bypasses the proxy → no transaction), checked exceptions not rolling back by default, propagation/isolation pitfalls, JPA/Hibernate N+1 with lazy associations, LazyInitializationException outside the session, OPEN_IN_VIEW antipattern, singleton bean scope storing per-request state, @Async needing an explicit thread pool and swallowing exceptions, @Valid + DTOs against overposting, and Spring Security method-level authorization for object-level checks. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-jvm (JVM runtime concerns: thread pools, virtual threads, GC, container heap, cold start, JMM visibility, ThreadLocal hygiene); this module only adds Spring Boot / Spring Data library mechanics. TRIGGER only when the JVM backend stack is Spring Boot — building, reviewing, or
mir-backend-jvm
Make It Right (JVM runtime tier). Java 21+ / Kotlin runtime reliability footguns shared across EVERY JVM backend framework (Spring Boot, Quarkus, Micronaut, Vert.x) — distinct from the generic backend gates and from any one framework's mechanics. Covers: thread-pool sizing and pool-exhaustion deadlock, blocking I/O on platform threads, Java 21 virtual threads and carrier-thread pinning inside synchronized/native calls, GC pause tuning (G1 vs ZGC/Shenandoah), container-aware heap sizing (-XX:MaxRAMPercentage vs hard -Xmx), cold-start / JIT warmup cost and mitigations (GraalVM native image, CRaC, AOT), shared-mutable-state visibility (happens-before, volatile, final, data races), and ThreadLocal leaks in pooled threads. TRIGGER when the backend runtime is Java or Kotlin — sits between mir-backend (generic gates) and the framework module (e.g. mir-backend-jvm-spring). SKIP for Python, Node, Go, Rust, .NET, Ruby, PHP, BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics
mir-backend-node-express
Make It Right (Express module). Express 4/5 + Node.js specific reliability augmentation. Use alongside mir-backend and mir-backend-node when the target stack is Express — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: async error propagation differences between Express 4 and 5, middleware ordering as a hard contract, the absence of built-in validation and what fills the gap, security headers and CORS off-by-default, and object-level authorization gaps that structural frameworks catch but Express doesn't. TRIGGER only when the Node backend stack is Express — building, reviewing, or debugging an Express route, middleware, or error handler. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-node (V8 event-loop / process-model concerns: blocking, worker_threads, unhandled rejections, backpressure, timeouts); this module only adds Express library mechanics. SKIP for Fastify, NestJS, Hapi, Koa, or any non-Express stack (those get their own mir-backend-node-<f
mir-backend-node-fastify
Make It Right (Fastify module). Fastify 4/5 + Node.js specific reliability augmentation. Use alongside mir-backend and mir-backend-node when the target stack is Fastify — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: schema-first validation and response serialization (and the data-leak risk of skipping it), the reply lifecycle and double-send traps, plugin encapsulation and decorator scoping, and hook-ordering for authentication. TRIGGER only when the Node backend stack is Fastify — building, reviewing, or debugging a Fastify route, plugin, hook, or schema. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-node (V8 event-loop / process-model concerns: blocking, worker_threads, unhandled rejections, backpressure, timeouts); this module only adds Fastify library mechanics. SKIP for Express, NestJS, Hapi, Koa, or any non-Fastify stack (those get their own mir-backend-node-<framework> module), and for non-Node runtimes.
mir-backend-node-nestjs
Make It Right (NestJS module). NestJS + TypeScript specific reliability augmentation. Use alongside mir-backend and mir-backend-node when the target stack is NestJS — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: singleton DI scope bleeding request state across users, the full execution-order pipeline (middleware → guards → interceptors → pipes → handler → interceptors → exception filters), ValidationPipe with whitelist and forbidNonWhitelisted to stop mass assignment, and offloading durable work to a queue (Bull/BullMQ) rather than running it in a request. TRIGGER only when the Node backend stack is NestJS — building, reviewing, or debugging a NestJS controller, provider, guard, pipe, interceptor, or exception filter. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-node (V8 event-loop / process-model concerns: blocking, worker_threads, unhandled rejections, backpressure, timeouts); this module only adds NestJS library mechanics. SKIP for Express, F
mir-backend-node
Make It Right (Node.js runtime tier). V8/Node 20+ LTS runtime reliability footguns that are shared across EVERY Node backend framework (Express, Fastify, NestJS, Hapi, Koa) — distinct from the generic backend gates and from any one framework's mechanics. Covers: the single-threaded event loop and what blocks it (sync I/O, huge JSON, synchronous crypto/zlib, long CPU loops, pathological regex), the absence of CPU parallelism on one process and how to get it (worker_threads / cluster), unhandled promise rejection crashes, serializing awaits in a loop vs. bounded Promise.all concurrency, stream backpressure, AbortController timeouts on every outbound call, uncaughtException semantics, heap limits under container memory, and async-context loss across callbacks and timers. TRIGGER when the backend runtime is Node.js / V8 — sits between mir-backend (generic gates) and the framework module (e.g. mir-backend-node-express). SKIP for Python/JVM/Go/Rust/.NET/Ruby/PHP/BEAM runtimes (each has its own mir-backend-<runtime>
mir-backend-php-laravel
Make It Right (Laravel module). Laravel 10/11 + Eloquent ORM + MySQL/PostgreSQL + Redis + Laravel Queues specific reliability augmentation. Use alongside mir-backend and mir-backend-php when the target stack is Laravel — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: Eloquent N+1 queries, mass assignment via $fillable/$guarded, synchronous vs. queued work, DB::transaction() boundaries and afterCommit event semantics, Octane state bleed from singletons surviving requests, and migration safety on populated tables. TRIGGER only when the PHP backend stack is Laravel — building, reviewing, or debugging a Laravel controller, Eloquent model, Job, migration, or middleware. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-php (Zend Engine runtime concerns: shared-nothing lifecycle, FPM worker model, Octane state bleed, opcache, error model); this module only adds Laravel/Eloquent library mechanics. SKIP for Symfony, WordPress, Slim, or any non-Laravel PHP stac
mir-backend-php-symfony
Make It Right (Symfony module). Symfony 6/7 + Doctrine ORM + PostgreSQL/MySQL + Messenger + API Platform specific reliability augmentation. Use alongside mir-backend and mir-backend-php when the target stack is Symfony — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: Doctrine N+1 via lazy proxies, Unit of Work memory exhaustion in batch loops, EntityManager becoming closed/stale after an exception, service container singleton semantics and request-state bleed, Serializer group discipline to avoid data leaks, Messenger for async/queued work with idempotent handlers, Validator on DTOs, and explicit flush boundaries. TRIGGER only when the PHP backend stack is Symfony — building, reviewing, or debugging a Symfony controller, Doctrine entity/repository, Messenger handler, migration, or service. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-php (Zend Engine runtime concerns: shared-nothing lifecycle, FPM worker model, persistent-runtime state bleed, opca
mir-backend-php
Make It Right (PHP runtime tier). Zend Engine / PHP 8.2+ runtime reliability footguns that are shared across EVERY PHP backend framework (Laravel, Symfony, WordPress, Slim, Lumen) — distinct from the generic backend gates and from any one framework's mechanics. Covers: shared-nothing request lifecycle and why static/global state does not persist, FPM worker model and concurrency = pm.max_children (not threads), long-running runtime modes (Swoole/RoadRunner/FrankenPHP/Octane) and the state-bleed/memory-leak inversion they introduce, max_execution_time and memory_limit per request, opcache correctness in production, persistent DB connection caveats, and PHP's error/exception model in prod. TRIGGER when the backend runtime is PHP — sits between mir-backend (generic) and the framework module (e.g. mir-backend-php-laravel). SKIP for Node/JVM/Go/Rust/.NET/Python/Ruby/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics (those live in the framework module).
mir-backend-python-django
Make It Right (Django module). Django 5 + Django REST Framework specific reliability augmentation. Use alongside the mir-backend skill when the target stack is Django — it carries the mechanical footguns that the framework-agnostic skill deliberately omits: ORM N+1 with select_related/prefetch_related, queryset laziness and caching semantics, migration safety on populated tables (NOT NULL / index locking), transaction.atomic() and on_commit() boundaries, mass assignment through ModelForm and DRF serializers, async views with the Django 4.1+ async ORM, and signal side-effect traps. TRIGGER only when the Python backend stack is Django — building, reviewing, or debugging a Django view, model, serializer, migration, or admin. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-python (CPython runtime concerns: GIL, async/sync, fork-safety, cold start); this module only adds Django/DRF library mechanics. SKIP for FastAPI, Flask, or any non-Django stack (those get their own mir-backend-python-<framew
mir-backend-python-fastapi
Make It Right (FastAPI module). FastAPI + Async SQLAlchemy 2.0 + Postgres + Alembic + Redis specific reliability augmentation. Use alongside the mir-backend skill when the target stack is FastAPI — it carries the mechanical footguns that the framework-agnostic skill deliberately omits: async session lifecycle and scope, Pydantic v2 validation boundaries, Depends()-based auth and authorization, BackgroundTasks vs a real queue, async N+1 with selectinload, greenlet/sync-driver-in-async traps, Alembic migration safety on populated tables, and Redis idempotency/locking patterns. TRIGGER only when the Python backend stack is FastAPI — building, reviewing, or debugging a FastAPI endpoint, dependency, SQLAlchemy session, or Alembic migration. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-python (CPython runtime concerns: GIL, async/sync, fork-safety, cold start); this module only adds FastAPI/SQLAlchemy library mechanics. SKIP for Django, Flask, or any non-FastAPI stack (those get their own mir-
mir-backend-python-flask
Make It Right (Flask module). Flask 3 specific reliability augmentation. Use alongside the mir-backend skill when the target stack is Flask — it carries the mechanical footguns that the framework-agnostic skill deliberately omits: app/request context misuse (current_app/request/g outside context), missing input validation and object-level authorization, SQLAlchemy session scoping and teardown, app-factory pattern and circular import avoidance, offloading heavy work to Celery/RQ, config/secret safety (debug=True RCE, SECRET_KEY), and Alembic migration safety via Flask-Migrate. TRIGGER only when the Python backend stack is Flask — building, reviewing, or debugging a Flask route, blueprint, extension, SQLAlchemy session, or migration. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-python (CPython runtime concerns: GIL, async/sync, fork-safety, cold start); this module only adds Flask library mechanics. SKIP for Django, FastAPI, or any non-Flask stack (those get their own mir-backend-python-<f
mir-backend-python
Make It Right (Python runtime tier). CPython/PyPy runtime reliability footguns that are shared across EVERY Python backend framework (FastAPI, Django, Flask, Celery) — distinct from the generic backend gates and from any one framework's mechanics. Covers: the GIL (threads give no CPU parallelism), async-vs-sync 'coloring', blocking the event loop, choosing asyncio vs threads vs multiprocessing vs a worker queue, fork-safety of connection pools, serverless cold starts, and dropped-task exceptions. TRIGGER when the backend runtime is Python — sits between mir-backend (generic) and the framework module (e.g. mir-backend-python-fastapi). SKIP for Node/JVM/Go/Rust/.NET/Ruby/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics (those live in the framework module).
mir-backend-ruby-rails
Make It Right (Rails module). Ruby on Rails 7+ specific reliability augmentation. Use alongside mir-backend and mir-backend-ruby when the target stack is Rails — carries the mechanical footguns the framework-agnostic skills deliberately omit: ActiveRecord N+1 and eager-loading strategies, strong parameters and mass-assignment safety, callback side-effect timing (after_commit vs after_save), transaction semantics and nested transactions, migration safety on populated tables (the #1 Rails production incident class), and connection pool sizing tied to Puma threads. TRIGGER only when the Ruby backend is Rails — building, reviewing, or debugging a Rails controller, model, concern, migration, or background job that uses ActiveRecord. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-ruby (YARV runtime: GVL, Puma fork-safety, CoW memory, job hygiene); this module only adds Rails/ActiveRecord library mechanics. SKIP for Sinatra, Hanami, pure Rack apps, or non-Ruby runtimes.
mir-backend-ruby
Make It Right (Ruby runtime tier). YARV/MRI Ruby 3.3+ runtime reliability footguns shared across EVERY Ruby backend framework (Rails, Sinatra, Hanami, Sidekiq workers) — distinct from the generic backend gates and from any one framework's mechanics. Covers: the GVL (threads give no CPU parallelism, like Python's GIL), Puma's forked-worker + thread model, fork-safety of DB/Redis connections, copy-on-write memory and per-worker bloat, background job hygiene (Sidekiq/GoodJob idempotency, retries), and GC/frozen-string pressure. TRIGGER when the backend runtime is Ruby — sits between mir-backend (generic) and the framework module (e.g. mir-backend-ruby-rails). SKIP for Node/JVM/Go/Rust/.NET/Python/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics (those live in the framework module).
mir-backend-rust-actix
Make It Right (Actix-web module). Actix-web + async Rust specific reliability augmentation. Use alongside mir-backend and mir-backend-rust when the target stack is Actix-web — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: the multi-worker app data trap (state constructed inside the App factory closure yields N independent copies, not one shared instance), web::Data<T> Arc semantics and the .app_data vs .data deprecation, worker-local single-threaded actix-rt execution (!Send types allowed but blocking still starves the worker), extractor configuration via JsonConfig/QueryConfig, and error handling via the ResponseError trait. TRIGGER only when the Rust backend framework is Actix-web — building, reviewing, or debugging an Actix-web handler, middleware, extractor, or app factory. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-rust (Tokio runtime concerns: blocking, cancellation safety, Arc/'static, backpressure, timeouts); this module only adds Actix
mir-backend-rust-axum
Make It Right (Axum module). Axum + Tower + async Rust specific reliability augmentation. Use alongside mir-backend and mir-backend-rust when the target stack is Axum — it carries the mechanical footguns that the framework-agnostic tiers deliberately omit: extractor ordering (body-consuming extractors must be last), typed State<T> vs Extension<T> and the FromRef sub-state pattern, implementing IntoResponse for error types, and Tower middleware layer ordering (outermost wraps first). TRIGGER only when the Rust backend framework is Axum — building, reviewing, or debugging an Axum handler, router, extractor, or middleware. Always loads TOGETHER WITH mir-backend (the gates) and mir-backend-rust (Tokio runtime concerns: blocking, guard-across-await, cancellation safety, Arc/'static, backpressure, timeouts); this module only adds Axum/Tower library mechanics. SKIP for Actix-web, Warp, Poem, or any non-Axum Rust stack (those get their own mir-backend-rust-<framework> module), and for non-Rust runtimes.
mir-backend-rust
Make It Right (Rust runtime tier). Async Rust on Tokio runtime reliability footguns that are shared across EVERY Rust backend framework (Axum, Actix-web, Warp, Poem) — distinct from the generic backend gates and from any one framework's mechanics. Covers: blocking the async runtime (std::thread::sleep / blocking I/O inside async tasks starves Tokio worker threads), holding a std::sync::MutexGuard across an .await point (compile error or deadlock), cancellation safety (futures dropped at any .await under timeout/select!/disconnect leaving partial state), panic-poisoned Mutexes, Arc-based shared state with 'static bounds on spawned tasks, bounded vs unbounded channels for backpressure, and timeout discipline on every outbound call. TRIGGER when the backend runtime is Rust — sits between mir-backend (generic) and the framework module (e.g. mir-backend-rust-axum). SKIP for Python/Node/JVM/Go/.NET/Ruby/PHP/BEAM runtimes (each has its own mir-backend-<runtime> tier), and for framework-library mechanics (those live
mir-backend
Make It Right (backend pillar). Constraint-first backend planning protocol for AI coding agents — AI makes code that WORKS on the happy path; this makes it RIGHT under concurrency, failure, and load. Forces the model OUT of pattern-completion ('autocomplete from latent space') and INTO explicit constraint discovery before any code is written. Use whenever a task involves backend logic that changes state, touches money/inventory/auth, spans multiple tables or services, runs under concurrency, or persists data beyond a single request. Runs a hard-gated pipeline: Intent → Constraint Interrogation → Assumption Ledger → Invariants & Failure Modes → Risk Register → Design Review → Implementation → Production-Readiness Review. Spawns specialized reviewer sub-agents. Chains into a runtime tier (e.g. mir-backend-python for CPython concerns) and a framework module (e.g. mir-backend-python-fastapi for FastAPI/SQLAlchemy/Alembic). TRIGGER for backend work in ANY language (Python, Node, Go, Rust, Java) — this is the gener
mir-frontend-react
Make It Right (React reactivity tier). React 19 + React Compiler reactivity footguns shared across EVERY React meta-framework (Next.js, React Router 7/Remix, TanStack Start, Vite SPA) — distinct from the generic frontend gates and from any one framework's mechanics. Covers: the Rules of Hooks, effect-dependency discipline (derive in render, effects are for external sync only), stale closures, list-key correctness, controlled vs uncontrolled inputs, granular Suspense + Error Boundary placement, useTransition/useDeferredValue for INP, React Compiler 1.0 interop (blind useMemo/useCallback is now a liability; the 'use no memo' opt-out), concurrent-rendering/StrictMode double-invoke, and the server-state-vs-client-state boundary (TanStack Query, not useState mirrors). TRIGGER when the frontend reactivity library is React — sits between mir-frontend (generic) and the framework module (e.g. mir-frontend-react-next). SKIP for Vue/Angular/Svelte (each gets its own mir-frontend-<lib> tier), and for meta-framework-libra
mir-frontend
Make It Right (frontend pillar). Constraint-first frontend planning protocol — AI generates components that LOOK right; this makes them RIGHT under async, state transitions, hydration, accessibility, and real interaction. Forces explicit UX/state/interaction contracts before code. Runs the hard-gated pipeline (Intent→Constraint Interrogation→Assumption Ledger→Invariants & UI State Machine→Risk Register→Design Review→Implementation→Production-Readiness). Chains into a reactivity tier (e.g. mir-frontend-react) and a framework module (e.g. mir-frontend-react-next). TRIGGER for frontend/UI work in any reactive library (React, Vue, Angular) — building components, hooks, forms, data-fetching UI, routing, styling, accessibility. SKIP for backend logic, pure data/CLI scripts, and standalone database/data-pipeline work (those are other Make It Right pillars).
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.