lowy

Review module boundaries against axes of change using volatility-based decomposition.

10|2|Updated Jan 24, 2026
One-click install
npx skills add https://github.com/nrdxp/predicate --skill lowy-nrdxp
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: lowy
Source: https://github.com/nrdxp/predicate/tree/main/skills/lowy
Command: npx skills add https://github.com/nrdxp/predicate --skill lowy-nrdxp

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Software architectures often decompose code by functionality (UserService, PaymentController), which maximizes the blast radius of every change. This Skill evaluates whether module boundaries actually encapsulate axes of change, catching functional decomposition disguised as good design before it compounds into unmaintainable coupling. ## Core Features & Use Cases - Volatility Analysis: Names, classifies (sequence vs. activity), and challenges each axis of change behind a boundary, rejecting speculative or merely variable concerns. - Blast Radius Tracing: Walks plausible change scenarios through the code to count how many modules a single change would touch, including layering and symmetry checks. - Interface Stability Review: Verifies interfaces expose atomic business verbs that stay stable when the encapsulated volatility changes. - Use Case: During an architecture review of a new service split, run this workflow to discover that a BillingManager groups unrelated volatilities (payment provider, pricing rules, notification channel) behind one functional boundary, then get concrete restructuring actions per finding. ## Quick Start Ask the agent to run /lowy on the module boundaries in this pull request and report which ones track functionality rather than volatility.

Frequently Asked Questions about lowy

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

FAQPage Schema
How do I review module boundaries with volatility-based decomposition?

Run the /lowy workflow on the boundaries under review. It names the volatility behind each boundary, classifies it as sequence or activity volatility, traces change blast radius, and outputs findings with concrete restructuring actions.

What is the difference between functional and volatility-based decomposition?

Functional decomposition groups code by what it does (UserService, PaymentController), so one change cuts across many modules. Volatility-based decomposition groups code by what changes independently, encapsulating each axis of change behind a stable interface.

When should I use /lowy versus /hickey for architecture review?

Use /lowy for the temporal question of whether boundaries encapsulate axes of change, and /hickey for the spatial question of whether independent concerns are interleaved. Running both gives full coverage, and conflicts are resolved by unifying the volatile axis without complecting strategies.

Does every varying concern deserve its own module boundary?

No. The workflow distinguishes variable from volatile: adding a data attribute is variable but not volatile. Speculative changes without history, roadmap, or domain certainty are rejected, and weak volatilities can be folded into existing boundaries.

What are the limitations of volatility-based decomposition review?

It depends on correctly identifying real, observed volatilities, so it can miss axes of change in unfamiliar domains. It also optimizes for change containment, which can conflict with other goals like simplicity, requiring judgment when lenses disagree.