@shaykec/app-agent 1.0.0

package/.claude/skills/android-customizer/SKILL.md

@@ -0,0 +1,278 @@
+---
+name: android-customizer
+description: Specialized Android/Kotlin skill for customizing Jetpack Compose app templates. Handles Gradle config updates, Compose screen rewriting, Hilt DI adjustments, navigation configuration, and Android-specific features.
+---
+
+# Android Customizer Skill
+
+Use this skill to perform deep Android/Kotlin/Compose customization on a cloned template.
+
+## When to Use
+
+- At Step 8 of the AppAgent workflow, when the platform is Android
+- After AppConfig, mock data, and design tokens are already in place
+- When you need to modify Compose screens, navigation, and themes
+
+## Execution Modes
+
+This skill supports two modes:
+
+### Full Mode (legacy — single agent customizes everything)
+
+Used when no customization-planner manifest exists. The agent customizes all screens sequentially using design and content briefs carried in context.
+
+### Batch Mode (parallel — subagent customizes a subset of screens)
+
+Used when the customization-planner has produced a `customization-manifest.md`. The main agent:
+1. Updates shared files first (AppConfig, MockDataProvider, Theme/Colors)
+2. Dispatches 2-3 parallel `Task` subagents, each running this skill in batch mode
+
+**When running in batch mode, you will receive:**
+- **Batch assignment** — a list of screen files you own (ONLY edit these files)
+- **Customization manifest** — the full manifest from the planner (design brief, content brief, per-screen change list)
+- **App directory** — path under `output/`
+
+**Batch mode rules:**
+- ONLY modify the screen files assigned to your batch
+- Do NOT modify AppConfig, MockDataProvider, Theme/Colors, or any shared file — those are already done
+- Do NOT modify screens outside your batch — another subagent owns them
+- DO update TESTING_MANIFEST.md entries and Maestro test files for YOUR screens only
+- Read the **Screen Change List** section of the manifest for your assigned screens — follow it precisely
+
+## Context You Need
+
+- **App name** — display name (e.g., "GigWallet")
+- **App directory** — path under `output/` (e.g., `output/gigwallet-android/`)
+- **Platform** — `android`
+- **App description** — what the app does
+- **What has been done** — renaming, AppConfig, mock data updates already completed
+- **Design brief** — from `customization-manifest.md` (preferred) or design-system skill — color palette (light + dark hex codes), Material icon mapping, visual tone, corner radius, typography intent
+- **Content brief** — from `customization-manifest.md` (preferred) or content-writer skill — onboarding text, tab labels, section headers, empty state messages, button labels, search placeholders, error messages
+- **Screen change list** (batch mode only) — from the manifest, specific changes for each assigned screen
+
+## Instructions
+
+### Step 1 — Gradle and Build Configuration
+
+Verify and fix:
+1. `settings.gradle.kts` — `rootProject.name` matches the app
+2. `build.gradle.kts` (app) — `namespace` and `applicationId` are correct
+3. `gradle/libs.versions.toml` — version catalog is consistent
+4. `AndroidManifest.xml` — `android:label`, package reference, permissions
+
+### Step 2 — Package Structure
+
+Ensure the Kotlin package structure is correct:
+- All `.kt` files have the correct `package` declaration
+- Directory structure under `src/main/java/` or `src/main/kotlin/` matches the package name
+- `@HiltAndroidApp` Application class has the correct name
+- All Hilt modules reference the correct package paths
+
+### Step 3 — Compose Screen Customization
+
+Apply the content brief and design tokens to all Composable screens:
+- Use `@Composable` functions with proper preview annotations
+- Apply Material 3 components and theming
+- Use `LazyColumn` / `LazyVerticalGrid` for lists
+- Apply content brief strings to all Text composables, labels, and placeholders
+- Use `stringResource()` for strings in `res/values/strings.xml` where applicable
+
+### Step 4 — Navigation
+
+Android templates use Compose Navigation with bottom tabs:
+
+```kotlin
+NavHost(navController = navController, startDestination = "home") {
+    composable("home") { HomeScreen() }
+    composable("search") { SearchScreen() }
+}
+```
+
+When modifying navigation:
+- Update route names to match the app domain
+- Update `BottomNavigation` items with labels from content brief
+- Apply Material Icons from the design brief
+- Ensure deep link routes are updated if applicable
+
+### Step 5 — Theme Customization
+
+Android templates use Material 3 dynamic theming in `Theme.kt`:
+- Apply primary, secondary, tertiary colors from the design brief
+- Update both `lightColorScheme()` and `darkColorScheme()`
+- Apply typography scale if the design brief specifies custom fonts
+- Apply shape theme (corner radius) from the design brief
+
+### Step 6 — Data Layer & Offline Infrastructure
+
+Templates now include an **offline-first data layer**. Understand these components:
+
+**Files you should NOT modify** (generic infrastructure):
+- `data/NetworkMonitor.kt` — connectivity detection
+- `data/LocalPersistence.kt` — JSON file persistence
+- `core/components/OfflineBanner.kt` — offline status banner
+
+**Files you MAY need to update** (domain-specific):
+- `mock/MockDataProvider.kt` — seed data already updated in Step 7. Verify:
+  - Seed data in `default*` vals matches the new domain
+  - `StateFlow` properties are reactive
+  - CRUD functions work with the correct entity types
+  - `reset()` function references correct defaults
+- `data/SyncManager.kt` — if entity types were renamed, update domain methods
+
+**ViewModel/Screen patterns** (how screens consume data):
+```kotlin
+// Screens collect StateFlow
+val products by MockDataProvider.products.collectAsState()
+
+// ViewModels read from MockDataProvider
+val products = MockDataProvider.products.value
+
+// CRUD via SyncManager
+SyncManager.addProduct(newProduct)
+SyncManager.deleteProduct(id)
+```
+
+**OfflineBanner integration** — add to main navigation:
+```kotlin
+Column {
+    OfflineBanner()
+    // ... rest of screen content
+}
+```
+
+**Application class** — verify NetworkMonitor and LocalPersistence are initialized:
+```kotlin
+class MyApplication : Application() {
+    override fun onCreate() {
+        super.onCreate()
+        NetworkMonitor.register(this)
+        LocalPersistence.initialize(this)
+    }
+}
+```
+
+### Step 7 — MockDataProvider Verification
+
+Verify MockDataProvider uses the correct patterns:
+
+```kotlin
+object MockDataProvider {
+    private val _products = MutableStateFlow(defaultProducts)
+    val products: StateFlow<List<Product>> = _products.asStateFlow()
+    
+    val defaultProducts = listOf(...)  // Seed data
+    
+    fun addProduct(product: Product) { ... }  // CRUD
+    fun reset() { ... }  // Reset to defaults
+}
+```
+
+- Verify seed data matches the new domain
+- Ensure CRUD functions reference correct entity types
+- Verify `reset()` works correctly
+- Check that helper functions use `.value` to read from StateFlows
+
+## Report Output
+
+Write the report to `output/{app-name}/reports/05-customization.md` (append Android customization section if file already exists):
+
+```markdown
+# Customization Report
+
+**Step:** 8
+**Skill:** android-customizer
+**Timestamp:** {ISO 8601}
+**Result:** PASS
+
+## Platform
+
+Android (Kotlin / Jetpack Compose)
+
+## Files Modified
+
+- {path}: {what changed}
+- {path}: {what changed}
+
+## Design Tokens Applied
+
+- Primary: {hex} applied to {components}
+- Tab icons: {Material Icon mappings}
+- Corner radius: {value}
+- Typography: {changes}
+
+## Content Applied
+
+- Tab labels: {list}
+- Onboarding slides: {count}
+- Empty states: {count}
+- CTAs updated: {count}
+
+## Offline Infrastructure
+
+- OfflineBanner integrated: {yes/no}
+- NetworkMonitor registered in Application: {yes/no}
+- SyncManager methods updated: {list or "no changes needed"}
+- Data persistence verified: {yes/no}
+
+## Potential Issues
+
+- {any concerns or items needing manual review}
+```
+
+Update `output/{app-name}/reports/summary.json` — read the file, append this step.
+
+**Timing:** Record the current timestamp when you begin this skill. When writing the step entry, set `"startedAt"` to that timestamp (ISO 8601) and `"durationSeconds"` to the elapsed seconds.
+
+```json
+{
+  "step": 8,
+  "name": "android-customization",
+  "startedAt": "{ISO 8601 timestamp}",
+  "durationSeconds": 0,
+  "result": "PASS",
+  "reportFile": "05-customization.md",
+  "filesModified": 0,
+  "platform": "android"
+}
+```
+
+### Step 8 — Test ID Maintenance
+
+Templates include `Modifier.testTag()` on all interactive elements and a `TESTING_MANIFEST.md` file. Follow the conventions in `templates/TEST_ID_CONVENTIONS.md`.
+
+**Preserve existing test tags.** When modifying composables, do NOT remove `Modifier.testTag()` calls. They are critical for Maestro test automation.
+
+**Rename test tags when screens/entities are renamed.** If you rename a screen (e.g., `ProductDetailScreen` → `DrinkDetailScreen`), update all test tags: `product_detail_add_to_cart_button` → `drink_detail_add_to_cart_button`.
+
+**Add test tags to NEW elements.** Every new interactive element you add MUST include a `Modifier.testTag()` following the `{screen}_{element}_{role}` convention:
+```kotlin
+Button(
+    onClick = { ... },
+    modifier = Modifier.testTag("drink_detail_order_button")
+) { Text("Order Now") }
+```
+
+**Update TESTING_MANIFEST.md.** After all screen changes, update the manifest to reflect renamed screens, renamed IDs, new elements, or removed elements.
+
+**Update skeleton Maestro tests.** The template includes `tests/*.yaml` files. Update:
+- Replace `${APP_PACKAGE_NAME}` with the actual package name
+- Update assertion text to match the new domain content
+- Add/remove steps if features were toggled
+- Rename test IDs in selectors to match any renames you made
+
+**Update unit tests.** If entity types were renamed, update test files to reference the new model names. Keep test logic intact, only change types and sample data.
+
+## Important Rules
+
+- ONLY edit files under `output/` — never touch `templates/`
+- Ensure all imports resolve after changes
+- Keep Hilt dependency injection working — `@HiltAndroidApp`, `@AndroidEntryPoint`, `@Inject`
+- Preserve `MockDataProvider` CRUD functions and `reset()` method
+- Do NOT modify NetworkMonitor, LocalPersistence, or OfflineBanner
+- Verify NetworkMonitor is registered in the Application class
+- Use Material 3 components and icons
+- Validate that Gradle sync would succeed (no missing dependencies)
+- Preserve `MVVM` architecture — ViewModels, Models, Repositories stay separated
+- Ensure OfflineBanner is integrated into main navigation composables
+- Preserve ALL `Modifier.testTag()` calls — do NOT remove test IDs
+- Follow `{screen}_{element}_{role}` convention for new test tags (see `templates/TEST_ID_CONVENTIONS.md`)

