Claude Skills by robsonkades

Cross-process exclusion through leases, session/transaction locks and fencing: stale holders, owner-safe release, Redis/Redlock assumptions, database advisory locks, resource claims and lock-free alternatives. Use when reviewing SET NX/TTL, watchdog renewal, duplicate workers or a lock around a non-repeatable effect. Consensus implementation, leader election, local JVM locking and user-session concurrency are separate skills.

Testing the failure behaviour a distributed system claims: injecting latency, errors, partitions and process death; verifying that timeouts, retries, breakers and fallbacks do what their configuration says; checking idempotency against duplicate delivery; and running a controlled experiment in production rather than a chaos tool. Use when resilience configuration exists but has never been exercised, when a timeout or retry budget is being chosen, when an incident was caused by a dependency be...

Triage and routing entry point for cross-process Java systems. Classifies design questions and production symptoms, establishes boundary and fault assumptions, then selects the specialist skill for delivery, consistency, time, overload, partitioning, messaging, coordination, recovery or observability. Use when the next technical owner is unclear; it deliberately does not duplicate specialist guidance.

Designing trace topology and semantics: selecting actionable span boundaries, stable operation names, kinds, status and attributes; modelling synchronous, asynchronous, messaging, batch, retry and long-running workflows with parentage and links; and making traces usable with metrics, logs and profiles during incidents. Use when traces are noisy, fragmented, mis-parented, high-cardinality, misleading about errors, or unable to model batches and asynchronous causality. Sampling, propagation mec...

Coordinating a business operation across transactional owners: dual writes, XA/2PC, persisted sagas, compensation, pivot/forward recovery, ambiguous outcomes and manual repair. Use when a local transaction is expected to cover a broker or remote service, or in-flight workflow state cannot survive restart. Outbox delivery, idempotency, consistency, retries and single-database transaction design remain in their owning skills.

Deciding whether a boundary should be a process boundary, and designing it when it must be: what distribution actually costs (latency, serialisation, partial failure, lost atomicity, independent deployment), caller-driven remote granularity, and choosing between synchronous call, messaging and replication. Use when a module is proposed for extraction into a service, when microservices are being adopted without a named driver, when a service call sits inside a transaction, when one request fan...

Choosing where business rules live — Transaction Script, Domain Model or Table Module — from the shape of the logic rather than from convention, and recognising when the choice made no longer fits. Use when starting a new module and the "standard" layered structure is about to be applied by default, when a service class has grown past a thousand lines of procedural steps, when entities have only getters and setters and every rule sits in a service, when the same business rule is implemented i...

Using eBPF/bpftrace to measure kernel-visible behavior around a JVM without inventing attribution: selecting stable tracepoints versus kprobes/uprobes/USDT, scoping by process/thread/cgroup, tracking syscall/futex/scheduler/block-I/O lifecycles, managing BPF map loss and cardinality, resolving native and time-varying JIT code, and correlating—not summing—kernel, JFR, profile, and application evidence. Use when scheduler delay, kernel I/O, faults, networking, or cross-process interference may ...

Communicating engineering facts to people who will act on them: stating what is true, what follows from it, what is still uncertain, and the options and recommendation when needed. Covers raising a risk early, saying no to a request in a way that leaves a yes on the table, resolving technical disagreement by making the checkable claim checkable, escalating without going around someone, and status updates during an incident. Use when bad news has to travel, when a risk is visible but unspoken,...

The entry point for reasoning about an enterprise application's architecture: what makes these systems distinctive (data that outlives the code, concurrent users, integration, rules that change), the forces that shape every decision, how the kind of application changes the answers, and which specific skill answers which question. Use when starting on an unfamiliar enterprise codebase, when designing a new application or module and the first structural decisions are open, when someone asks "ho...

Detecting structural problems in an enterprise application from evidence, and telling genuine harm apart from unfamiliar-but-fine: anaemic domain models, god services, transaction-script sprawl, generic repositories, excessive layering and DTO mapping, leaky abstractions, distributed monoliths, persistence leakage, and abstractions that only move complexity. Use when reviewing an architecture or a large pull request, when adding a field touches seven files, when a "clean architecture" refacto...

The small structural patterns that hold an enterprise application together — Gateway, Mapper, Layer Supertype, Separated Interface, Registry, Special Case, Plugin and Service Stub — with the judgement about when each earns its place and when it is indirection. Use when an external system's API is being called directly from business code, when the same null check appears in twenty callers, when a base class is accumulating unrelated protected helpers, when a Registry or a static holder is bein...

Transaction boundaries as an architectural decision: where a transaction starts and ends, what isolation level actually buys, how propagation and rollback rules behave in practice, the costs of spanning a network call or a user's thinking time, and how to handle effects outside its atomic scope. Use when a use case writes twice and nobody can say whether it is atomic, when @Transactional sits on a repository or a controller, when a transaction stays open across an HTTP call or a message publi...

