xtdb-object-boundaries

Classifies Kotlin objects by concurrency role to guide state ownership and boundary decisions.

3.0k|192|Updated Mar 19, 2018
One-click install
npx skills add https://github.com/xtdb/xtdb --skill xtdb-object-boundaries
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: xtdb-object-boundaries
Source: https://github.com/xtdb/xtdb/tree/main/.claude/skills/xtdb-object-boundaries
Command: npx skills add https://github.com/xtdb/xtdb --skill xtdb-object-boundaries

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Deciding where state and behavior belong in a concurrent Kotlin codebase is error-prone: misplaced fields cause torn reads, latching monitor defects, and dangling references. This Skill provides a decision framework for assigning every object a role and placing state correctly before writing or reviewing code.

Core Features & Use Cases

  • Role Classification: Categorizes every object as an Active Object, Passive Object, or Monitor Object using mechanical tests based on select, coroutineScope, and stored CoroutineScope usage.
  • Value Boundary Design: Applies Clojure's identity/state model and aggregate design to decide when two fields are one value, requiring a single atomic swap behind a sealed hierarchy.
  • Defect Recognition: Identifies monitor defects such as latching conditions (e.g., the Watchers failure mode) and transient state that must not be published mid-flight.
  • Use Case: When reviewing a diff that adds a Map<Id, State> beside the objects it identifies, use this Skill to determine whether the state belongs in a new object, an existing value, or a transient accumulator.

Quick Start

Ask the AI to apply the xtdb-object-boundaries skill to decide which object should own a new field you are adding to a Kotlin class.

Frequently Asked Questions about xtdb-object-boundaries

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide which Kotlin class should own a piece of state?▼

Identify the object's role first: an Active Object owns a select and decides what happens next, a Passive Object completes work on the caller's coroutine, and a Monitor holds state others wait on. One object holds one role, so state belongs with the object whose control flow governs it.

How to tell if a Kotlin coroutine object is active or passive?▼

Check whether it offers a choice among simultaneously-ready events via a select with multiple clauses. A long-running suspending loop driven by one source is passive; coroutineScope and withContext join their children so they stay passive, while a stored CoroutineScope plus launch escapes.

When should two fields be merged into one immutable value?▼

Two fields are one value when you cannot name a state the identity holds between them. Group them into a sealed hierarchy behind one reference with a single atomic swap, keep the swap function pure for CAS retries, and keep the value small.

What is a latching monitor condition and why is it a defect?▼

A monitor's condition must be re-evaluable so a later waiter can reach a different verdict. A latching condition, like a Failed state that never clears, makes every later waiter fail permanently, and swapping the concurrency primitive does not fix it.

When is mutable accumulating state safe in concurrent Kotlin code?▼

Mutable accumulation is safe only as a transient: owned by exactly one writer, never published mid-flight, and handed over complete. If anyone reads it while it is being built, it must be an atom where every observable step is a swap.