---
name: code-like-simon
description: >
  Use when writing new Kotlin or Java files, editing existing Kotlin code,
  writing or modifying Compose UI code, writing or modifying unit tests in Kotlin,
  any task that produces .kt file changes, or updating .kts files such as build.gradle.kts.
---

# Code Like Simon

**Skill type: code-generating** — produces Kotlin, Compose, test, and Gradle code following
patterns learned from effective Claude users.

Coding patterns and conventions collected from colleagues and friends who use Claude
effectively for Android/Kotlin development. This is a living document — patterns are
added as they are learned and validated.

## Scope

**This skill covers:**
- Kotlin coding style (function bodies, null handling, collections, named params, etc.)
- Compose UI patterns (state hoisting, Modifier conventions, slot APIs)
- Unit test patterns (fakes, naming, assertions)
- Gradle build file conventions (version catalogs, dependency declarations)

**This skill does NOT cover:**
- Circuit UI scaffolding — use `/create-circuit-feature`
- Accessibility patterns — use `/android-a11y`
- Slackforce team-specific conventions — `team-code-slackforce` takes precedence when both apply

**Priority:** When `team-code-slackforce` triggers on the same files, its conventions
override this skill. This skill provides general patterns; team skills provide team-specific rules.

## Trigger Paths

This skill applies to files matching:

```
.*\.kt$
.*\.java$
.*\.kts$
```

## Safety Constraints

**NEVER perform git operations.** This skill and any subagents it dispatches MUST NOT:
- Run `git commit`, `git add`, `git push`, or any git commands
- Instruct subagents to commit or push
- Include commit steps in any workflow

All git operations are the responsibility of the orchestrating agent or the user.

### Red Flags — STOP

- About to run `git commit`? **STOP.** Not your job.
- About to run `git add`? **STOP.** Not your job.
- About to run `git push`? **STOP.** Not your job.
- "Just a quick commit" — **NO.** Never.
- "Let me save this progress" — **NO.** The orchestrator handles git.

## Subagent Dispatch Model

When this skill is invoked, the orchestrating Opus agent dispatches a **sonnet** subagent
to perform the actual coding work.

### When to Dispatch a Subagent

Dispatch a sonnet subagent when:
- Writing new `.kt` files
- Editing existing Kotlin code
- Writing or modifying Compose UI code
- Writing or modifying unit tests in Kotlin
- Any task that produces `.kt` file changes
- Updating `.kts` files (build.gradle.kts)

### Dispatch Template

```
Agent tool:
  model: sonnet
  description: "[Brief task description]"
  prompt: |
    You are a Kotlin/Android code implementer following the "code-like-simon" conventions.

    ## CRITICAL SAFETY CONSTRAINT
    You MUST NOT perform any git operations. No git commit, git add, git push, or any
    git commands whatsoever. All git operations are handled by the orchestrating agent.

    ## Conventions to Follow
    [Paste relevant patterns from references/ based on the task type — see Pattern Selection below]

    ## Task
    [Full task description — paste it here, don't make the subagent read files]

    ## Context
    [Relevant file contents and codebase context]

    ## Before You Begin
    If you have questions about requirements, approach, or dependencies — ask them now.

    ## Your Job
    1. Implement exactly what the task specifies
    2. Follow the conventions provided above
    3. Add KDoc to every NEW public class, method, object, sealed interface/class you create
    4. Verify compilation succeeds
    5. Report back (do NOT commit)

    ## KDoc on Existing Code
    If you encounter an EXISTING public class, method, object, or sealed type that is
    missing KDoc, do NOT add it automatically. Instead, list it in your report under
    "Missing KDoc" so the user can decide whether to address it now or in follow-up work.

    ## Report Format
    - **Status:** DONE | DONE_WITH_CONCERNS | NEEDS_CONTEXT | BLOCKED
    - Files changed
    - Patterns applied
    - **Missing KDoc:** List any existing public types/methods found without KDoc (file:line)
    - Any concerns
```

### Pattern Selection

Based on the task, load and paste the appropriate reference content into the subagent prompt:

| Task Type | Reference to Load |
|-----------|-------------------|
| New Kotlin class or editing `.kt` files | [kotlin-coding-style.md](./references/kotlin-coding-style.md) |
| Compose UI work | [compose-patterns.md](./references/compose-patterns.md) |
| Unit tests | [test-patterns.md](./references/test-patterns.md) |
| `build.gradle.kts` changes | [gradle-patterns.md](./references/gradle-patterns.md) |
| Multiple areas | Load all relevant references |

## Core Principles

### Rules (always enforced)

1. **No git operations** — never commit, add, push, or perform any git actions
2. **Use kotlin-lsp for code navigation** — prefer kotlin-lsp over Grep for finding symbols, references, definitions, and usages in Kotlin files. Use Grep only as a fallback for plain-text or non-Kotlin searches.
3. **Follow existing codebase patterns** — read neighboring files before writing new code
4. **Compile before claiming done** — always verify compilation succeeds
4. **Named parameters in Kotlin** — always use named parameters for readability
5. **Trailing commas** — always use trailing commas in multi-line declarations
6. **Imports over fully qualified paths** — never use fully qualified class names inline; use import aliases for conflicts
7. **Fakes over mocks** — never use mocking libraries in tests
8. **KDoc on all new public APIs** — every new public class, method, object, sealed interface/class must have KDoc describing what it is used for. See [KDoc conventions](./references/kotlin-coding-style.md#kdoc)

### Guidelines (apply judgment)

9. **Clarity over cleverness** — readable, explicit code over clever one-liners
10. **Minimal diffs** — change only what is necessary for the task
11. **Self-documenting code** — code should read clearly without excessive comments
12. **Immutability by default** — `val`, sealed types, data classes, `Collection<T>` in APIs
13. **Design out nullability** — null only for genuinely optional information