package/.claude/skills/app-renaming/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: app-renaming
+description: Renames a mobile app from its template name to a new name. Handles display name, bundle ID, package name, directory names, and all code references for both iOS and Android.
+---
+
+# App Renaming Skill
+
+Use this skill when you need to rename a mobile app from its template name to the user's chosen name.
+
+## When to Use
+
+- After cloning a template to `output/`
+- When the user specifies an app name in their description
+- When any template placeholder names need to be replaced
+
+## Instructions
+
+### Preferred: Use the rename script
+
+If `scripts/rename-template.sh` exists, run it instead of doing manual renaming:
+
+```bash
+bash scripts/rename-template.sh {TemplateName} {AppName} {BundleId} {platform}
+```
+
+Example:
+```bash
+bash scripts/rename-template.sh TrackTemplate PetCare com.petcare.app ios
+```
+
+The script handles all file renames, string replacements, Maestro placeholder replacement, and xcodegen regeneration. After running the script, do a quick verification grep for leftover template names and fix any remaining references.
+
+If the script does not exist or fails, fall back to the manual process below.
+
+### Step 1 — Derive Names
+
+From the user's app name (e.g., "PawSpa"), derive:
+- **Display name**: "PawSpa" (user-facing, can have spaces/caps)
+- **Slug**: "pawspa" (lowercase, no spaces, for directories and packages)
+- **Bundle ID** (iOS): `com.{slug}.app` (e.g., `com.pawspa.app`)
+- **Package name** (Android): `com.{slug}.app`
+- **Module name** (Swift): PascalCase with no spaces (e.g., `PawSpa`)
+
+### Step 2 — iOS Renaming
+
+1. **AppConfig.swift**: Update `appName`, `bundleId` or any name references
+2. **project.yml** (XcodeGen): Update `name`, `bundleIdPrefix`, target names
+3. **.xcodeproj/project.pbxproj**: Update `PRODUCT_BUNDLE_IDENTIFIER`, `PRODUCT_NAME`, target names
+4. **Info.plist**: Update `CFBundleDisplayName`, `CFBundleName` if present
+5. **Directory names**: Rename `{TemplateName}/` folder inside the project to `{NewName}/`
+6. **Swift files**: Update `import {OldModule}` statements, class/struct namespaces
+7. **App entry point**: Rename `{Template}App.swift` to `{NewName}App.swift`, update `@main` struct name
+
+### Step 3 — Android Renaming
+
+1. **AppConfig.kt**: Update `APP_NAME` and any name references
+2. **settings.gradle.kts**: Update `rootProject.name`
+3. **build.gradle.kts** (app): Update `namespace` and `applicationId`
+4. **AndroidManifest.xml**: Update `android:label`, verify package reference
+5. **Package directories**: Rename `com/appship/{oldname}/` to `com/{slug}/app/` (or keep `com.appship.{slug}`)
+6. **Kotlin files**: Update `package` declarations at the top of each file
+7. **Application class**: Rename `{Template}Application.kt` and update class name
+8. **Hilt modules**: Update any `@HiltAndroidApp` annotated class name
+
+### Important Rules
+
+- **Be thorough** — a partial rename will break the build
+- **Use find-and-replace** across the entire project, not just key files
+- **Check imports** after renaming — every `import` statement must resolve
+- **Test the package structure** — Android requires directory structure to match package name
+- **Preserve the `com.appship` prefix** if the user doesn't specify a domain — just change the app-specific part (e.g., `com.appship.shop` -> `com.appship.pawspa`)

