Skip to content

Instantly share code, notes, and snippets.

@jul-sh
Created January 9, 2026 16:19
Show Gist options
  • Select an option

  • Save jul-sh/cde89264bc98d4dc5a5e866cc22e8790 to your computer and use it in GitHub Desktop.

Select an option

Save jul-sh/cde89264bc98d4dc5a5e866cc22e8790 to your computer and use it in GitHub Desktop.
Enum-driven state skill for Claude
name description
enum-driven-state
Enforce enum-driven, type-safe state modeling so invalid states are unrepresentable; refactor boolean flags/"isX" helpers and conditional-only fields into enum cases with associated data.

Enum-Driven State (Type-Safe Modeling)

Use this skill when a codebase shows boolean flags, optional fields, or "only valid for X" comments that can be expressed as an enum with associated data. The goal is to make invalid states impossible to represent and to update call sites to match enum cases directly.

Core principles

  • Model state with enums + associated data; avoid parallel booleans and optionals that can drift out of sync.
  • Replace "only available for X" comments with enum structure.
  • Update usage patterns: prefer pattern matching at call sites over isX helpers or derived flags.
  • Avoid helper methods that reintroduce ambiguous states.

Heuristics

  • If you see isSomething flags or optional fields guarded by comments, consider an enum.
  • If a value is only valid in one branch, move it into the associated data for that enum case.
  • If a function accepts an item but assumes a specific subtype, change the function signature to accept the enum case data directly.

Refactor checklist (state + usage)

  • Replace isX computed properties with switch/if case at call sites.
  • Collapse optional sibling fields into enum-associated data.
  • Replace "only for X" API with enum-specific parameters.
  • Remove unused helpers that allowed invalid states to pass through.
  • Ensure database/serialization logic uses the enum discriminator directly.

Examples

Swift: "only for link" data

Before:

struct Item {
    let type: ItemType
    let linkTitle: String? // only for links
    let imageData: Data?   // only for images
}

After:

enum ItemContent {
    case text(String)
    case link(url: String, title: String?)
    case image(data: Data)
}

struct Item {
    let content: ItemContent
}

Swift: isX helper removal

Before:

if item.isLink { showLink(item) }

After:

if case .link(let url, let title) = item.content {
    showLink(url: url, title: title)
}

UI state flags

Before:

var isLoading: Bool
var error: String?

After:

enum LoadState {
    case loading
    case loaded
    case error(String)
}

When to stop

  • If refactors require broad API changes, stage them incrementally and avoid breaking unrelated paths.
  • If an enum refactor would force large architectural changes, propose a plan with the minimal safe cut.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment