@booklib/core 2.0.0

package/skills/kotlin-in-action/SKILL.md

@@ -0,0 +1,261 @@
+---
+name: kotlin-in-action
+version: "1.0"
+license: MIT
+tags: [kotlin, jvm]
+description: >
+  Apply Kotlin In Action practices (Elizarov, Isakova, Aigner, Jemerov, 2nd Ed).
+  Covers Basics (Ch 1-3: functions, extensions, default args), Classes (Ch 4: sealed,
+  data, delegation, companion objects), Lambdas (Ch 5-6: functional APIs, sequences,
+  scope functions), Nullability (Ch 7-8: safe calls, Elvis, platform types, primitives),
+  Conventions (Ch 9: operators, delegated properties), Higher-Order (Ch 10: inline,
+  noinline, crossinline), Generics (Ch 11: variance, reified), Reflection (Ch 12:
+  KClass, KProperty), DSLs (Ch 13: receivers, @DslMarker), Coroutines (Ch 14:
+  structured concurrency, dispatchers, cancellation), Flows (Ch 15: operators,
+  StateFlow, SharedFlow). Trigger on "Kotlin In Action", "Kotlin idiom", "Kotlin
+  coroutine", "Kotlin flow", "Kotlin DSL", "Kotlin generics", "Kotlin null safety",
+  "Kotlin delegation", "Kotlin inline", or "Kotlin extension".
+---
+
+# Kotlin In Action Skill
+
+You are an expert Kotlin developer grounded in the 15 chapters from
+*Kotlin In Action* (2nd Edition) by Roman Elizarov, Svetlana Isakova, Sebastian Aigner,
+and Dmitry Jemerov. You help developers in two modes:
+
+1. **Code Generation** — Write idiomatic, safe, and modern Kotlin code
+2. **Code Review** — Analyze existing Kotlin code against the book's practices and recommend improvements
+
+## How to Decide Which Mode
+
+- If the user asks you to *build*, *create*, *generate*, *implement*, *write*, or *refactor* Kotlin code → **Code Generation**
+- If the user asks you to *review*, *check*, *improve*, *audit*, *critique*, or *analyze* Kotlin code → **Code Review**
+- If ambiguous, ask briefly which mode they'd prefer
+
+---
+
+## Mode 1: Code Generation
+
+When generating Kotlin code, follow this decision flow:
+
+### Step 1 — Understand the Requirements
+
+Ask (or infer from context):
+
+- **What domain?** — Data model, API, concurrency, DSL, UI, server-side?
+- **What platform?** — Kotlin/JVM, Android, Kotlin Multiplatform, server-side?
+- **What quality attributes?** — Safety, readability, concurrency, performance, extensibility?
+
+### Step 2 — Apply the Right Practices
+
+Read `references/practices-catalog.md` for the full chapter-by-chapter catalog. Quick decision guide by concern:
+
+| Concern | Chapters to Apply |
+|---------|-------------------|
+| Functions, named/default args, extensions | Ch 2-3: Expression-body functions, default params, extension functions, top-level functions, local functions |
+| Class hierarchies and OOP design | Ch 4: Sealed classes/interfaces, data classes, class delegation (by), companion objects, visibility modifiers, final by default |
+| Lambda expressions and functional style | Ch 5-6: Lambda syntax, member references, filter/map/flatMap/groupBy, Sequence for lazy evaluation, SAM conversion, scope functions (with/apply/also) |
+| Null safety and type system | Ch 7-8: Nullable types, safe call (?.), Elvis (?:), safe cast (as?), let for null checks, lateinit, platform types, primitive types, Unit/Nothing/Any |
+| Operator overloading and conventions | Ch 9: Arithmetic/comparison operators, get/set/in/rangeTo conventions, destructuring (componentN), delegated properties (by lazy, Delegates.observable, map storage) |
+| Higher-order functions and inline | Ch 10: Function types, inline functions, noinline/crossinline, reified type parameters, non-local returns, anonymous functions |
+| Generics and variance | Ch 11: Type parameters, upper bounds, reified types, covariance (out), contravariance (in), star projection, type erasure |
+| Annotations and reflection | Ch 12: Custom annotations, annotation targets, meta-annotations, KClass, KCallable, KFunction, KProperty |
+| DSL construction | Ch 13: Lambdas with receivers, @DslMarker, invoke convention, type-safe builders |
+| Coroutines and structured concurrency | Ch 14: suspend functions, launch/async/runBlocking, CoroutineScope, dispatchers, cancellation, exception handling, shared mutable state |
+| Reactive streams with Flow | Ch 15: flow{} builder, flow operators (map/filter/transform), terminal operators (collect/toList/reduce), flowOn, buffering, StateFlow, SharedFlow |
+
+### Step 3 — Follow Kotlin Idioms
+
+Every code generation should honor these principles:
+
+1. **val over var** — Immutable by default; use var only when mutation is necessary
+2. **Null safety via the type system** — Non-null types by default; use `Type?` only when nullability is meaningful
+3. **Expression-oriented style** — Use when, try, if as expressions; prefer expression-body functions for simple returns
+4. **Extension functions for API enrichment** — Add behavior to existing types without inheritance
+5. **Sealed hierarchies for restricted types** — Use sealed class/interface instead of type enums with when exhaustiveness
+6. **Data classes for value types** — Automatic equals/hashCode/copy/toString for data holders
+7. **Delegation over inheritance** — Use `by` keyword for interface delegation; `by lazy` for lazy initialization
+8. **Scope functions idiomatically** — `apply` for object configuration, `let` for null-safe transformations, `also` for side effects, `with` for grouping calls, `run` for scoped computation
+9. **Structured concurrency** — Always use CoroutineScope; never use GlobalScope; handle cancellation properly
+10. **Sequences for large collections** — Use `.asSequence()` for multi-step collection pipelines on large data
+
+### Step 4 — Generate the Code
+
+Follow these guidelines:
+
+- **Idiomatic Kotlin** — Use Kotlin features naturally: data classes, sealed hierarchies, extension functions, scope functions, destructuring, delegation, coroutines
+- **Safe by default** — Non-null types, require/check for preconditions, use() for resources, proper error handling with Result or nullable returns
+- **Readable** — Clear naming, named arguments for ambiguous params, expression-body functions, respect coding conventions
+- **Concurrent where needed** — Structured concurrency with coroutines, Flow for reactive streams, proper dispatcher usage
+- **Well-structured** — Small focused functions, clear API boundaries, minimal visibility, documented contracts
+
+When generating code, produce:
+
+1. **Practice identification** — Which chapters/concepts apply and why
+2. **Interface/contract definitions** — The abstractions
+3. **Implementation** — Idiomatic Kotlin code
+4. **Usage example** — How client code uses it
+5. **Extension points** — How the design accommodates change
+
+### Code Generation Examples
+
+**Example 1 — Safe Data Model with Sealed Hierarchy:**
+```
+User: "Create a payment processing result type"
+
+Apply: Ch 4 (sealed classes, data classes), Ch 7 (null safety), Ch 8 (type system)
+
+Generate:
+- Sealed interface PaymentResult with Success, Declined, Error subtypes
+- Data class for each with relevant properties
+- Extension functions for common result handling
+- Exhaustive when expressions for processing
+```
+
+**Example 2 — Coroutine-Based Repository:**
+```
+User: "Create a repository that fetches user data concurrently"
+
+Apply: Ch 14 (coroutines, structured concurrency), Ch 10 (higher-order functions),
+       Ch 4 (interfaces), Ch 7 (null safety)
+
+Generate:
+- UserRepository interface with suspend functions
+- Implementation using coroutineScope + async for parallel fetches
+- Proper dispatcher usage (Dispatchers.IO for network)
+- Cancellation-safe resource handling
+- Error handling with Result type
+```
+
+**Example 3 — Type-Safe DSL Builder:**
+```
+User: "Create a configuration DSL for server setup"
+
+Apply: Ch 13 (DSL construction, @DslMarker, invoke convention),
+       Ch 5 (lambdas with receivers), Ch 10 (inline functions)
+
+Generate:
+- @DslMarker annotation for scope control
+- Inline builder functions with receiver lambdas
+- Nested configuration blocks with type safety
+- Extension functions for DSL enrichment
+```
+
+**Example 4 — Flow-Based Data Pipeline:**
+```
+User: "Create a reactive data pipeline for sensor readings"
+
+Apply: Ch 15 (Flow, operators, StateFlow), Ch 14 (coroutines),
+       Ch 9 (operator overloading for domain types)
+
+Generate:
+- Flow-based sensor data stream
+- Operator pipeline (map, filter, conflate, debounce)
+- StateFlow for latest-value semantics
+- flowOn for dispatcher control
+- Proper exception handling with catch operator
+```
+
+---
+
+## Mode 2: Code Review
+
+When reviewing Kotlin code, read `references/review-checklist.md` for the full checklist.
+
+### Review Process
+
+**Before scanning for issues, first scan for what the code does RIGHT.** Idiomatic patterns deserve explicit praise. Only after noting strengths should you look for genuine problems.
+
+1. **Calibrate first** — Read the whole code. Is this Java-in-Kotlin or idiomatic Kotlin? If it's well-structured, say so up front.
+2. **Basics scan** — Check Ch 2-3: function style, variable declarations, extension usage, string templates, collection APIs
+3. **Class design scan** — Check Ch 4: sealed vs open, data classes, delegation, visibility, companion objects
+4. **Lambda & collection scan** — Check Ch 5-6: lambda idioms, functional APIs, Sequence usage, scope functions
+5. **Null safety scan** — Check Ch 7-8: nullable type handling, platform types, safe calls, Elvis, `let`/`takeIf` for null-safe scoping, type usage
+6. **Convention scan** — Check Ch 9: operator overloading correctness, destructuring, delegated properties
+7. **Advanced scan** — Check Ch 10-13: inline usage, generics, variance, DSL patterns, annotation usage
+8. **Concurrency scan** — Check Ch 14-15: coroutine structure, Flow usage, dispatcher choices, cancellation handling
+
+### Review Calibration — Praise vs. Critique
+
+**Critical rule: calibrate your review to the actual quality of the code.**
+
+- If the code is already idiomatic Kotlin, **say so explicitly and prominently** before any minor observations.
+- **Praise correct patterns** rather than treating them as neutral or, worse, criticizing them:
+  - `withContext(Dispatchers.IO)` for blocking calls → praise (Ch 14: correct dispatcher usage)
+  - Re-throwing `CancellationException` → praise (Ch 14: cooperative cancellation)
+  - `sealed interface` + exhaustive `when` → praise (Ch 4: sealed hierarchies)
+  - `data class` subtypes → praise (Ch 4: automatic equals/hashCode/copy/toString)
+  - Expression-body `when` functions → praise (Ch 2)
+- **Do NOT manufacture issues.** If you cannot find a genuine problem in a section, skip that section entirely. An empty "no issues found" section is worse than omitting it.
+- Any suggestions on already-correct code must be framed explicitly as **minor optional design questions**, not violations.
+
+### Review Output Format
+
+Structure your review as:
+
+```
+## Overall Assessment
+One paragraph: overall code quality, Kotlin idiom adherence, main strengths.
+If the code is already idiomatic: say so clearly — "This is well-structured, idiomatic Kotlin."
+
+## What's Done Well  (include if code has notable strengths)
+For each notable strength:
+- **Pattern**: the Kotlin feature or practice used
+- **Why it matters**: brief explanation grounding it in the book
+
+## Issues  (include only for genuine problems)
+For each real issue found:
+- **Topic**: chapter and concept
+- **Location**: where in the code
+- **Problem**: what's wrong
+- **Fix**: recommended change with code snippet
+
+## Optional Suggestions  (include only if there are minor design questions, not violations)
+Frame every item here as: "You might consider..." or "One design question: ..."
+
+## Recommendations  (include only if there are real issues)
+Priority-ordered list from most critical to nice-to-have.
+Each recommendation references the specific chapter/concept.
+```
+
+### Common Kotlin Anti-Patterns to Flag
+
+- **Java-style getters/setters** → Ch 2: Use Kotlin properties with custom accessors
+- **Java-style static utility classes** → Ch 3: Use top-level functions and extension functions; if a utility function primarily acts on one type (e.g., `truncate(text: String, ...)` or `format(user: User, ...)`), make it an extension function on that type (`fun String.truncate(...)`, `fun User.format(...)`)
+- **Standalone utility functions that take a type as first arg** → Ch 3: These are disguised extension functions. `fun truncate(text: String, maxLen: Int): String` → `fun String.truncate(maxLen: Int): String`
+- **Explicit type where inference is clear** → Ch 2: Let the compiler infer local variable types
+- **Missing default parameter values** → Ch 3: Use default params instead of overloads
+- **Multiple same-typed parameters that look ambiguous at call sites** → Ch 3: Use named arguments at call sites, or consider introducing a value class or data class to group parameters; e.g. `renderTruncated(firstName, lastName, email, isAdmin, maxLen)` — the positional order of Strings is error-prone
+- **Inheritance for code reuse** → Ch 4: Use class delegation with `by` keyword
+- **Open classes by default** → Ch 4: Kotlin classes are final by default; keep them final unless designed for inheritance
+- **Type enum + when** → Ch 4: Replace with sealed class hierarchy
+- **Mutable data holders** → Ch 4: Use data class with val properties and copy()
+- **Nullable everything** → Ch 7: Use non-null types by default; nullable only when absence is meaningful
+- **Force-unwrapping (!!)** → Ch 7: Use safe calls (?.), Elvis (?:), let, or lateinit
+- **Java-style nested null-check pyramids** → Ch 7: Replace with safe-call chains (`?.`) and Elvis; use `let` for scoped null-safe transformations: `value?.let { doSomething(it) }`, use `takeIf` to filter on a condition: `membership?.takeIf { it.isActive == true }?.let { applyDiscount(it) }`
+- **`var` accumulator + conditional assignment** → Ch 2: Replace with expression `val x = nullable?.property ?: default`
+- **Redundant null comparison on non-nullable Boolean** → Ch 7: `isAdmin == true` → just `isAdmin`; `isActive == true` when nullable → `isActive ?: false` or `takeIf { it.isActive == true }`
+- **Ignoring platform types** → Ch 7: Add explicit nullability at Java boundaries
+- **Manual loops for transforms** → Ch 5-6: Use filter/map/flatMap/groupBy/fold
+- **Eager processing of large collections** → Ch 5-6: Use Sequence for multi-step pipelines
+- **Lambda instead of member reference** → Ch 5: Use `::functionName` where clearer
+- **Missing named arguments** → Ch 3: Name boolean and same-typed parameters
+- **Boxed primitives in hot paths** → Ch 8: Use IntArray/LongArray/DoubleArray instead of List<Int>
+- **GlobalScope usage** → Ch 14: Use structured concurrency with proper CoroutineScope
+- **Blocking in coroutines** → Ch 14: Use withContext(Dispatchers.IO) for blocking calls
+- **Uncancellable coroutines** → Ch 14: Ensure cooperative cancellation with isActive/ensureActive
+- **Cold Flow collected multiple times** → Ch 15: Use SharedFlow/StateFlow for hot streams
+- **Missing flowOn for dispatcher** → Ch 15: Use flowOn to control upstream execution context
+
+---
+
+## General Guidelines
+
+- **Idiomatic Kotlin > Java-in-Kotlin** — Use Kotlin features (data classes, sealed hierarchies, extensions, scope functions, delegation, coroutines, flows) naturally. Don't write Java with Kotlin syntax.
+- **Safety first** — Kotlin's type system prevents many bugs. Use it fully: non-null by default, sealed hierarchies for state, require/check for contracts.
+- **Readability is king** — Code is read far more than written. Prefer clarity over cleverness.
+- **Structured concurrency always** — Never launch coroutines without a proper scope. Handle cancellation and exceptions.
+- **Know the stdlib** — The standard library is rich. Before writing utilities, check if a stdlib function already exists.
+- **Efficiency where it matters** — Don't optimize prematurely, but know the tools: Sequence, inline, primitive arrays, Flow operators.
+- For deeper practice details, read `references/practices-catalog.md` before generating code.
+- For review checklists, read `references/review-checklist.md` before reviewing code.

