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.