Clerk Android
ClerkOfficialCreated by clerk
- Skill
- Tool integration
- Software development
- MIT
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a structured approach to implementing Clerk authentication in native Android projects. It supports two primary integration paths: a prebuilt UI flow using AuthView and UserButton for rapid deployment, and a custom API-driven flow for developers requiring full control over the authentication sequence. The skill ensures compliance with official Android quickstart requirements, proper SDK initialization, and capability-driven logic that respects dashboard configurations.
What it does
- Guides the setup of Clerk authentication in native Android apps.
- Supports prebuilt UI components for fast integration.
- Enables custom API-driven authentication flows for specialized requirements.
- Ensures correct SDK initialization and state management.
- Validates project prerequisites like manifest permissions and SDK versions.
- Promotes capability-driven development based on Clerk runtime settings.
When to use it
- When adding authentication to a native Android application using Kotlin.
- When using Jetpack Compose for UI development.
- When you need to choose between prebuilt auth screens or a custom-built auth experience.
- When you need to ensure your Android project meets Clerk's specific integration requirements.
Advantages
- Provides clear separation between prebuilt and custom implementation paths.
- Enforces mandatory setup checks to prevent common integration errors.
- Promotes clean architecture by separating UI, state, and API logic.
- Ensures authentication behavior remains consistent with dashboard settings.
Usage examples
- “How do I add Clerk to my new Android app using the prebuilt UI?”
- The agent will verify your project type, ask for your Clerk publishable key, and guide you through installing the clerk-android-ui artifact and implementing AuthView.
- “I need to build a custom sign-in flow for my Android app using Clerk.”
- The agent will confirm your requirements, ask for your publishable key, and provide a checklist for using the clerk-android-api artifact to build a multi-step auth flow.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/clerk/clerk-android/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip clerk-android.zip -d .agents/skills
Documentation by clerk
Clerk Android (Native)
This skill implements Clerk in native Android projects by following current clerk-android SDK and docs patterns.
Activation Rules
Activate this skill when either condition is true:
The user explicitly asks for Android, Kotlin, Jetpack Compose, or native mobile Clerk implementation on Android.
The project appears to be native Android (for example
build.gradle(.kts)with Android plugins,AndroidManifest.xml,app/src/main/java, Compose UI files).
Do not activate this skill when either condition is true:
The project is Expo.
The project is React Native.
If Expo/React Native signals are present, route to the general setup skill instead.
What Do You Need?
| Task | Reference |
|---|---|
| Prebuilt AuthView / UserButton (fastest) | references/prebuilt.md |
| Custom API-driven auth flows (full control) | references/custom.md |
Quick Start
| Step | Action |
|---|---|
| 1 | Confirm project type is native Android and not Expo/React Native |
| 2 | Determine flow type (prebuilt or custom) and load the matching reference file |
| 3 | Ensure a real Clerk publishable key exists (or ask developer) |
| 4 | Ensure correct Clerk artifacts are installed for the selected flow |
| 5 | Read official Android quickstart and verify required setup (Native API, min SDK/Java, manifest, initialization) |
| 6 | Inspect clerk-android source/sample patterns relevant to selected flow |
| 7 | Implement flow by following only the selected reference checklist |
Decision Tree
User asks for Clerk in Android/Kotlin
|
+-- Expo/React Native project detected?
| |
| +-- YES -> Do not use this skill
| |
| +-- NO -> Continue
|
+-- Existing auth UI detected?
| |
| +-- Prebuilt views detected -> Load references/prebuilt.md
| |
| +-- Custom flow detected -> Load references/custom.md
| |
| +-- New implementation -> Ask developer prebuilt/custom, then load matching reference
|
+-- Ensure publishable key and SDK initialization path
|
+-- Ensure correct Android artifacts are installed
|
+-- Verify quickstart prerequisites in project
|
+-- Implement using selected flow referenceFlow References
After flow type is known, load exactly one:
Prebuilt flow: references/prebuilt.md
Custom flow: references/custom.md
Do not blend the two references in a single implementation unless the developer explicitly asks for a hybrid approach.
Interaction Contract
Before any implementation edits, the agent must have both:
flow choice:
prebuiltorcustoma real Clerk publishable key
If either value is missing from the user request/context:
ask the user for the missing value(s)
pause and wait for the answer
do not edit files or install dependencies yet
Only skip asking when the user has already explicitly provided the value in this conversation.
Source-Driven Templates
Do not hardcode implementation examples in this skill. Inspect current clerk-android source/docs for the installed SDK version before implementing.
| Use Case | Source of Truth |
|---|---|
SDK artifacts and dependency split (clerk-android-api vs clerk-android-ui) | clerk-android README and Android install docs |
| SDK initialization and publishable key wiring | Android quickstart and source/api/.../Clerk.kt |
| Prebuilt auth and profile behavior | source/ui/.../AuthView.kt, source/ui/.../UserButton.kt, and prebuilt sample |
| Custom auth sequencing and factor handling | source/ui/auth/*, source/api/auth/*, and custom-flows sample |
| Capability/feature gating from instance settings | Clerk public fields (for example enabledFirstFactorAttributes, socialProviders, isGoogleOneTapEnabled, mfaIsEnabled) and environment model source |
| Required Android setup checklist | Official Android quickstart (/docs/android/getting-started/quickstart) |
Execution Gates (Do Not Skip)
No implementation edits before prerequisites
Do not edit project files until flow type is confirmed and a valid publishable key is available.
Missing flow or key must trigger a question
If flow choice is missing, explicitly ask: prebuilt views or custom flow.
If publishable key is missing/placeholder/invalid, explicitly ask for a real key.
Do not continue until both answers are provided.
Publishable key wiring mode is mandatory
By default, wire the developer-provided key directly in
Clerk.initialize(...).Do not introduce secret-management indirection unless explicitly requested.
Artifact install policy is mandatory
Prebuilt flow: use
clerk-android-ui(includes API).Custom flow: use
clerk-android-apiunless prebuilt components are explicitly requested.If Clerk artifacts are missing, add the latest stable release available.
Android quickstart compliance is mandatory
Verify Native API is enabled for the Clerk app.
Verify Android requirements from quickstart are implemented in project (minimum SDK and Java target, manifest internet permission, app-level Clerk initialization).
Verify app waits for SDK initialization (
Clerk.isInitialized) before assuming auth-ready state.
Capability-driven behavior is mandatory
Use Clerk runtime capability/settings state (for example enabled factors/social providers/MFA flags) to gate flow behavior.
Do not hardcode factor assumptions that may conflict with dashboard configuration.
Reference-file discipline is mandatory
Once flow is selected, follow only that flow reference file for implementation and verification.
Custom-flow structure parity is mandatory
For
customflow, preserve multi-step auth progression and factor-specific handling (no single all-fields form by default).Keep UI, state orchestration, and Clerk API integration in separate modules.
Prebuilt preference is mandatory when selected
For
prebuiltflow, do not rebuild auth forms with custom API calls unless explicitly requested.Use
AuthView/UserButtonas default building blocks.
Workflow
Detect native Android vs Expo/React Native.
If flow type is not explicitly provided, ask user for
prebuiltorcustom.If publishable key is not explicitly provided, ask user for it.
Wait for both answers before changing files.
Load matching flow reference file.
Ensure
Clerk.initialize(...)path and publishable key wiring are valid.Ensure dependencies/artifacts match selected flow.
Review Android quickstart requirements and apply missing setup in project.
Implement using selected reference checklist.
Verify using selected reference checklist plus shared gates.
Common Pitfalls
| Level | Issue | Prevention |
|---|---|---|
| CRITICAL | Not asking for missing flow choice before implementation | Ask for prebuilt vs custom and wait before edits |
| CRITICAL | Not asking for missing publishable key before implementation | Ask for key and wait before edits |
| CRITICAL | Starting implementation before flow type is confirmed | Confirm flow first and load matching reference |
| CRITICAL | Skipping Android quickstart prerequisites | Verify and apply required setup from official Android quickstart |
| CRITICAL | Missing app-level Clerk.initialize(...) call | Initialize Clerk from Application startup path |
| HIGH | Wrong artifact for chosen flow | Prebuilt: clerk-android-ui; custom: clerk-android-api |
| HIGH | Rendering auth UI before SDK initialization completes | Gate UI with Clerk.isInitialized state |
| HIGH | Hardcoding auth factors/social providers | Drive behavior from Clerk runtime capability fields |
| HIGH | Using this skill for Expo/React Native | Detect and route away before implementation |
See Also
clerkskill for top-level Clerk routingclerk-setupskill for cross-framework quickstart setuphttps://github.com/clerk/clerk-androidhttps://clerk.com/docs/android/getting-started/quickstart
Files
- ATTRIBUTION.mdAdded by AutoGineer833 B
- SKILL.md8.4 KiB
- references/custom.md3.8 KiB
- references/prebuilt.md2.7 KiB
references/custom.md
Custom Flow Reference (Clerk Android API)
Use this file only when flow type is custom.
Purpose
Implement native Android auth with Clerk API primitives while preserving Clerk's multi-step auth semantics and dashboard-driven capability gating.
Source-Driven Requirements
Use current clerk-android source/docs as primary references:
source/apifor sign-in/sign-up/session/auth APIs.source/ui/authandsamples/custom-flowsfor flow sequencing patterns.Android quickstart for required project setup.
Source priority rules for custom flow:
Primary source: Clerk Android API and auth flow source.
Secondary source:
samples/custom-flows.Fallback only: high-level docs when behavior is unclear from SDK/source.
Required Patterns
Artifact selection
Ensure
com.clerk:clerk-android-apiis installed.Do not add
clerk-android-uiunless developer explicitly asks for a hybrid prebuilt/custom approach.
Quickstart prerequisite audit
Read the official Android quickstart:
https://clerk.com/docs/android/getting-started/quickstart.Verify required project setup (Native API, min SDK/Java, manifest internet permission, app-level initialization).
Implement missing required setup before finishing custom auth work.
Initialization and state contract
Initialize via
Clerk.initialize(...)at app startup.Wait for
Clerk.isInitializedbefore treating Clerk as ready.Drive session/user UI from
Clerk.userFlow/Clerk.sessionFlow.
Capability-driven flow logic
Use Clerk runtime capability/settings fields to drive flow branches (first factors, social providers, MFA, Google One Tap support).
Do not hardcode fixed factor/provider assumptions.
Multi-step flow progression
Keep sign-in/sign-up progression split into explicit steps/states.
Avoid collapsing all required auth input into one monolithic screen.
Keep branching aligned with factor requirements and verification states returned by Clerk.
API usage patterns
Use Clerk sign-in/sign-up APIs and verification methods with structured success/failure handling.
Keep request/response handling explicit and status-driven.
Use Clerk error helpers/messages for user-visible errors.
OAuth/social policy
Use provider flows supported by Clerk APIs.
For Google, honor runtime One Tap capability and use the appropriate Clerk path.
Do not bypass Clerk by implementing provider-specific token exchange directly unless explicitly requested.
Code organization and separation of concerns
Split custom auth into focused modules:
UI step views/components
Flow/state orchestration (view models/state machines)
Clerk API integration layer
Keep module boundaries clear and composable.
Avoid hidden dependencies
Do not silently add prebuilt UI dependencies to custom-only implementations.
Do not introduce local config indirection for publishable key unless requested.
Verification Checklist
Quickstart prerequisites are complete
Required Android/Clerk setup from quickstart is present.
Missing required setup was applied.
Correct artifact usage
clerk-android-apiis present.clerk-android-uiis absent unless explicitly required.
Initialization and auth state handling
UI/runtime waits for
Clerk.isInitialized.Auth/session/user state derives from Clerk flows.
Capability-driven behavior
Flow branches align with runtime capabilities and dashboard configuration.
No hardcoded factor/provider matrix independent of Clerk state.
Multi-step auth quality
Flow uses explicit steps with clear transitions.
Required fields and verifications are fully covered.
Architecture quality
UI, orchestration, and Clerk integration are separated into focused files/modules.
OAuth/social correctness
OAuth handling uses Clerk APIs and supported provider paths.
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Declares allowed tools
The author says: Requires Android Studio and clerk-android Gradle dependency
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- clerk
- Publisher
- Clerk (Official)
- Source
- clerk/skills · skills/clerk-android · commit c5d2c0d
- Licence
- MIT License (redistribution allowed)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by clerk.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download clerk-android.zip