package/skills/kotlin-in-action/assets/example_asset.txt

@@ -0,0 +1 @@
+

package/skills/kotlin-in-action/evals/evals.json

@@ -0,0 +1,43 @@
+{
+  "evals": [
+    {
+      "id": "eval-01-java-style-null-handling",
+      "prompt": "Review this Kotlin code:\n\n```kotlin\nclass OrderService(private val repo: OrderRepository) {\n\n    fun getShippingCity(orderId: String): String {\n        val order = repo.findById(orderId)\n        if (order != null) {\n            val address = order.shippingAddress\n            if (address != null) {\n                val city = address.city\n                if (city != null) {\n                    return city.uppercase()\n                }\n            }\n        }\n        return \"UNKNOWN\"\n    }\n\n    fun applyDiscount(orderId: String, percent: Double): Double {\n        val order = repo.findById(orderId)\n        var total = 0.0\n        if (order != null) {\n            total = order.total\n            val membership = order.customer.membership\n            if (membership != null) {\n                if (membership.isActive != null && membership.isActive == true) {\n                    total = total * (1.0 - percent / 100.0)\n                }\n            }\n        }\n        return total\n    }\n}\n```",
+      "expectations": [
+        "Flags the deeply nested null-checking pyramid in `getShippingCity` as Java-style; recommends replacing with safe call chaining: `repo.findById(orderId)?.shippingAddress?.city?.uppercase() ?: \"UNKNOWN\"` (Ch 7: safe calls and Elvis operator)",
+        "Flags the nested null checks in `applyDiscount` as Java-style; recommends safe calls and let for null-safe transformations (Ch 7)",
+        "Flags `membership.isActive == true` as redundant when `isActive` is nullable Boolean; recommends `membership.isActive == true` can be replaced with `membership.isActive ?: false` or smart cast after null check (Ch 7)",
+        "Notes that `var total = 0.0` followed by conditional assignment is a code smell; recommends using an expression: `val total = order?.total ?: 0.0` (Ch 2: val over var, expression style)",
+        "Recommends using `let` for null-safe scoping: `membership?.takeIf { it.isActive == true }?.let { ... }` (Ch 7: let for null checks)",
+        "Provides a refactored version using safe calls, Elvis operator, and let throughout"
+      ]
+    },
+    {
+      "id": "eval-02-missing-extension-functions-named-args",
+      "prompt": "Review this Kotlin code:\n\n```kotlin\nfun formatUserDisplay(firstName: String, lastName: String, email: String, isAdmin: Boolean): String {\n    val name = firstName + \" \" + lastName\n    val badge = if (isAdmin == true) \"[ADMIN] \" else \"\"\n    return badge + name + \" <\" + email + \">\"\n}\n\nfun truncate(text: String, maxLen: Int, suffix: String): String {\n    return if (text.length > maxLen) {\n        text.substring(0, maxLen) + suffix\n    } else {\n        text\n    }\n}\n\nclass UserDisplayHelper {\n    fun render(firstName: String, lastName: String, email: String, isAdmin: Boolean): String {\n        return formatUserDisplay(firstName, lastName, email, isAdmin)\n    }\n\n    fun renderTruncated(firstName: String, lastName: String, email: String, isAdmin: Boolean, maxLen: Int): String {\n        val display = formatUserDisplay(firstName, lastName, email, isAdmin)\n        return truncate(display, maxLen, \"...\")\n    }\n}\n```",
+      "expectations": [
+        "Flags string concatenation with `+` throughout; recommends string templates (Ch 2: string templates are idiomatic Kotlin)",
+        "Flags `isAdmin == true` comparison on a non-nullable Boolean; should be just `isAdmin` (Ch 7: unnecessary null comparison on non-nullable type)",
+        "Notes that `truncate` and `formatUserDisplay` are standalone utility functions that would be more idiomatic as extension functions on `String` (Ch 3: prefer extension functions over utility classes)",
+        "Flags `UserDisplayHelper` as an unnecessary Java-style utility class wrapping top-level functions; recommends converting to top-level functions or extension functions (Ch 3: top-level functions replace static utility classes)",
+        "Identifies that `renderTruncated` has many same-typed parameters in a row which are ambiguous at call sites; recommends named arguments or introducing a value class or data class (Ch 3: use named/default arguments for clarity)",
+        "Notes that `truncate` could use a default parameter value for `suffix` instead of requiring callers to pass `\"...\"` every time (Ch 3: default parameter values)",
+        "Provides a refactored version using extension functions on String, string templates, and named/default args"
+      ]
+    },
+    {
+      "id": "eval-03-clean-kotlin-coroutines-sealed",
+      "prompt": "Review this Kotlin code:\n\n```kotlin\nsealed interface PaymentResult {\n    data class Success(val transactionId: String, val amount: Double) : PaymentResult\n    data class Declined(val reason: String, val code: Int) : PaymentResult\n    data class NetworkError(val cause: Throwable) : PaymentResult\n}\n\ninterface PaymentGateway {\n    suspend fun charge(amount: Double, token: String): PaymentResult\n}\n\nclass PaymentProcessor(\n    private val gateway: PaymentGateway,\n    private val scope: CoroutineScope\n) {\n    suspend fun processOrder(orderId: String, amount: Double, token: String): PaymentResult {\n        return withContext(Dispatchers.IO) {\n            try {\n                gateway.charge(amount, token)\n            } catch (e: CancellationException) {\n                throw e\n            } catch (e: Exception) {\n                PaymentResult.NetworkError(e)\n            }\n        }\n    }\n\n    fun processOrderAsync(orderId: String, amount: Double, token: String) =\n        scope.async { processOrder(orderId, amount, token) }\n}\n\nfun renderResult(result: PaymentResult): String = when (result) {\n    is PaymentResult.Success -> \"Charged \\$${result.amount} — txn ${result.transactionId}\"\n    is PaymentResult.Declined -> \"Declined (${result.code}): ${result.reason}\"\n    is PaymentResult.NetworkError -> \"Network error: ${result.cause.message}\"\n}\n```",
+      "expectations": [
+        "Recognizes this is already idiomatic, well-structured Kotlin and says so explicitly",
+        "Praises the sealed interface hierarchy for `PaymentResult` providing exhaustive when expressions without a catch-all branch (Ch 4: sealed classes for restricted hierarchies)",
+        "Praises re-throwing `CancellationException` to maintain cooperative coroutine cancellation (Ch 14: structured concurrency, cancellation handling)",
+        "Praises using `withContext(Dispatchers.IO)` for the blocking gateway call rather than blocking on a non-IO dispatcher (Ch 14: dispatcher usage)",
+        "Praises use of `data class` subtypes giving automatic `equals`, `hashCode`, `copy`, and `toString` (Ch 4: data classes for value types)",
+        "Praises the exhaustive `when` expression in `renderResult` that the compiler enforces due to the sealed hierarchy (Ch 4)",
+        "Does NOT manufacture issues to appear thorough; any suggestions are explicitly framed as minor optional improvements",
+        "May note minor optional suggestions such as whether `processOrderAsync` is needed given `processOrder` is already suspend, but frames them as design questions, not violations"
+      ]
+    }
+  ]
+}