Epsilon as a measurement instrument (isolating allocation cost, failing fast against an allocation budget, sizing from time-to-OOM) and Shenandoah internals (the load reference barrier, the concurrent phase sequence, generational mode and its card-table remembered set, the heuristics and their thresholds, pacing, and the degenerated-versus-full fallbacks). Use when a hot path is claimed to be allocation-free, when benchmark numbers are polluted by collection, when an Epsilon catch block never...

C2 escape-analysis internals: connection graphs, escape-state propagation, flow insensitivity, bytecode escape summaries, scalar replacement and allocation merges, lock elimination, macro expansion, and deoptimization rematerialization. Use when a hot object still allocates, an inlining boundary changes EA, a product-build diagnostic is misleading, a disabled JFR allocation event is treated as proof, or recurring deoptimization makes eliminated objects costly. Does not cover introductory desi...

Producing a software estimate that carries its own uncertainty instead of hiding it: a range with explicit probability assumptions when supported, decomposition, PERT and the limits of summing task estimates, calibrating against what this team has actually done, and keeping estimate, target and commitment as three separate things. Use when asked how long something will take, when a single date is being requested for work that has not been broken down, when an estimate is being treated as a pr...

Choosing facts, asynchronous commands or request/response across services; then designing choreography/orchestration, payload authority, evolution horizon and consumer runtime. Use when a broker masks synchronous outcome dependence, workflows are unreconstructable, consumers read back every event, or publish and database commit form a dual write. Delivery, idempotency, ordering, outbox mechanics and schema evolution remain in their owning skills.

Event streams as authoritative state: adoption criteria, stream boundaries, expected-version appends, command idempotency, snapshots, projection correctness/rebuild, temporal replay, schema evolution and erasure. Use when event sourcing is proposed, projections drift, old payloads must evolve, or write/read visibility surprises users. Integration messaging, delivery, sagas, mutable-row locking and replica consistency remain separate skills.

Engineering the full lifecycle of tasks accepted by Java executors: ownership, admission, queue/grow behavior, execution context, result/failure observation, rejection, cancellation, scheduled/periodic semantics, context cleanup, shutdown/drain and recovery. Covers ThreadPoolExecutor, scheduled pools and thread-per-task/virtual-thread executors without treating factory defaults as capacity policy. Use when work disappears, queues grow, rejection or deploy loses work, or a virtual-thread migra...

Stating a system's fault model before designing against it: crash-stop, crash-recovery, omission, timing and Byzantine faults; partial failure and the third outcome of every remote call (unknown); gray failure and the slow node whose health check stays green; the eight fallacies as a checklist; blast radius, correlated versus independent failure, and the availability arithmetic of a dependency chain. Use when a design says "if the service is down" without defining down, when a retry is added ...

Proving and mitigating cache-line false sharing between independent locations with hot writes. Covers ownership and address/layout hypotheses, coherence/HITM evidence limits, JMH topology, arrays and object placement, `@Contended` module/restriction mechanics, grouping and padding, JOL/address validation, manual padding fragility, striping, compact headers, memory cost and cross-socket/NUMA validation. Use after excluding logical contention; cache fundamentals, lock contention and general obj...

Enumerating what a feature actually touches, with paths: which modules, layers, contracts, schemas, message topics, configuration and cross-cutting concerns change, which of those changes are visible outside the component, and where the change crosses a boundary that requires checking compatibility and ownership. Use before writing an implementation plan, when a feature is assumed to be local and might not be, when a change is about to alter a published contract or a stored schema, when the f...

Reading the repository for one specific feature: which technologies and patterns are actually present, which components the feature can reuse, which questions the code has already answered, and — stated as findings rather than silence — which it has not. Use when a scoped feature needs repository evidence before clarification or technology selection, when it is about to be built in a style the codebase does not use, when "the project uses X" is being asserted without a path, when an abstracti...

