Claude Skills for Kotlin: Review and Test Templates

Claude skills for Kotlin are saved prompt instructions that apply consistent review criteria to null safety, coroutine behavior, and test coverage. Call them by name in a Claude Project instead of retyping the Kotlin-specific checklist each session.

Tools like fenbs store the project conventions and lessons from past bugs. A connected assistant reading those at the start of a session applies your team's actual standards rather than generic Kotlin guidance.

Why Kotlin needs its own review criteria

Kotlin's null safety type system prevents most NullPointerExceptions, but developers can bypass it. The !! operator asserts that a value is non-null and throws an exception at runtime if it is not. A codebase that uses !! throughout its critical paths has opted back into exactly the crash behavior the type system was designed to prevent.

Coroutine bugs are a second category that general code review prompts miss. A coroutine launched in the wrong scope can leak when the associated lifecycle ends. A blocking call on the Main dispatcher freezes the UI. A long-running loop that does not check isActive cannot be canceled gracefully. These problems are structural and show up in the shape of the code before they appear as runtime failures.

The skills below cover three distinct areas: null safety, coroutine behavior, and test review. Each targets the Kotlin-specific failure modes. For Android projects, the coroutine skill includes lifecycle scope checks. For backend Kotlin, the dispatcher and scope checks apply differently. Adjust the checklist items to match your environment before saving.

A skill for null safety review

This skill focuses on the operators that bypass Kotlin's null safety guarantees. A single !! in a critical path can reintroduce crashes. The skill also checks for platform type handling from Java interop, where the type system has incomplete information.

Review the following Kotlin code for null safety issues.

Code:
{{paste the relevant functions or classes}}

Check each item and mark Pass, Fail, or Not applicable:

Unsafe null operators:
- [ ] No !! operator in production code without a documented reason
- [ ] No unchecked smart cast where the cast can fail at runtime
- [ ] No lateinit var used for values that might never be initialized

Nullable handling:
- [ ] Nullable types use safe call (?.) or Elvis operator (?:) appropriately
- [ ] let, run, or also blocks used for null-safe transformations
- [ ] Function return types are nullable only when null is a meaningful result
- [ ] Platform types from Java interop are handled with explicit null checks

Boundary safety:
- [ ] Public API parameters that arrive from Java code are checked
- [ ] Collections from Java APIs are treated as potentially containing nulls

For each Fail: Location (quote the code) | Problem (one sentence) | Suggested fix (one sentence).
End with: Null safety risk: Low | Medium | High with one-line reason.

The lateinit var check is worth explaining. lateinit var is used for properties that cannot be initialized in the constructor but will be set before any use. If the property is accessed before it is set, Kotlin throws UninitializedPropertyAccessException. This is a crash. The skill flags lateinit var on values that might remain unset, which is a common pattern in test setup code that does not always run.

For Java interop, the platform type check is critical. When Kotlin calls a Java method, the return type becomes a platform type (written as Type!). The type system cannot guarantee whether it is nullable. Explicitly checking the result or annotating the Java code with @Nullable or @NonNull removes the ambiguity.

A skill for coroutine behavior review

Coroutine bugs are harder to reproduce than synchronous bugs because they often depend on timing, lifecycle state, or cancellation sequences. This skill checks the structural problems that cause coroutine issues before they become runtime failures.

Review the following Kotlin coroutine code.

Code:
{{paste the coroutine-related functions or classes}}

Check each item and mark Pass, Fail, or Not applicable:

Scope and lifecycle:
- [ ] Coroutines are launched in a scope tied to the correct lifecycle
- [ ] No GlobalScope.launch in production code without a documented reason
- [ ] viewModelScope or lifecycleScope used in UI-layer code
- [ ] Scopes are canceled when the associated lifecycle ends

Dispatchers:
- [ ] CPU-intensive work uses Dispatchers.Default or IO, not Main
- [ ] UI updates happen on Dispatchers.Main
- [ ] No blocking calls inside a coroutine on the Main dispatcher

Cancellation:
- [ ] Cancellation exceptions are not caught and swallowed
- [ ] Long loops check isActive to support cooperative cancellation
- [ ] withContext is used for dispatcher switches, not launch

Error handling:
- [ ] CoroutineExceptionHandler is set where exceptions must not be lost
- [ ] Async/await error paths are handled (deferred.await in try/catch)

For each Fail: Location | Problem (one sentence) | Suggested fix (one sentence).
End with: Coroutine safety: Low risk | Medium risk | High risk with one-line reason.

The GlobalScope.launch check is important for Android projects in particular. A coroutine launched in GlobalScope continues running after its associated screen or component is destroyed. This is a memory leak and can cause crashes when the coroutine updates UI state that no longer exists. Using viewModelScope or lifecycleScope ties the coroutine's lifetime to the component that launched it.

Catching and swallowing CancellationException is a structural problem. If a coroutine catches all exceptions including CancellationException, it cannot be canceled. This prevents graceful shutdown and can keep coroutines running after their scope is canceled. The fix is to either rethrow CancellationException or use catch (e: Exception) only for non-cancellation exceptions.

A skill for Kotlin test review

A test review skill checks existing or planned tests for the cases most often missed in Kotlin projects: coroutine test setup, null input coverage, and error path verification. Getting these right during planning is faster than finding them after writing the tests.

Review or plan tests for the following Kotlin code.

Code or change description: {{paste the code or describe the change}}
Test framework: {{JUnit 5 | Kotest | other}}
Using coroutines: Yes | No

Check or plan:

Unit test coverage:
- [ ] Happy path covered
- [ ] Null inputs for all nullable parameters
- [ ] Error paths and exceptions
- [ ] Boundary values (empty collections, zero, max values)

Coroutine tests (if applicable):
- [ ] Tests use runTest (kotlinx-coroutines-test) not runBlocking
- [ ] Fake dispatchers used to control timing
- [ ] Cancellation behavior tested

Missing cases:
  - [list any cases not covered]

Recommended additions:
  - Test: [description] | Why: [one sentence]

The runTest vs runBlocking distinction matters. runTest from kotlinx-coroutines-test uses a virtual time controller that lets you advance time instantly in tests involving delay. Using runBlocking instead makes those tests slow and timing-dependent. For coroutine-heavy code, runTest is the right tool and this skill flags any test that uses runBlocking where runTest would be more appropriate.

How to build lessons into better reviews

After a null safety or coroutine bug reaches production, record what the review missed and why. If a !! operator on a platform type from a Java library caused a crash in a specific code path, add the lesson: "The null safety skill must explicitly check !! usage on return values from Java interop in the payment module." The next review of similar code catches it.

Lessons accumulate into a body of project-specific knowledge that generic checklists cannot replicate. A team that records lessons consistently ends up with a review skill that knows about the actual failure modes of its codebase, not just the ones that appear in the official Kotlin documentation.

How to do this with fenbs

1. Create a free account and add a project for the Kotlin codebase or team.
2. Add each skill to Skills and prompts: "Null safety review", "Coroutine review", "Test review".
3. Add the project conventions as Decisions and rules: !! policy, coroutine scope rules, dispatcher conventions.
4. Connect Claude over MCP from Integrations. Ask Claude to read the conventions before running a review skill.
5. After each bug, add a lesson: what the review missed and what to check next time.

For general skill patterns, see Claude skills examples and how to create a Claude skill. For how skills fit alongside Claude's other features, see Claude Projects vs Skills vs Artifacts.