kotlin-control-flow

Refactors Kotlin branching code into subject-based when expressions with guard conditions and exhaustive matching.

1|Updated Jul 6, 2026
One-click install
npx skills add https://github.com/citytexi/team-yg-pesonal-agent --skill kotlin-control-flow-citytexi
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: kotlin-control-flow
Source: https://github.com/citytexi/team-yg-pesonal-agent/tree/main/.claude/skills/kotlin-control-flow
Command: npx skills add https://github.com/citytexi/team-yg-pesonal-agent --skill kotlin-control-flow-citytexi

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Kotlin codebases often accumulate tangled if/else chains, nested branches, and repeated checks against the same value, which break smart casts and hide exhaustiveness bugs. This Skill provides a deterministic refactoring procedure to reshape branching code so the compiler can verify correctness. ## Core Features & Use Cases - Subject-based when conversion: Identifies the value being classified and rewrites scattered conditions into a single when (subject) expression. - Guard condition refactoring: Moves branch-local predicates into guarded branches, splitting comma-separated branches when needed. - Exhaustiveness and smart cast preservation: Ensures closed-domain when expressions stay exhaustive without unnecessary else, and verifies smart casts still work after the rewrite. - Use Case: When reviewing a pull request with a nested if inside a when branch over a sealed class, apply the procedure to flatten it into guarded branches that the compiler checks exhaustively. ## Quick Start Ask the assistant to refactor this Kotlin function's if/else chain into an exhaustive when expression using the kotlin-control-flow procedure.

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 expressions in Kotlin?▼

Identify the single value every branch classifies and make it the when subject, then move branch-local predicates into guard conditions. Keep guarded branches before their unguarded fallback for the same primary condition.

How do Kotlin guard conditions work in when expressions?▼

Guard conditions add an extra predicate to a branch using `if` after the primary condition, such as `is Event.Message if event.isUnread`. They require a when subject and do not apply to comma-separated branch conditions, which must be split.

When should I use else in a Kotlin when expression?▼

Use else only for open domains like server strings, integer status codes, or deliberate fallback paths. For closed domains such as enums, sealed types, and Booleans, handle every case explicitly so the compiler proves exhaustiveness.

Does refactoring control flow break Kotlin smart casts?▼

It can if the rewrite forces `as`, `!!`, temporary mutable vars, or duplicated casts. After reshaping, verify every branch still has the narrowed type where it is used, and keep the original shape if smart casts are lost.

When should I not use guard conditions in Kotlin?▼

Avoid guard conditions if the project's Kotlin version does not support them, when conditions are unrelated boolean checks with no common subject, or when flattening would obscure cleanup, transaction, or error-handling structure.