package/.claude/skills/appconfig-customization/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: appconfig-customization
+description: Systematically updates the AppConfig file by processing all CUSTOMIZE markers. Covers branding, features, API endpoints, business rules, content, theme, and categories.
+allowed-tools: Read, Edit, Write, Grep, Glob, LS
+---
+
+# AppConfig Customization Skill
+
+Update the central AppConfig file to match the user's app requirements.
+
+## Instructions
+
+### Step 1 — Read Current AppConfig
+
+Read `AppConfig.swift` (iOS) or `AppConfig.kt` (Android). Identify all `// CUSTOMIZE:` markers.
+
+### Step 2 — Process Each Marker
+
+- **CUSTOMIZE:BRANDING** — appName, bundleId, tagline
+- **CUSTOMIZE:FEATURES** — enable/disable feature flags per user description
+- **CUSTOMIZE:API** — set baseURL to placeholder, update domain paths
+- **CUSTOMIZE:BUSINESS** — adapt business rules to domain
+- **CUSTOMIZE:CONTENT** — supportEmail, URLs, descriptions
+- **CUSTOMIZE:THEME** — colors from design-system palette, typography, spacing
+- **CUSTOMIZE:CATEGORIES** — domain-specific categories
+- **CUSTOMIZE:ONBOARDING** — slides from content-writer brief
+
+### Step 3 — Verify Completeness
+
+Search for remaining `// CUSTOMIZE:` comments. Ensure no template defaults remain.
+
+## Report Output
+
+Write report and update summary.json.
+
+## Important Rules
+
+- Process ALL markers
+- Keep struct/object structure intact
+- Use realistic placeholder values
+- Colors must be valid hex codes

