robsonkades
UserA cross-agent skill package manager with specialist skills for Java, JVM performance, software architecture, and distributed systems.
Categories
Indexed Skills (50)
adapter-sidecar-pattern
Choose and review Kubernetes telemetry adapters when a legacy or vendor process emits incompatible metrics, logs or health signals, when deciding between per-pod translation and a node agent, or when an application upgrade silently changes parsed telemetry. Covers translation contracts, evidence-backed enrichment and failure behavior. Excludes in-process interface adaptation (gof-adapter), container mechanics (sidecar-pattern), probe configuration (kubernetes-service-lifecycle) and telemetry instrumentation design.
allocation-profiling
Attribute Java heap allocation to code and validate reductions in bytes per operation. Use when allocation or GC frequency regresses, JFR allocation events are empty or disagree with counters, large buffers trigger G1 humongous collections or ZGC stalls, or pooling, TLAB tuning, or assumed JIT elimination is proposed without measurements. Covers sampling semantics and allocation-specific triage; general capture selection belongs to jfr-and-async-profiler, retention diagnosis to heap-dump-analysis, and scalar replacement mechanisms to jit-inlining-and-escape-analysis.
ambassador-pattern
Choose or review a local outbound proxy when discovery or routing changes require client releases, a canary or shadow needs routing outside the app, or retries overlap across app, proxy and mesh. Define the listener, policy ownership, deadlines and failure behavior. Covers shard-map consumption and experiment routing, not shard algorithms (sharding-and-partitioning), container lifecycle (sidecar-pattern), or output normalization (adapter-sidecar-pattern).
architecture-and-performance
Attribute endpoint latency and throughput limits to architectural choices when query counts grow with result size, remote calls are chatty, connections are held across other work, or a cache, layer removal or service extraction is proposed as a performance fix. Compare fetching, call topology, resource occupancy and data movement across the whole request path. Does not replace investigation methodology (performance-methodology), profiling (jfr-and-async-profiler), individual SQL tuning (sql-query-performance), pool configuration (connection-pool-sizing) or load-test construction (load-testing).
architecture-characteristics
Derive and prioritize architectural quality drivers when requirements say only scalable or reliable, too many qualities are called top priority, stakeholders disagree on their meaning, or one list is applied across unrelated services. Define scope, sources, observable scenarios, baseline obligations and reasons for deferring candidates. Covers terminology and quality-model interpretation; excludes choosing design options (architecture-trade-off-analysis), recording ADRs (architecture-decision-making), coupling analysis (architecture-coupling-and-quanta) and operational SLO implementation.
architecture-coupling-and-quanta
Map release and runtime coupling when services ship together, event-driven components still require coordinated changes, shared data obscures ownership, or a proposed architecture quantum boundary cannot be justified. Distinguish structural dependencies, workflow completion and connascence using contracts, deployment evidence and failure behavior. Does not choose service extractions (distribution-boundaries), diagnose architecture smells (enterprise-architecture-smells), or refactor package dependencies (java-cohesion-coupling).
architecture-decision-making
Write, review, reconstruct or supersede architecture decision records when rationale is missing, a decision is repeatedly reopened, a proposal needs an explicit outcome, or an accepted choice changes. Decide how much record is warranted; preserve evidence, alternatives, consequences, decision authority and revisit conditions. Covers ADR scope, lifecycle and traceability; option comparison belongs to architecture-trade-off-analysis, quality-driver elicitation to architecture-characteristics, and shortcut/repayment choices to technical-debt-decisions.
architecture-fitness-functions
Define or review checks that preserve architectural qualities when a green pipeline misses incidents, inherited rules are skipped or unexplained, a characteristic lacks evidence, or a metric is being promoted to a blocking gate. Choose the measurement or rubric, threshold, execution site, owner and response policy; expose proxy limits and coverage gaps. Excludes selecting quality drivers (architecture-characteristics), implementing application tests (architecture-testing), pipeline composition (quality-gates), performance experiment thresholds (performance-regression-ci) and operational error-budget design (slo-and-alerting).
architecture-refactoring-paths
Sequence a chosen enterprise architecture change into compatible, testable checkpoints: domain and persistence refactoring, remote boundaries, session state, locking or events. Use when old and new paths must coexist, a migration has stalled, code and data changes interact, consumers cannot upgrade together, or rollback and safe pause points are unclear. Does not select target patterns, diagnose the need for change (enterprise-architecture-smells), plan a whole modernization programme (legacy-enterprise-modernization), or implement database migration tooling.
architecture-testing
Write or review tests for architectural promises: dependency boundaries, transaction atomicity, persistence mappings, stale-write detection, query budgets and API/event compatibility. Use when green tests missed a lost update or N+1, a boundary exists only in documentation, or an integration test may hide the behavior it claims to verify. Does not choose the architecture or governance thresholds (architecture-fitness-functions), replace general unit-test design, or establish production capacity (load-testing).
architecture-trade-off-analysis
Compare architectural alternatives when quality goals conflict, a scorecard or case study is being used as a verdict, options mix abstraction levels, advocates disagree, or a benchmark needs a decision rule. Build comparable options, separate constraints from preferences, test domain scenarios and uncertainty, and recommend a choice or a bounded next step. Excludes ADR lifecycle (architecture-decision-making), quality-driver elicitation (architecture-characteristics), domain pattern selection and debt repayment.
async-profiler-advanced
Configure and validate async-profiler when recordings are empty, idle-heavy, truncated, permission-blocked, containerized, multi-event, or version-sensitive. Choose event weights and engines, bound collection overhead, diagnose missing stacks, and verify conversions and differentials. Does not own initial profiler selection (jfr-and-async-profiler), visual interpretation (flame-graph-analysis), or JDK Flight Recorder configuration.
blocking-and-nonblocking-io
Four things routinely conflated into one: a blocking API, a blocked OS thread, non-blocking I/O at the syscall, and an asynchronous programming model. Covers which JDK operations unmount a virtual thread and which capture the carrier, the difference between capture-with-compensation and pinning, the socket poller behind blocking socket calls, file I/O as the case Loom does not fix, and what blocking an event loop costs. Use when someone says virtual threads make I/O non-blocking, when a file-heavy workload on virtual threads grows the carrier pool, when a blocking call sits inside a Netty or Reactor pipeline, when jdk.virtualThreadScheduler.maxPoolSize is raised to fix a symptom, or when an argument turns on whether the model or the syscall is the bottleneck. Not choosing between the two models (reactive-and-virtual-thread-selection), continuation mechanics and pinning diagnosis (virtual-threads-internals), demand signalling (reactive-backpressure), or copy avoidance (io-uring-and-zero-copy).
c2-sea-of-nodes
How HotSpot actually executes and compiles: the runtime-generated template interpreter, C2's sea-of-nodes IR, a release-scoped diagnostic map of compilation phases, and why a given transformation fired or did not. Use when a method is believed to be "not optimised", when an allocation that looks eliminable still shows up in allocation profiling, when a hot call site reports `too large` or stays non-inlined, when `made not entrant` repeats on the same method, when someone prescribes `-XX:CompileThreshold` under tiered compilation, or when explaining why the JIT did not fix an O(n^2) loop. Does not cover the tiered pipeline, warm-up and code cache sizing (jit-compilation), reading the compiler's own decision logs end to end (compilation-and-inlining-logs), the emitted machine code (reading-jit-assembly), or the bytecode the compiler consumes (jvm-bytecode).
cache-sharding-and-replication
Topology for a cache that no longer fits one node: client-side sharded, proxy-fronted, clustered, and fully replicated, compared on failure behaviour, cost and client complexity; and why a read after a write on a replicated cache is not read-your-writes. Estimates origin load when a cache node fails from its measured request share and the surviving copies, routing and capacity — mitigated by replication, warming, coalescing and admission control. Use when choosing between client sharding, a proxy and cluster mode, when a cache node loss or rolling restart took the database with it, when replicas of a cache disagree, or when deciding between sharding the cache and replicating all of it. Does not cover whether to cache, TTL, stampede or invalidation (caching-strategies), the key-to-node mapping (consistent-hashing), a single hot cache key (hot-partitions-and-rebalancing), entry serialisation cost (serialization-performance), or what a replicated read observes (consistency-models).
caching-strategies
Deciding whether to cache, then doing it safely: saved origin work and latency, bounded size or weight, TTL and jitter, stampede and its four distinct scopes, cache-aside versus refreshAfterWrite, immutable DTOs rather than JPA entities, invalidation across instances, Redis serialisation, and why hit rate alone is a misleading metric. Use when a cache is being added or reviewed, when @Cacheable is called from within the same bean, when a cache has no size limit or no TTL, when entries are preloaded in bulk with one TTL, when hit rate is the only metric on the dashboard, when Old Gen keeps growing, when FLUSHALL appears in a deploy pipeline, or when instances disagree about a value. Does not cover the pool the cache protects (connection-pool-sizing), the queueing arithmetic (littles-law-and-queueing), or GC tuning for the resulting heap (jvm-gc-tuning).
cancellation-and-interruption
Designing cooperative cancellation in Java across interruption, Future/CompletableFuture, executor/scope shutdown, deadlines, resource close/abort, CPU loops, blocking APIs, native calls, partial side effects and cleanup. Covers multiple cancellation sources, signal ownership, propagation/translation/restoration, noninterruptible regions, residual work, idempotency and bounded termination tests. Use when timeout/cancel returns but work or resources remain, or when `InterruptedException` handling is ambiguous. Timeout selection and retry policy are separate.
capacity-planning
Evidence-based capacity decisions for Java services: defining demand and failure scenarios, measuring feasible capacity envelopes, selecting replica and resource configurations, forecasting exhaustion with uncertainty, designing autoscaling headroom, and comparing cost per successful unit of work. Use when deciding pod or instance counts, minimum replicas, scaling signals, saturation dates, infrastructure budgets, rollout or failure-domain headroom, and downstream capacity constraints. Does not own load-test design (load-testing-advanced), queueing-model selection (queueing-models), scalability curve fitting (universal-scalability-law), or overload controls (rate-limiting-and-load-shedding).
cascading-failures
How one slow dependency becomes a total outage: the amplification loop and the four points that close it — retry storms, unbounded queues, thread and connection exhaustion, an inner timeout longer than the outer one. Covers why cutting offered work is usually the first stabilization step in a cascade, metastability sustained by backlog, recovery herds and criticality separation. Use when one dependency's latency rise took down services that never call it, when the dependency recovered and the system did not, when adding replicas mid-incident made it worse, or when queue depth grows while goodput falls to zero. Does not cover the breaker (circuit-breakers), shedding policy (rate-limiting-and-load-shedding), bulkheads (concurrency-limiting-and-bulkheads), retry policy (retries-and-backoff), queue arithmetic (littles-law-and-queueing), replica routing (load-balancing-and-routing), or the fault model (failure-models).
circuit-breakers
The breaker as a state machine that stops calling a failing dependency: closed, open and half-open; choosing rate windows versus consecutive failures; why half-open admits a bounded number of probes; the failure predicate—classifying correlated dependency failures rather than blindly counting status classes—and the distinction between protecting caller resources by failing fast and providing a semantically valid fallback. Use when a breaker trips on consecutive failures, when it never trips or trips on one client's bad requests, when half-open sends full traffic at a recovering dependency, when a breaker sits on a call with no timeout under it, or when a dependency is slow rather than failing. Does not cover bulkheads (concurrency-limiting-and-bulkheads), retry policy (retries-and-backoff), the bound itself (timeouts-and-deadlines), the system-wide loop (cascading-failures), shedding (rate-limiting-and-load-shedding), or serving a cached fallback (caching-strategies).
clean-delivery-workflow
The order of work for a change, and how much of that order a given change actually warrants: understanding before editing, clarifying what is ambiguous, deciding the test approach, implementing in reversible steps, separating refactoring from behaviour where independently valid, running the gates the risk deserves, and verifying before declaring done. Also the entry point that routes a situation to the skill that owns it. Use when starting a change and the order is not obvious, when a change has sprawled and needs re-sequencing, when refactoring and behaviour changes have been mixed in one commit, when work is being declared done without verification, when the same ceremony is being applied to a one-line fix and a migration, or when you know the problem but not which skill covers it. Does not itself cover any step in depth — it routes to requirements-and-acceptance, java-testing-strategy, tdd, java-refactoring, code-review and quality-gates, each of which owns its own.
code-cache-segments
The JDK 17-25 segmented code cache, GC-driven unloading, fragmentation, segment sizing, and jcmd Compiler.codecache/CodeHeap_Analytics. Use when aggregate usage looks healthy but one CodeHeap is exhausted, compilation stops or restarts, GC logs show a CodeCache cause, startup rejects manual heap sizes, an OutOfMemoryError reports "Out of space in CodeCache", or a long-running service degrades while aggregate free space remains. Covers runtime-shape discovery so tools do not assume exactly three heaps on every mode or release. Excludes the introductory exhaustion signature (jit-compilation), container memory budgeting (jvm-memory-regions), and Metaspace internals (metaspace-internals).
code-review
Reviewing a change as an engineering activity: setting review depth from the change's risk rather than its size, looking in the order that finds the expensive defects first, refusing to spend human attention on what a formatter or linter should own, writing a finding that can be acted on, separating blocking objections from preferences, and receiving review without either capitulating or defending. Use when reviewing a pull request or a diff, when a review has become a list of style comments, when reviews are slow or rubber-stamped, when a reviewer and an author are deadlocked, when a defect reached production through an approved change, or when deciding what a review must catch versus what CI should. Does not cover the smell catalogue (java-code-smells), SOLID as review criteria (java-solid), readability heuristics (java-clean-code), or which automated gates to run (quality-gates).
coding-agent-discipline
The reporting and restraint rules for an AI agent changing someone's codebase: never claiming a result that was not observed, saying which commands ran and what they printed, reporting what could not be verified rather than omitting it, keeping the diff to what was asked, preserving behaviour that was not in scope, checking APIs against the versions the project actually depends on, and refusing to make a test pass by weakening it. Use before reporting that work is complete, when about to write "this should work" or "tests pass", when a change is growing beyond the request, when a test is failing and deleting or disabling it is tempting, when an API is being used from memory rather than checked, or when two instructions cannot both be satisfied. Does not cover the order of work (clean-delivery-workflow), which checks to run (quality-gates), or how to phrase a message to a human (engineering-communication).
collaborative-feature-definition
Co-authoring Product Features and Tech Features through focused question-and-revision rounds. For a Product Feature, separates the business definition from an optional engineering analysis owned by an architect or senior engineer, including PoCs, ADRs, contracts, and engineering premises. Use when the deliverable is an agreed feature brief or ticket, not implementation. The completed package is handed to feature-engineering for lifecycle validation and execution planning.
compilation-and-inlining-logs
Reading what the JIT actually did: the columns of -XX:+PrintCompilation and its flag characters, -XX:+PrintInlining and its verdict strings, -XX:+LogCompilation with JITWatch, the -Xlog:jit+compilation and JFR forms, targeted compiler directives, and turning a refusal into a code change. Use when a hot method is suspected of not reaching tier 4, when a call site shows "too big" or another inlining refusal, when a method never appears in the compilation log at all, when someone prescribes -XX:CompileThreshold or -Xlog:jit, when a script greps the compilation log and returns nothing, when a directive added with jcmd changed nothing, when JFR shows no compilation events, or when raising FreqInlineSize globally is proposed to fix one method. Does not cover the tiered pipeline, warm-up and the code cache as concepts (jit-compilation), the design rules about inlining and escape (jit-inlining-and-escape-analysis), recompilation and uncommon traps (deoptimization), or C2's internal representation (c2-sea-of-nodes).
completablefuture-composition
Design and diagnose CompletionStage graphs with explicit execution, ownership, failure, timeout, cancellation, context and admission semantics. Use when a continuation runs on an I/O thread, a branch failure disappears, allOf or anyOf has the wrong policy, a timeout leaves work running, or asynchronous fan-out overloads a dependency. Distinguishes Java 17/21 APIs from Java 25 preview structured-concurrency alternatives.
component-and-release-boundaries
Deciding what becomes an independently releasable component — a Maven module, a JPMS module, a published library — and what that costs: the tension between reusing code and being able to release it, why a shared jar couples every service depending on it, breaking cycles between components, and judging whether a component is stable enough to depend on. Use when a `common` or `shared` module is proposed or has grown, when extracting code into a library so two services can reuse it, when a dependency cycle appears between Maven modules, when upgrading one library forces a coordinated release of several services, or when services are independently deployable in theory but always ship together. Does not cover cohesion and coupling at class and package level (java-cohesion-coupling), whether a component should become a separate process (distribution-boundaries), the API compatibility of a published type (java-api-design), or wire contract versioning (rpc-and-api-contracts).
concurrency-diagnostics
Evidence-led diagnosis of deadlock, starvation, livelock, saturation, leaks and virtual-thread scheduler problems. Compares traditional platform-thread dumps, jcmd all-thread dumps, ThreadMXBean, VirtualThreadSchedulerMXBean, JFR, wall/CPU profiles and application telemetry, including each tool's visibility and consistency limits. Use when progress stops, CPU and latency disagree, tasks disappear, shutdown hangs, or a virtual-thread dump is inconclusive.
concurrency-limiting-and-bulkheads
Engineer process-local concurrency limits and bulkheads around scarce resources, with explicit admission deadlines, permit ownership, weighted work, partitioning, fairness, observability and overload validation. Distinguishes concurrency, rate and queue limits and the assumptions behind Little's Law. Use after virtual-thread migrations, during downstream saturation, or when local limits leak, over-release, double-queue or fail to compose across replicas.
concurrency-testing
Testing concurrent Java so failures appear in CI rather than in an incident: what a passing concurrency test does and does not prove, replacing sleeps with latches and deterministic executors, explicitly exercising cancellation, interruption and timeout, stress tests that assert invariants, and soak tests that catch permit and connection leaks. Use when a test uses Thread.sleep to wait for another thread, when a concurrency test is flaky and a retry is proposed, when cancellation or timeout paths have no test at all, when tests assert on thread names or pool sizes and broke after a virtual-thread change, when a race was found in production and nobody can reproduce it, or when a concurrency limit or fallback has never been exercised under failure. Does not cover proving memory-model claims (java-memory-model, varhandles-and-memory-ordering), benchmark methodology (jmh-microbenchmarks), load generation and rates (load-testing), or diagnosing a live system (concurrency-diagnostics).
concurrent-collections-and-synchronizers
Choosing between the members of java.util.concurrent once the family is settled, and the parameter that makes it correct: which BlockingQueue and which of its four insert and remove forms, which ConcurrentHashMap atomic replaces a compound action, copy-on-write's cost, latch versus barrier versus phaser versus semaphore, the Condition await loop, and ReentrantLock versus ReentrantReadWriteLock versus StampedLock. Use when computeIfAbsent loads from a database, when IllegalStateException "Recursive update" is thrown, when new LinkedBlockingQueue<>() appears in a producer, when a thread parks in CountDownLatch$Sync or every worker sits in CyclicBarrier.dowait, when await() sits under an if, or when a read lock is upgraded to a write lock. Not the thread-safety contract (java-thread-safety-contracts), executor lifecycle (executors-and-task-lifecycle), limit sizing (concurrency-limiting-and-bulkheads), CAS loops (lock-free-patterns), monitor contention (lock-inflation), or happens-before (java-memory-model).
connection-pool-sizing
Sizing and diagnosing a JDBC connection pool: L = λ × W where W is connection hold time rather than query latency, the database-side ceiling, HikariCP timeouts and lifetimes, transaction boundaries and idle-in-transaction, N+1 detection, JDBC batching, and what virtual threads change. Use when choosing maximumPoolSize, when connection-timeout is 0 or 30 s, when threads wait for connections under load, when HTTP or queue calls happen inside @Transactional, when connections die silently behind a firewall or load balancer, when hibernate.jdbc.batch_size appears not to work, or when raising the pool is proposed as the fix. Does not cover the general queueing arithmetic (littles-law-and-queueing), thread pool sizing (thread-sizing-and-virtual-threads), or caching to reduce load (caching-strategies).
consensus-and-quorums
Crash-fault consensus and quorum reasoning: FLP, safety versus liveness, majority 2f+1, R + W > N intersection and its limits, voter/failure-domain placement, Raft terms and why external fencing still requires resource enforcement, plus the differing read/watch contracts of etcd, ZooKeeper and Consul. Use when a cluster size is being chosen, when nodes are spread across AZs or regions, when application data or a queue is being put in etcd or ZooKeeper, when a coordination store sits on the request path, when a watch is treated as a delivery guarantee, or when a fourth node is proposed for redundancy. Does not cover CAP and the model ladder (consistency-models), mutual exclusion built on top (distributed-locks-and-leases), electing a singleton worker (leader-election), or the fault model itself (failure-models).
consistency-models
Choosing distributed consistency guarantees as an engineering decision: linearizability, sequential/causal ordering, session guarantees (read-your-writes, monotonic reads), bounded staleness and eventual convergence, stated as observable contracts rather than a false total ladder; CAP stated correctly—the choice between C and A exists only while partitioned—and PACELC, replica paths and transaction isolation boundaries. Use when a user cannot see their own write, when a read after a write returns the previous value, when a design names a model instead of an observable requirement, when reads are being routed to replicas, or when someone cites "pick two". Does not cover multi-service atomicity (distributed-transactions-and-sagas), quorum arithmetic (consensus-and-quorums), caches (caching-strategies), replicated cache topology (cache-sharding-and-replication), or the JMM's happens-before (java-memory-model).
consistent-hashing
Stable key-to-node placement across membership changes: modulo remapping, consistent-hash rings, virtual points, rendezvous hashing, collision-safe Java implementations, hash contracts, replica selection, weighting, testing and membership handoff. Use when changing node count causes a miss storm or migration, ownership is uneven, or placement relies on Object.hashCode. Does not choose the shard key (sharding-and-partitioning), repair hot keys (hot-partitions-and-rebalancing), define cache topology (cache-sharding-and-replication), or balance interchangeable replicas (load-balancing-and-routing).
container-awareness
What the JVM actually detects inside a container: cgroup v1 versus v2 detection, ActiveProcessorCount and how a CPU quota becomes a processor count, MaxRAMPercentage and every ergonomic derived from it, GC and JIT thread counts sized from the wrong number, and verifying all of it from inside the running container. Use when a pod is OOMKilled while heap usage is well below Xmx, when a Deployment has no resources.limits or sets limits.memory equal to Xmx, when MaxRAMPercentage is pushed to 90, when someone reads ActiveProcessorCount out of PrintFlagsFinal or jcmd VM.flags and gets -1, when a cgroup command reads /sys/fs/cgroup/cpu/cpu.stat and finds nothing, or when latency spikes have no matching GC pause. Does not cover host-side kernel behaviour such as the node OOM killer, page faults, swap, PSI or signals (linux-for-jvm), the memory-region budget itself (jvm-memory-regions), or CPU topology and pinning (numa-and-cpu-affinity).
continuous-profiling
Designing and operating always-on production profiling: question-driven signal choice, permanent overhead and coverage budgets, in-process versus host collection, context-label propagation, profile schemas, storage and cardinality, retention and incident preservation, deploy-aware comparisons, trust boundaries, and evidence-quality SLOs. Use when historical CPU/allocation/lock evidence must survive an incident, when profile cost or tenant labels can grow without bound, when a backend or agent is being selected, or when two time windows are compared as a regression claim. Does not teach one-off capture mechanics (jfr-and-async-profiler), async-profiler engines (async-profiler-advanced), JFR tuning (jfr-advanced), or graph interpretation (flame-graph-analysis).
coordinated-omission
Coordinated omission in depth: response-coupled sampling, open/closed/semi-open workload models, scheduled-versus-actual clocks, generator saturation, correction at recording time versus at generation time, HdrHistogram's recordValueWithExpectedInterval semantics, what wrk2, k6, Gatling, JMeter and Locust each actually do, and the effect on capacity numbers. Use when a load test's p99 is far better than production's for the same endpoint, when a generator misses its planned schedule, when someone proposes applying recordValueWithExpectedInterval to open-loop data, when a latency dashboard improves as a system saturates, or when a benchmark's numbers are about to become an SLO. Does not cover the introductory treatment or the general statistics of latency (latency-statistics), or designing the load test as a whole (load-testing).
cpu-cache-and-numa
Hardware-aware Java: cache-line coherence and locality, false sharing and how it differs from lock contention, object layout measured with JOL, LongAdder versus AtomicLong, data locality in arrays and collections, and NUMA topology. Use when throughput gets **worse** as threads are added, when scaling efficiency collapses, when fields are being added to a class shared between threads, when volatile counters sit next to each other, when @Contended or padding is proposed, when -XX:+UseNUMA is being set, or when someone says a volatile write "flushes the cache". Does not cover happens-before correctness (java-memory-model), pool and queue sizing (littles-law-and-queueing), or kernel and cgroup behaviour (linux-for-jvm). Proving and fixing false sharing is false-sharing-and-contended, and topology and pinning is numa-and-cpu-affinity.
data-source-patterns
Choosing how code reaches the database — Table Data Gateway, Row Data Gateway, Active Record or Data Mapper — from the shape of the domain logic rather than from framework habit, and knowing what each one couples together. Use when a new module's persistence approach is being chosen, when entities carry both business rules and save() methods, when JPA is being applied to a schema that fights it, when SQL is scattered through service classes, when a "DAO" layer duplicates what the ORM already provides, when the domain model's shape is visibly dictated by the tables, when bulk or reporting work is being forced through an ORM, or when a team is arguing Active Record versus Data Mapper in the abstract. Does not cover where business logic lives (domain-logic-organization), the ORM's runtime behaviour — unit of work, identity map, lazy load (orm-behavioral-patterns), the column-level mapping decisions (orm-structural-mapping), or the collection-shaped abstraction over aggregates (repository-pattern).
database-bulk-loading
Designing and diagnosing high-volume database ingestion from the JVM across PostgreSQL, MySQL, and SQL Server: JDBC batching and statement rewrite, native COPY/LOAD DATA/Bulk Copy, staging, transaction and partial-error semantics, idempotent restart, upsert races, logging, parallelism, and post-load validation. Use when a backfill, import, migration, or batch window is too slow or unsafe. Not routine ORM fetch/write tuning, which belongs to orm-fetch-and-batching-performance.
database-engine-selection-and-migration
Choosing among SQL Server, MySQL/InnoDB, and PostgreSQL for a greenfield system, or planning a migration between them, from explicit semantic, workload, operational, JVM-driver, DDL, cost, and team constraints. Use when an ADR, proof of concept, compatibility inventory, shadow validation, or reversible cutover is needed. Not a generic product ranking or live query-tuning workflow.
database-index-design
Designing and governing an index portfolio across SQL Server, MySQL/InnoDB, and PostgreSQL: deriving composite keys from a workload, equality/range/order trade-offs, covering and partial indexes, write amplification, redundant-index consolidation, engine-specific semantics, and safe production creation or removal. Use when changing schema indexes for several queries or reviewing a table's index set. Not the diagnosis of one slow statement, which belongs to sql-query-performance.
database-performance
Evidence-first triage and routing for database performance questions across SQL Server, MySQL/InnoDB, PostgreSQL, JDBC pools, ORM behavior, index portfolios, and bulk loading. Use when the symptom spans layers, the owning mechanism is unclear, or a database choice or migration needs structured comparison. This is a router; it does not replace the specialist skills that own a confirmed engine or mechanism.
debugging
Finding the cause of a fault instead of a change that makes the symptom go away: reproducing before diagnosing, shrinking the reproduction until nothing is removable, stating a hypothesis that predicts an observation, changing one variable at a time, bisecting, and choosing which evidence to collect from a running production system before it is destroyed. Use when a fix is being guessed at, when a change "seems to work", when the same bug keeps coming back, when a fault cannot be reproduced, when a production incident needs a cause rather than a restart, when print statements are being added everywhere, or when several changes were made at once and it now works. Does not cover JVM performance triage (java-performance), GC (jvm-gc-tuning), live thread diagnosis (concurrency-diagnostics), heap dump mechanics (heap-dump-analysis), or deliberately injecting failures (distributed-systems-testing).
delivery-semantics
Precise end-to-end delivery and processing semantics: acknowledgement placement, loss and duplicate windows, Kafka transactions, visibility leases, ambiguous outcomes and external side effects. Use when reviewing "exactly once", consumer commits, redelivery or a handler that writes outside its broker. Idempotent handler design belongs to idempotency; retries, ordering, poison messages and fault assumptions have their own skills.
deoptimization
Deoptimisation and recompilation on HotSpot: uncommon traps and their reason codes, the none / maybe_recompile / reinterpret / make_not_entrant / make_not_compilable actions, jdk.Deoptimization in JFR, -XX:+TraceDeoptimization, the per-method trap limits and recompilation cutoffs, and diagnosing a method that never stabilises. Use when a method repeatedly shows "made not entrant" in the compilation log, when latency spikes correlate with class loading or a deploy, when a burst of "marked for deoptimization" follows a deploy or a plugin load, when a feature flag or APM agent is suspected of invalidating compiled code, when "made not compilable" or a flood of action "none" appears for a hot method, when someone proposes raising PerMethodRecompilationCutoff, or when -Xlog:jit+deoptimization produced an empty file. Does not cover the tiered pipeline and warm-up (jit-compilation), reading the compilation log itself (compilation-and-inlining-logs), or C2's internal representation (c2-sea-of-nodes).
distributed-aggregation-and-barriers
Correct and recoverable aggregation across workers: algebraic laws, duplicate attempts, numeric reproducibility, mergeable summaries, barriers, joins, skew, checkpointing and partial results. Use when totals drift between runs, stragglers set job latency, worker percentiles are averaged, cardinality exhausts memory, or a join stalls on one task. It excludes request fan-out, streaming windows, percentile theory, message ordering and the broader hot-key repair catalogue.
distributed-failure-catalogue
Evidence-oriented recognition index for recurring distributed failure shapes: overload amplification, gray and asymmetric failure, split ownership, stale work, mixed versions, correlated faults, silent stagnation and destructive automation. Use to turn incident observations into discriminable hypotheses and route each to the skill owning diagnosis and remediation. It is not a substitute for the owner skill or causal evidence.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.