AgentStack
SKILL verified Apache-2.0 Self-run

Build Kotlin Android

skill-gaelic-ghost-socket-build-kotlin-android · by gaelic-ghost

Implement Kotlin-first Android app or library changes, including activities, fragments, services, receivers, Compose UI, XML/AppCompat UI, AndroidX, lifecycle-aware coroutines, state, persistence touchpoints, resources, accessibility labels, navigation touchpoints, tests, lint, and validation while preserving repo conventions.

No reviews yet
0 installs
16 views
0.0% view→install

Install

$ agentstack add skill-gaelic-ghost-socket-build-kotlin-android

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Build Kotlin Android? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Build Kotlin Android

Purpose

Implement Kotlin-first Android changes while preserving the repository's architecture, UI system, resources, and validation path.

The skill should be deep enough for common Compose and XML UI work without pretending to replace future specialized UI skills.

Source Check

Use repo-local Android files, checked-out dependency sources, and Dash.app docsets opportunistically when they cover exact Gradle, Java, or local command questions. Use official documentation as authority for Android APIs, Compose, AndroidX, lifecycle, resources, accessibility, and version-sensitive behavior:

Translate documentation into repository-specific code, resource, lifecycle, or validation decisions.

Implementation Workflow

  1. Inspect existing conventions:
  • package structure and module boundaries
  • activities, fragments, services, receivers, workers, or navigation owners
  • Compose versus XML/AppCompat ownership
  • ViewModel, state holder, repository, dependency injection, persistence, and background-work patterns
  • resource naming, theming, strings, dimensions, and accessibility conventions
  • existing tests and lint baselines
  1. Preserve architecture:
  • keep UI, state, domain, persistence, and platform boundaries consistent
  • add shared helpers only when they remove real duplication or match an existing local pattern
  • avoid new architecture layers unless the current shape cannot support the requested work
  1. Implement common Compose tasks:
  • compose screens from small functions with explicit state and callbacks
  • preserve state hoisting and unidirectional data flow
  • update previews when the repo already uses them
  • use modifiers, lists, forms, theming, and semantics consistently
  • keep navigation touchpoints aligned with existing navigation owners
  1. Implement common XML/AppCompat tasks:
  • update layouts, resources, themes, strings, and accessibility labels together
  • use view binding or data binding only when the repo already does
  • keep RecyclerView, adapter, fragment, and activity wiring aligned with existing code
  • avoid mixing Compose into XML screens unless the repo already has an interop pattern or the user approves it
  1. Implement platform work:
  • keep lifecycle-aware coroutines scoped correctly
  • keep permissions, manifests, and background work explicit
  • preserve nullability and Java interop annotations for public APIs
  1. Validate narrowly:
  • compile or assemble the affected module
  • run targeted unit tests
  • run lint for affected variants when UI/resources/platform APIs changed
  • hand off emulator/device checks to the Android testing plugin when needed

Command Selection

Choose commands from the repo's Gradle tasks:

./gradlew :app:assembleDebug
./gradlew :app:testDebugUnitTest
./gradlew :app:lintDebug

Use narrower module or variant tasks when the project defines them.

Output Shape

Return:

  1. Implementation surface: module, source set, packages, UI files, resources, manifest, or tests.
  2. UI path: Compose, XML/AppCompat, interop, or no UI.
  3. State and lifecycle: state owner, coroutine scope, lifecycle owner, persistence or background-work impact.
  4. Validation path: commands run or skipped with concrete reasons.
  5. Handoffs: Java interop, Gradle/AGP, testing/lint, release readiness, or emulator/device validation.

Guardrails

  • Do not migrate Java to Kotlin without user intent.
  • Do not mix Compose and XML patterns casually.
  • Do not introduce a new dependency injection, navigation, persistence, or architecture framework without an explicit decision.
  • Do not hardcode user-facing text that belongs in resources unless the repo already does so.
  • Do not ignore accessibility labels, content descriptions, focus behavior, or dynamic text when changing UI.
  • Do not start emulator or device automation from this skill.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.