package/.claude/skills/build-tester/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: build-tester
+description: Attempts to build the generated app and reports compilation errors. Handles both iOS (xcodebuild) and Android (Gradle) builds. Reports the build artifact path needed for UI testing.
+allowed-tools: Read, Edit, Write, Grep, Glob, LS, Bash
+---
+
+# Build Tester Skill
+
+Compile the generated app and verify it builds successfully.
+
+## Instructions
+
+### Step 1 — Identify the App
+
+Find app directory under output/. Confirm platform by file types.
+
+### Step 2 — Attempt the Build
+
+**iOS:** xcodegen generate (if project.yml exists), then xcodebuild with iphonesimulator SDK.
+**Android:** ./gradlew assembleDebug.
+
+### Step 3 — Locate Build Artifact
+
+**iOS:** Find .app in DerivedData/Debug-iphonesimulator/
+**Android:** Find .apk in build/outputs/apk/debug/
+
+This path is CRITICAL — the ui-tester needs it.
+
+### Step 4 — Run Unit Tests
+
+After a successful build, run the unit test suite:
+
+**iOS:** `xcodebuild test` with the test scheme or app scheme, targeting an iOS Simulator.
+**Android:** `./gradlew test`
+
+Record tests run/passed/failed. If tests fail due to renamed entities, fix the test code and re-run. Test failures do NOT block the build — the artifact is still valid.
+
+### Step 5 — Handle Failures
+
+Parse errors, categorize (IMPORT/TYPE/SYNTAX/CONFIG), suggest fixes, fix and rebuild. Repeat until success.
+
+## Report Output
+
+Write `output/{app-name}/reports/06-build.md` and update summary.json with artifact path.
+
+## Important Rules
+
+- Report ALL errors
+- Always report BUILD ARTIFACT path on success
+- Time limit: kill builds taking > 3 minutes
+- Fix errors between attempts
+- Templates include unit tests — run them after building and include results in report
+- Templates include skeleton Maestro tests in `tests/` and a `TESTING_MANIFEST.md` — verify they exist after the build

