Scaffold a complete, build-ready Android project in seconds. Architecture, tests, and all dependencies wired up. Use it as a Claude skill or as a standalone Python CLI (no AI required).
demo.mov
android-starter-skill-demo-2.mp4
Android Starter is a project scaffolding tool that generates a complete, build-ready Android project. It works two ways:
- As a Claude skill: describe what you want in plain English and Claude derives screen names, entity models, fields, and dummy data automatically
- As a standalone Python script: run it directly from the command line with explicit arguments, no AI involved
Either way, you get the same output: a fully-wired, architecturally sound project, ready to open in Android Studio immediately.
With Claude:
"Build a recipe tracking app called RecipeBox"
Without Claude:
python generate_project.py --name RecipeBox --package com.example.recipebox \
--output ./RecipeBox --screen1 RecipeList --screen2 RecipeDetail \
--entity Recipe --fields "id:String,title:String,cuisine:String,prepTime:Int"Same 27 Kotlin files. Same architecture. Same result.
Every Android project starts the same way: set up Gradle, configure the version catalog, wire up Hilt, create a Room database, scaffold a Retrofit client, add Navigation, set up a ViewModel pattern… and 90 minutes later you haven't written a single line of product code.
This tool eliminates that entirely. The scaffolded project reflects real-world production patterns used by teams at scale:
- ✅ MVVM with unidirectional data flow
- ✅ Offline-first architecture (Room → UI, Retrofit → Room)
- ✅ Proper separation of concerns (Route vs Screen vs ViewModel)
- ✅
StateFlowfor state +SharedFlowfor one-shot effects - ✅ 22 unit tests with Turbine, MockK, and Truth out of the box
- ✅ KSP-based annotation processing (Hilt + Room)
- ✅ Full dependency injection via Hilt
- ✅ Everything in the version catalog (
libs.versions.toml)
A complete two-screen Android app demonstrating the full architecture stack. Screen names, entity models, and dummy data are all customized to match your domain:
RecipeBox/ (or any project name you choose)
├── app/src/main/java/<package>/
│ ├── ui/
│ │ ├── theme/ → Color, Theme, Type
│ │ ├── recipe_list/ → RecipeListRoute, RecipeListScreen, RecipeListViewModel, RecipeListUiModel
│ │ └── recipe_detail/ → RecipeDetailRoute, RecipeDetailScreen, RecipeDetailViewModel, RecipeDetailUiModel
│ ├── data/
│ │ ├── local/ → Room DB, DAO, RecipeEntity
│ │ ├── remote/ → Retrofit ApiService, RecipeDto
│ │ ├── repository/ → Repo interface, RepoImpl, Recipe domain model + mappers
│ │ └── StaticItemsData → Domain-relevant dummy data (e.g., 15 recipes)
│ ├── di/ → AppModule (network + db), RepoModule (bindings)
│ ├── App.kt → @HiltAndroidApp
│ └── MainActivity.kt → @AndroidEntryPoint + NavHost (RecipeList → RecipeDetail)
├── app/src/test/java/<package>/
│ ├── ui/recipe_list/ → RecipeListViewModelTest (8 tests)
│ ├── ui/recipe_detail/ → RecipeDetailViewModelTest (7 tests)
│ └── data/repository/ → RepoImplTest (7 tests)
├── gradle/libs.versions.toml
├── build.gradle.kts
└── settings.gradle.kts
27 Kotlin files (24 source + 3 test) generated with correct package names, imports, and wiring throughout. All class names, file names, and dummy data are derived from your domain automatically.
| Category | Libraries |
|---|---|
| UI | Jetpack Compose BOM, Material3, Activity Compose |
| Navigation | Navigation Compose |
| Lifecycle | Lifecycle Runtime KTX, collectAsStateWithLifecycle |
| DI | Hilt + KSP |
| Networking | Retrofit, OkHttp (logging interceptor), GSON converter |
| Database | Room (runtime, ktx, compiler via KSP) |
| Storage | DataStore Preferences |
| Images | Coil Compose |
| Logging | Timber |
| Async | Kotlin Coroutines (core + android) |
| Testing | JUnit, MockK, Truth, Turbine, Espresso, Compose UI Test |
-
Open Claude Desktop and go to Cowork mode.
-
Install the skill by dropping the
.skillfile into the Skills folder or via the Skills menu. -
Start a new session and ask in whatever way feels natural:
"Create a sample Android app" "Build a recipe tracking app called RecipeBox" "Set up a todo app with tasks, priorities, and due dates" "Bootstrap an Android app for a weather dashboard"
Claude will understand your domain, derive appropriate models and screen names, and generate your project immediately.
-
⬇️ Download android-starter.skill, or clone the repo:
git clone https://github.com/shuja1497/android-starter-skill.git
-
Install the skill by extracting it into your Claude Code skills directory:
mkdir -p ~/.claude/skills unzip android-starter.skill -d ~/.claude/skills/
-
Start Claude Code in your terminal and ask in whatever way feels natural. All of these work:
> Create a sample Android app> Build a recipe tracking app with cuisine types and prep times> Set up an Android project called FitnessTracker for workout logging> Bootstrap a contacts app with phone numbers and email addresses -
Claude generates the project with domain-specific screen names, entity models, fields, and dummy data. Open it in Android Studio. It builds immediately, no further setup needed.
Don't use Claude? No problem. The generator is a plain Python 3 script with zero dependencies. Just clone and run.
-
Clone the repo:
git clone https://github.com/shuja1497/android-starter-skill.git cd android-starter-skill -
Run with defaults (generates a generic Listing/Details app with soccer club data):
python scripts/generate_project.py \ --name MyApp \ --package com.example.myapp \ --output ./MyApp
-
Or customize everything:
python scripts/generate_project.py \ --name RecipeBox \ --package com.example.recipebox \ --output ./RecipeBox \ --screen1 RecipeList \ --screen2 RecipeDetail \ --entity Recipe \ --fields "id:String,title:String,cuisine:String,prepTime:Int,vegetarian:Boolean" \ --items '[{"id":"1","title":"Pad Thai","cuisine":"Thai","prepTime":30,"vegetarian":true},{"id":"2","title":"Butter Chicken","cuisine":"Indian","prepTime":45,"vegetarian":false}]'
-
Open the generated project in Android Studio. It builds immediately.
| Argument | Required | Default | Description |
|---|---|---|---|
--name |
Yes | - | Project display name (e.g., RecipeBox) |
--package |
Yes | - | Package name (e.g., com.example.recipebox) |
--output |
Yes | - | Output directory path |
--screen1 |
No | Listing |
First screen name (e.g., RecipeList) |
--screen2 |
No | Details |
Second screen name (e.g., RecipeDetail) |
--entity |
No | Item |
Entity/model name (e.g., Recipe) |
--fields |
No | id:String,name:String |
Comma-separated field:Type pairs |
--items |
No | 20 soccer clubs | JSON array of dummy data matching field schema |
Supported field types: String · Int · Long · Float · Double · Boolean
Tip: The first field should always be
id:String(used as the Room primary key). If you omit it, the script adds it automatically.
Claude intelligently derives everything from your natural language request:
| What You Say | What Gets Generated |
|---|---|
| "Create a recipe app" | RecipeList / RecipeDetail screens, Recipe entity with title, cuisine, prepTime fields, 15 realistic recipes as dummy data |
| "Build a todo app called TaskMaster" | TaskList / TaskDetail screens, Task entity with title, completed, priority fields, 15 tasks as dummy data |
| "Set up a weather app" | CityList / CityDetail screens, City entity with name, temperature, humidity fields, 15 cities as dummy data |
| "Create a sample Android app" | Default: Listing / Details screens, Item entity with name field, 20 soccer clubs as dummy data |
The generated project always builds on first open. If Claude can't derive your domain (or something goes wrong), it falls back to working defaults automatically.
String · Int · Long · Float · Double · Boolean
The first field is always id:String (primary key). Claude adds domain-appropriate fields based on your request.
The generated project uses domain-relevant dummy data so you can run it immediately without any backend.
To switch to a real API, open your list ViewModel (e.g., RecipeListViewModel.kt) and change:
// Before (dummy mode)
repository.refreshItems(dummy = true)
// After (real API)
repository.refreshItems(dummy = false)Then update ApiService.kt with your actual endpoint URL.
UI Layer ViewModel Repository Data Sources
─────────────────────────────────────────────────────────────────
ListingScreen ←→ ListingViewModel ←→ RepoImpl ──→ Room (local)
│ └──→ Retrofit (remote)
└── UiState (StateFlow)
└── UiEffect (SharedFlow, replay=0)
└── UiEvent (sealed interface)
State flows down, events flow up. The ViewModel is the single source of truth for UI state. One-shot side effects (toasts, navigation) travel through a separate SharedFlow channel to avoid re-delivery on recomposition.
Not every developer gets the same value from this tool. Here's an honest breakdown:
Gets the most out of it:
- Freelancers and indie devs starting a new client project or side app. Massive time saver, no negotiating on architecture opinions
- Junior and mid-level Android devs learning modern patterns. A working reference implementation you can study, run, and extend
- Hackathon participants. Skip setup entirely and start building the actual idea from minute one
- Bootcamps and Android courses. A well-structured project that teaches real patterns, not toy examples
- Developers who don't use AI tools. The standalone CLI gives you the same scaffolding without any AI dependency
Gets less out of it:
- Senior devs at established companies who already have internal templates and locked-in architecture
- Teams requiring Kotlin Multiplatform or multi-module setups out of the box
- Projects where a list → detail pattern doesn't map to the app's domain
A few things worth knowing before you dive in:
Two screens only. The scaffold demonstrates the full architecture pattern across a list screen and a detail screen, but real apps go beyond this. Use it as your foundation and add screens from there.
Six field types supported. Entity fields are limited to String, Int, Long, Float, Double, and Boolean. Complex types (lists, nested objects, enums) aren't supported yet. Add those manually after generation.
No Kotlin Multiplatform or multi-module support. If your project requires either of these, you'll need to restructure after generation.
-
Configurable screen names (custom domain, not just Listing/Details) -
Configurable entity names and fields -
Domain-aware dummy data generation -
Automatic fallback to defaults on any failure - Support for additional screen templates beyond list/detail
- Optional feature modules scaffolding
- Dark mode theming out of the box
- GitHub Actions CI workflow included in generated project
- Complex field types (lists, enums, nested objects)
Found a bug? Have a feature request? Want to improve the generated architecture?
👉 Open an issue. All feedback is welcome!
When reporting a bug, please include:
- What you asked Claude (or the CLI command you ran)
- What was generated vs what you expected
- Python version (for standalone CLI) or Claude version (for skill usage)
Contributions are welcome! If you'd like to improve the skill, the architecture patterns, or the generated project structure:
- Fork this repo
- Create a feature branch (
git checkout -b feat/my-improvement) - Commit your changes
- Open a Pull Request describing what and why
MIT License. See LICENSE for details. Use freely in personal and commercial projects.