agentleFS
codybromcodybrom/clairvoyance/skills/pull-complexity-down/SKILL.md

pull-complexity-down

Skill12 starsChanged 4 months agoMITView on GitHub

Checks whether complexity is pushed to callers or absorbed by implementations — the direction complexity flows. Use when callers must do significant setup, handle errors the module could resolve, or configure things they don't understand. Not for module depth (use deep-modules), knowledge leakage (use information-hiding), or exception strategy once an error must surface (use error-design).

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When invoked with $ARGUMENTS, focus the analysis on the specified file or module.

    line 10
  2. Distinctive:

    When callers must do significant setup or configuration

    line 17
  3. Distinctive:

    When callers handle errors or edge cases the module could handle internally

    line 18
  4. Distinctive:

    When configuration parameters are being added to an API

    line 19
  5. Distinctive:

    When evaluating decorator or wrapper patterns

    line 20
  6. Distinctive:

    If any condition fails:

    line 38
  7. Distinctive:

    All callers use the same value → make it a constant

    line 40
  8. Distinctive:

    When uncertain about a decision, making it configurable feels responsible but that is avoidance dressed as engineering.

    line 48

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Pull Complexity Downwards Review Lens

When invoked with $ARGUMENTS, focus the analysis on the specified file or module. Read the target code first, then apply the checks below.

Evaluate whether complexity is absorbed into implementations or pushed up to callers.

When to Apply

  • Designing or reviewing a module's interface
  • When callers must do significant setup or configuration
  • When callers handle errors or edge cases the module could handle internally
  • When configuration parameters are being added to an API
  • When evaluating decorator or wrapper patterns

Core Principles

The Core Asymmetry

One implementer, many callers. Complexity in the implementation is paid once. Complexity in the interface is paid by every caller. (The same asymmetry underlies deep-modules' "Depth Principle" — applied there to overall interface depth, applied here to which side of the interface should absorb a given piece of complexity.)

When developers encounter a hard problem, the path of least resistance is to push it upward: throw an exception, add a configuration parameter, define an abstract policy. These moves feel like good engineering. But all you have done is distribute the decision to a larger number of people who typically have less context.

Configuration Parameter Test - The Three AND Conditions

Configuration parameters are not a feature. They are a symptom of an incomplete module. Every parameter exported is a decision the developer chose not to make.

  1. Different callers genuinely need different values, AND
  2. The correct value cannot be determined automatically, AND
  3. The impact is significant enough to justify the interface cost

If any condition fails:

  • All callers use the same value → make it a constant
  • The module can compute a good value → compute it dynamically
  • The impact is negligible → pick a sensible default

Even for legitimate parameters, provide reasonable defaults so users only need to provide values under exceptional conditions.

Dynamic computation beats static configuration. A network protocol that measures response times and computes retry intervals automatically is superior to one that exports a retry-interval parameter: better accuracy, adapts to conditions, and the parameter disappears from the interface entirely.

When uncertain about a decision, making it configurable feels responsible but that is avoidance dressed as engineering. Configuration parameters and thrown exceptions share the same impulse because both inflict complexity on callers.

Three AND Conditions: When NOT to Pull Down

Pulling complexity down has a limit. Adding a backspace(cursor) method to a text class appears to absorb UI complexity, but the text class has nothing to do with the backspace key. That is UI knowledge forced into the wrong module, which is information leakage masquerading as good design.

All Three Must Hold:

  1. The complexity is closely related to the module's existing functionality
  2. Pulling it down simplifies the rest of the application
  3. Pulling it down simplifies the module's interface

Failing any single one means the complexity belongs somewhere else.

Related Techniques

Context objects and decorator alternatives are tools for pulling complexity down. Both are detailed in deep-modules: context objects solve pass-through variables. Decorator alternatives prevent shallow wrapper layers.

Review Process

  1. Inventory interface elements: List every parameter, exception, and constraint callers must handle
  2. Apply the core asymmetry: For each: could the module handle this internally?
  3. Test configuration parameters: Does each pass the three AND conditions?
  4. Check for dynamic alternatives: Could any static configuration be computed from internal measurements?
  5. Evaluate decorators: Shallow pass-through layer, or genuine abstraction?
  6. Recommend simplification: Propose specific interface reductions

Red flag signals for complexity direction are cataloged in red-flags (Overexposure).

References

For deeper coverage, read the following:

  • Configuration parameter audit: Patterns for recognizing and eliminating unnecessary config parameters

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.