kotlin-control-flow

Guides writing and reviewing Kotlin when expressions, guards, and exhaustive branching.

1.0k|46|Updated May 12, 2026
One-click install
npx skills add https://github.com/chrisbanes/skills --skill kotlin-control-flow
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kotlin-control-flow
Source: https://github.com/chrisbanes/skills/tree/main/skills/kotlin-control-flow
Command: npx skills add https://github.com/chrisbanes/skills --skill kotlin-control-flow

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Kotlin codebases often accumulate tangled if/else chains, redundant casts, and non-exhaustive branches that hide bugs and resist refactoring. This Skill provides a structured procedure for choosing the right control-flow shape so the compiler proves correctness instead of the reader.

Core Features & Use Cases

  • Branch shape selection: Decision table mapping code shapes to the right construct, including subject when, subjectless when, guard conditions, early returns, and exhaustive when expressions.
  • Exhaustiveness and smart casts: Rules for naming every case in closed enums, sealed types, and nullable types while preserving smart-cast payloads without as, !!, or duplicate casts.
  • Refactoring recipes: Concrete Kotlin examples showing guarded branches, null-as-branch classification, and when to keep else for open server or platform values.
  • Use Case: While reviewing a pull request with a deeply nested if/else chain classifying UI events, apply the procedure to rewrite it as an exhaustive when with one guarded branch, then compile and test to confirm the refactor.

Quick Start

Ask the assistant to review this Kotlin when expression and refactor the branching logic using the kotlin-control-flow guidelines.

Frequently Asked Questions about kotlin-control-flow

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

FAQPage Schema
How do I replace nested if/else chains with when in Kotlin?

Name the value every branch tests and use when (subject) if one value is classified; otherwise keep a subjectless when or if/else. Use guard conditions for branch-local predicates and early returns to remove invalid state from the main path.

When should I use guard conditions in Kotlin when expressions?

Use a guard only on a subject when, after a primary condition, when the extra predicate belongs to that branch and an unguarded branch still handles the primary case. Place the guarded branch first and split comma-separated conditions instead of guarding one.

Should a Kotlin when over sealed types include an else branch?

For closed enums, Booleans, sealed types, and nullable closed types, name every case and omit else so the compiler enforces exhaustiveness. Keep an explicit else only for open server or platform values that need a real fallback or logging.

Why does Kotlin smart cast stop working after refactoring?

Smart casts break when code introduces as casts, !! operators, mutable temporaries, or duplicate casts. Verify casts still work after refactoring; if they do not, keep the original shape or take a smaller refactor step.

When should I avoid early returns in Kotlin functions?

Use early returns only to remove invalid or nullable state from the main path. Keep nesting that expresses cleanup, transactions, or error handling, since flattening that structure obscures intent.