Claude Code Plugins

Community-maintained marketplace

Feedback

code-priority

@atusy/dotfiles
22
0

Guide design decisions using the State > Coupling > Complexity > Code priority framework. Use when evaluating tradeoffs, reviewing design choices, deciding between implementations, or when code volume seems to be prioritized over deeper concerns.

Install Skill

1Download skill
2Enable skills in Claude

Open claude.ai/settings/capabilities and find the "Skills" section

3Upload to Claude

Click "Upload skill" and select the downloaded ZIP file

Note: Please verify skill by going through its instructions before using it.

SKILL.md

name code-priority
description Guide design decisions using the State > Coupling > Complexity > Code priority framework. Use when evaluating tradeoffs, reviewing design choices, deciding between implementations, or when code volume seems to be prioritized over deeper concerns.

INSTRUCTIONS

Apply the code optimization priority framework: sacrifice lower priorities to improve higher ones.

The Priority Hierarchy

State > Coupling > Complexity > Code
Priority Focus Why It Matters
1. State Minimize mutable state Stateless code works identically in sequential, parallel, and distributed contexts
2. Coupling Reduce dependencies Loose coupling enables independent change and testing
3. Complexity Simplify logic Lower cognitive load, fewer bugs
4. Code Reduce volume Less to read and maintain

Core Principle

"It's okay to increase coupling if it makes your code more stateless."

Each level can be sacrificed to improve a higher-priority concern:

  • More code is acceptable for less complexity
  • More complexity is acceptable for less coupling
  • More coupling is acceptable for less state

Decision Framework

When evaluating design choices:

1. Does Option A have less mutable state than Option B?
   Yes → Prefer Option A (even if more coupled/complex/verbose)
   No  ↓
2. Does Option A have less coupling than Option B?
   Yes → Prefer Option A (even if more complex/verbose)
   No  ↓
3. Does Option A have less complexity than Option B?
   Yes → Prefer Option A (even if more verbose)
   No  ↓
4. Prefer the option with less code

Why This Order?

State is hardest to reason about:

  • Requires tracking "before" and "after" conditions
  • Creates implicit dependencies between operations
  • Breaks parallelization and distribution
  • Explodes test setup complexity

Beginners optimize the wrong thing:

  • Code volume is most visible, so it gets optimized first
  • But state, coupling, and complexity matter more for maintainability
  • Experience teaches that a few extra lines are cheap; hidden state is expensive

Practical Examples

Prefer Stateless (Accept More Coupling)

# More state, less coupling
class Processor:
    def __init__(self):
        self.result = None

    def process(self, data):
        self.result = transform(data)

    def get_result(self):
        return self.result

# Less state, more coupling (PREFERRED)
def process(data, transformer):
    return transformer(data)

Prefer Less Coupling (Accept More Code)

# Less code, more coupling
def create_user(data):
    user = User(**data)
    db.save(user)           # Coupled to global db
    email.send_welcome()    # Coupled to global email
    return user

# More code, less coupling (PREFERRED)
def create_user(data, repository, notifier):
    user = User(**data)
    repository.save(user)
    notifier.send_welcome(user)
    return user

Prefer Less Complexity (Accept More Code)

# Less code, more complexity
result = data if condition else (default if not other else fallback)

# More code, less complexity (PREFERRED)
if condition:
    result = data
elif other:
    result = fallback
else:
    result = default

Review Checklist

When reviewing code or design:

  • Is state being introduced where a pure function would work?
  • Are global/shared dependencies creating hidden coupling?
  • Is clever code sacrificing readability for brevity?
  • Is the author optimizing for code volume over deeper concerns?

Anti-Patterns

Anti-Pattern Problem Better Approach
Global singletons Maximum coupling + hidden state Dependency injection
Mutable shared state Race conditions, test complexity Immutable data, message passing
Clever one-liners Complexity hidden in density Explicit multi-line logic
Premature DRY Wrong abstraction, coupling Tolerate duplication until pattern is clear

Integration with Other Practices

This framework complements:

  • Tidy First: Structural improvements often reduce coupling
  • TDD: Tests reveal hidden state and coupling problems early
  • Refactoring: Many patterns specifically target state and coupling

Reference

Based on: curun1r's comment on Hacker News, attributed to Sandi Metz's design principles