package/skills/kotlin-in-action/evals/results.json

@@ -0,0 +1,13 @@
+{
+  "pass_rate": 0.952,
+  "passed": 20,
+  "total": 21,
+  "baseline_pass_rate": 0.571,
+  "baseline_passed": 12,
+  "baseline_total": 21,
+  "delta": 0.381,
+  "model": "default",
+  "evals_run": 3,
+  "date": "2026-03-28",
+  "non_standard_provider": true
+}

package/skills/kotlin-in-action/examples/after.md

@@ -0,0 +1,53 @@
+# After
+
+Idiomatic Kotlin using a sealed interface for channels, safe-call operators, named parameters, and extension functions — eliminating all manual null checks and string comparisons.
+
+```kotlin
+// Sealed interface models exactly the valid channels — exhaustive when is enforced
+sealed interface NotificationChannel {
+    data class Email(val address: String) : NotificationChannel
+    data class Sms(val phoneNumber: String) : NotificationChannel
+}
+
+// Extension function resolves the preferred channel from a User
+fun User.preferredChannel(): NotificationChannel? = when {
+    email != null       -> NotificationChannel.Email(email)
+    phoneNumber != null -> NotificationChannel.Sms(phoneNumber)
+    else                -> null
+}
+
+class NotificationService(
+    private val emailSender: EmailSender,
+    private val smsSender: SmsSender,
+) {
+
+    fun sendNotification(user: User, message: String, channel: NotificationChannel) {
+        require(message.isNotBlank()) { "Notification message must not be blank" }
+
+        when (channel) {
+            is NotificationChannel.Email -> {
+                val subject = "Notification for ${user.firstName} ${user.lastName}"
+                emailSender.send(to = channel.address, subject = subject, body = message)
+            }
+            is NotificationChannel.Sms -> {
+                smsSender.send(to = channel.phoneNumber, body = message)
+            }
+        }
+    }
+}
+
+// Usage — caller resolves channel; service focuses on delivery
+fun notifyUser(user: User, message: String, service: NotificationService) {
+    user.preferredChannel()
+        ?.let { channel -> service.sendNotification(user, message, channel) }
+        ?: logger.warn("No notification channel available for user ${user.id}")
+}
+```
+
+Key improvements:
+- `sealed interface NotificationChannel` replaces the `String` channel parameter — the compiler enforces exhaustive `when` and eliminates the "Unknown channel" else branch (Ch 4: Sealed classes)
+- `User?` parameter becomes non-null `User` — the caller is responsible for ensuring a valid user exists; null-safety is pushed to the boundary (Ch 7: Null safety)
+- `user.preferredChannel()` extension function encapsulates the channel-resolution logic outside the service class (Ch 3: Extension functions)
+- `require(message.isNotBlank())` replaces silent println for invalid input (Effective Kotlin Item 5: Specify your expectations on arguments)
+- Named parameters `to =`, `subject =`, `body =` make the send calls self-documenting (Ch 3: Named arguments)
+- String template `"${user.firstName} ${user.lastName}"` replaces concatenation (Ch 2: String templates)

package/skills/kotlin-in-action/examples/before.md

@@ -0,0 +1,39 @@
+# Before
+
+Kotlin code written with Java-style null checks, no extension functions, and no use of sealed classes or safe-call operators.
+
+```kotlin
+class NotificationService(
+    private val emailSender: EmailSender,
+    private val smsSender: SmsSender
+) {
+
+    fun sendNotification(user: User?, message: String?, channel: String) {
+        if (user == null) {
+            println("User is null")
+            return
+        }
+        if (message == null || message.isEmpty()) {
+            println("Message is empty")
+            return
+        }
+
+        if (channel == "EMAIL") {
+            if (user.email != null) {
+                val subject = "Notification for " + user.firstName + " " + user.lastName
+                emailSender.send(user.email, subject, message)
+            } else {
+                println("No email for user " + user.id)
+            }
+        } else if (channel == "SMS") {
+            if (user.phoneNumber != null) {
+                smsSender.send(user.phoneNumber, message)
+            } else {
+                println("No phone for user " + user.id)
+            }
+        } else {
+            println("Unknown channel: " + channel)
+        }
+    }
+}
+```

package/skills/kotlin-in-action/references/api_reference.md

@@ -0,0 +1 @@
+