Defining a versioned API, event, data, integration, security, or operational contract for a feature after its behavior is agreed and before implementation is planned. Use when callers, consumers, stored data, or operators will depend on a changed boundary and its success, failure, ownership, compatibility, and verification must be explicit. Does not choose the architecture or transport (feature-solution-analysis), record the decision (feature-decision-analysis), or implement the contract (fea...

Keeping the decision log for a feature and, before each entry, answering the two questions that make it trustworthy: where the decision came from — the user, the repository, an organisational standard or the agent — and whose it was to take. Use when a technology is about to be chosen for a feature, when "the project already uses X" is being treated as a reason to use X, when a corporate standard is being asserted without a source, when an agent is about to commit to a database, a broker, a c...

Deciding whether a feature should split and, when useful, defining independently valuable Product or Tech child features. During definition, stays at outcomes, owners and acceptance; during engineering delivery preparation, defines implementation resources with stable identifiers, dependencies and validation. Use when several outcomes are bundled together, a small change is being over-split, dependencies or shared work need a breakdown, or progress lacks meaningful units. Does not approve sco...

Separating what is actually established about a feature request from what has been filled in: a ledger in which every fact carries its source, every assumption carries what would falsify it, and every unknown carries the impact of getting it wrong. Use at the start of a feature, when a request is one sentence long and the work is not, when a plan or an estimate is being built on statements nobody has checked, when two people describe the same feature differently, when picking up a feature som...

Owning a Product Feature or Tech Feature from definition intake to completion review: selecting proportionate depth, routing iterative analysis and explicit returns, holding readiness gates, and keeping versioned evidence another engineer can resume. Use when feature implementation is being prepared, resumed, or validated and its scope, contracts, decisions, or completion need a trustworthy lifecycle. Does not co-author the initial feature brief (collaborative-feature-definition), own any spe...

Implementing an authorized plan through coherent, verifiable resources: selecting ready work, implementing within accepted scope, running relevant checks and reading their results, and reconciling deviations and blockers. Use when implementation is starting, too many resources are partly finished, code diverges from the plan, a blocked resource has stalled unrelated work, or compilation is being treated as completion. Does not select repository gate policy (quality-gates), own test-design met...

Designing and evaluating the smallest PoC or experiment that resolves one decision-relevant uncertainty in a Product Feature or Tech Feature. Use when feasibility, compatibility, capacity, integration behavior, or a risky technical premise cannot be established from existing evidence and a bounded experiment can decide the next step. Does not produce production implementation, replace an ADR, or run broad exploratory research without a decision and threshold.

Assembling everything established about a feature into one document another engineer could execute without re-deriving the architecture: the resources in dependency order, the schema, contract, configuration and security changes named individually, the test strategy per resource, the migration, deployment and rollback story, and acceptance criteria a test can be written from. Use once the decisions are taken and before implementation starts, when a plan is a list of file names, when the plan ...

Keeping a feature's state true while it is being built: one status per resource with defined transitions, a validation line required before anything reaches done, and a persisted record current enough that another agent or another session can resume from it without asking. Use when a feature spans more than one sitting, when someone else may pick the work up, when the answer to "where are we" is a summary of the conversation, when resources are marked done because code was written for them, w...

The intake, pre-implementation, and completion gates for a feature: first validating the Product/Engineering or Tech Feature baseline, then checking that nothing implementation depends on is still unresolved, and after, checking that what was built is what was agreed and that the claim of completion is supported. Use before the first line of a planned feature is written, when implementation is about to start with an open blocking question, when a feature is about to be declared done, when "do...

Deciding what to ask the user about a feature, when to ask it, and what stops work until it is answered: reusing supplied answers and checking relevant evidence first, pricing each question by what changes if the answer is the other one, batching questions into rounds instead of interrogating, and marking the few that are genuinely blocking. Use when a feature request is ambiguous and the choice is between asking and assuming, when a long list of questions is about to be sent at once, when wo...

Naming what could go wrong with a specific feature in a form that can be acted on: the failure stated as an event rather than a worry, how anyone would find out it happened, what reduces its probability or its cost, and what is done if it happens anyway. Use before implementation on anything touching data, integrations, concurrency or a released contract, when a plan has a risk section containing only adjectives, when a HIGH risk has no detection signal, when a migration or a breaking change ...

Fixing what a feature includes and, more usefully, what it deliberately excludes: sorting every candidate item into required, recommended, optional, out of scope or future work, tracing each included item back to a requirement or a constraint, and catching the additions that arrived because they seemed like a good idea. Use when a feature is being planned and its edges are undefined, when a plan has grown a dashboard, a refactor or an abstraction nobody asked for, when "while we are in there"...

Producing the option set for a feature-level choice and the block that recommends one: always considering the simplest feasible approach, comparing complete options for the same boundary, evaluating the axes this feature is actually sensitive to, and saying what would have to be true for a rejected option to win. Use when a feature has a real choice in it — a mechanism, a storage strategy, a place to put the work — when one approach has already been assumed and nobody wrote down what else was...

Interpreting flame graphs as weighted sampled call-path aggregates: identifying the selection event and denominator, separating inclusive from leaf/self attribution, recognizing truncation, inlining, symbol and thread/task artifacts, using bottom-up and differential views, quantifying sample uncertainty, and turning a hotspot into a bounded causal experiment. Use when a graph looks CPU-heavy, idle-heavy, fragmented, changed after a deploy, or tempting to optimize by width alone. Does not coll...

Design and diagnose ForkJoinPool workloads using work-stealing topology, task graphs, granularity, common-pool interference, managed blocking, compensation limits and approximate pool telemetry. Use when parallel computation underutilizes CPUs, parallel streams interfere, joins stall, blocking collapses effective parallelism, or copied thresholds and pool constants are being treated as universal policy. Includes Java 25 API changes with version labels.

Deciding how much of a system may depend on its framework, and pricing that dependency honestly: which couplings are cheap and correct, which are expensive and reversible, which require staged redesign, and what "framework-independent" actually costs in mapping code. Use when a framework or major version upgrade is being planned or has stalled, when a domain class carries persistence or serialisation annotations, when someone proposes a framework-free domain and the price is not stated, when ...

G1's concurrent marking cycle: SATB and the pre-write barrier, the cycle phases and the single mark bitmap with TAMS, adaptive IHOP triggering, mark stack overflow and its consequences, humongous allocation and eager reclaim, and mixed-collection candidate selection. Use when the log shows "Concurrent Mark Restart for Mark Stack Overflow", when "Pause Full" follows incomplete marking cycles, when "Concurrent Mark From Roots" grows longer cycle over cycle, when marking starts well away from 45...

How G1 actually works: uniform regions and the ergonomic sizing formula, remembered sets and the card table with its write barrier, SATB and the pre-write barrier, the phases of an evacuation pause, humongous allocation and why it bypasses the young generation, and how the collection set is chosen for a mixed collection. Use when a pause is longer than the live-set size explains, when `Merge Heap Roots` or `Merge RS` dominates `-Xlog:gc+phases`, when legacy `To-space exhausted` or current `Ev...

Deriving G1 flag values from a latency SLO and proving they helped: what `MaxGCPauseMillis` actually controls, the young size bounds, IHOP and adaptive IHOP with an explicit safety margin, region size as the basis of every region-denominated calculation, `G1OldCSetRegionThresholdPercent` and `G1MixedGCCountTarget`, and the measure-derive-predict-validate loop. Use when GC flags were copied from another service, when `-Xms` differs from `-Xmx` in production, when mixed GC violates the SLO whil...

How JVM garbage collectors work, as the mental model behind every GC diagnosis: the generational hypothesis and where it fails, mark-sweep versus mark-compact versus copying, how survivors, allocation and roots affect collection cost, write barriers, safepoints and Time-To-SafePoint, and the JDK 25 collector landscape. Use when explaining why a collection is expensive, when the reported pause does not match the latency the client feels, when a young pause is long although little survived, whe...

Configuring and reading JVM unified GC logs: the -Xlog:gc* baseline with decorators and rotation, the cause field, the before->after->capacity triple and headroom, pause distribution, Eden-refill and old-region-growth estimates derived from region lines, adaptive tenuring pressure via gc+age, and correlation with -Xlog:safepoint. Use when a log needs to be interpreted, when GC logging is not enabled and the right GC tag-sets have to be chosen, when full collections or Metadata GC Threshold ap...

Abstract Factory in modern Java: the pattern exists to keep a _family_ of related objects mutually consistent when the family varies, not to centralise construction. Covers the family invariant that justifies it, when existing composition resolves the deployment-time case, when per-request or per-tenant selection benefits from a family provider, and how to express it as a record of suppliers or a sealed provider rather than a four-level interface hierarchy. Use when a factory interface is pro...

Adapter in modern Java: making an existing type usable through an interface it was not written for, and keeping a foreign model, vocabulary and failure mode from leaking inward. Covers object versus class adapters, why a lambda already adapts a single-method interface, the error-translation duty most adapters omit, when an adapter has quietly become a translator with business rules in it, and when a passthrough should be deleted. Use when integrating a vendor SDK or legacy type behind your ow...

Bridge in modern Java: separating an abstraction hierarchy from an implementation hierarchy so the two vary independently instead of multiplying into N×M classes. Covers the two-axis test that distinguishes it from Strategy, what to do when the matrix has illegal combinations, how implementor contracts account for backend cost and failure without losing required capabilities, and the thread-safety contract that belongs to the interface rather than to each implementation. Use when class names ...

Builder in modern Java: distinguish the original GoF separation of construction process from representation from the Effective Java fluent value builder. Covers selection signals rather than parameter-count thresholds, staged builders, invariant placement, mutable-builder concurrency hazards, Lombok/JPA boundaries, performance evidence, and test data builders. Use for ambiguous or telescoping construction, incremental input, multiple representations, or a builder that permits invalid combinat...

Chain of Responsibility in modern Java, and the pipeline it is usually confused with: the classical first-accepting form versus middleware where stages may all process and forward conditionally. Covers choosing between them, the unhandled-request policy that silent chains get wrong, ordering discipline when handlers are contributed independently, error propagation and partial state when a stage throws mid-chain, and why servlet filters and interceptor chains are this pattern already implement...