package/.claude/skills/code-auditor/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: code-auditor
+description: Scans generated app code for security vulnerabilities — hardcoded secrets, insecure transport, unsafe storage, excessive permissions, and malicious code patterns. Run after the build succeeds.
+allowed-tools: Read, Grep, Glob, LS
+context: fork
+agent: Explore
+---
+
+# Code Auditor Skill
+
+Scan generated code for security vulnerabilities after build succeeds.
+
+## Instructions
+
+### Step 1 — Secrets Scan
+
+Search for hardcoded API keys, tokens, credentials, private keys. Placeholder URLs are acceptable.
+
+### Step 2 — Transport Security
+
+iOS: Check Info.plist for NSAllowsArbitraryLoads, verify https:// URLs.
+Android: Check AndroidManifest for usesCleartextTraffic, verify https:// URLs.
+
+### Step 3 — Storage Security
+
+iOS: No sensitive data in UserDefaults. Android: No sensitive data in SharedPreferences.
+
+### Step 4 — Permissions Audit
+
+Only necessary permissions declared. Each has clear description.
+
+### Step 5 — Debug Configuration
+
+No sensitive data in debug logging. No debuggable=true in release.
+
+### Step 6 — Malicious Code Patterns
+
+Check for: reverse shells, data exfiltration, hidden functionality, obfuscated payloads, disproportionate permissions.
+
+### Step 7 — Determine Verdict
+
+PASS = zero CRITICAL findings. FAIL = one or more CRITICAL findings.
+
+## Report Output
+
+Write `output/{app-name}/reports/07-security-audit.md` and update summary.json.
+
+## Important Rules
+
+- READ-ONLY — do NOT modify any files
+- Placeholder URLs are NOT security issues
+- Mock data with fake names is NOT PII
+- Focus on real harm patterns

package/.claude/skills/content-writer/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: content-writer
+description: Generates all user-facing strings for a new app domain — onboarding, tab labels, empty states, CTAs, errors, and more. Run after design-system and before AppConfig customization.
+allowed-tools: Read, Grep, Glob, LS
+---
+
+# Content Writer Skill
+
+Produce all user-facing text for the app in one pass with consistent tone and domain relevance.
+
+## Instructions
+
+### Step 1 — Establish Voice
+
+Match copy voice to visual tone: playful=friendly/casual, professional=clear/confident, minimal=concise, bold=energetic/direct.
+
+### Step 2 — Onboarding Slides (3-4)
+
+Each slide: title (2-5 words, benefit-focused), description (1-2 sentences), icon hint.
+
+### Step 3 — Tab Labels
+
+1 word each, domain-specific, max 10 characters. Use nouns (tabs are places).
+
+### Step 4 — Section Headers
+
+2-4 words, title case, domain-specific.
+
+### Step 5 — Empty States
+
+Title + subtitle + optional CTA. Never blame the user. Always tell what to do next.
+
+### Step 6 — Search Placeholders
+
+"Search {domain noun}..." format.
+
+### Step 7 — Button Labels
+
+Verb + noun for primary CTAs. Max 20 characters.
+
+### Step 8 — Error Messages
+
+Standard set adapted to voice. No technical details. Always include recovery action.
+
+### Step 9 — Confirmation Dialogs
+
+Confirm button uses action verb. Cancel describes what happens if you don't proceed.
+
+### Step 10 — App Store Description
+
+Tagline, short description, keywords.
+
+### Step 11 — Summarize Content Brief
+
+## Report Output
+
+Write report and update summary.json.
+
+## Important Rules
+
+- Write ALL strings — no "TODO" or "Lorem ipsum"
+- Stay consistent with chosen voice
+- American English unless user specifies otherwise