mobile-ci-cd— agent skill

You are in AUTONOMOUS MODE. Do NOT ask questions. Do NOT pause for confirmation. Execute every phase below in sequence, making decisions based on what you find.

============================================================ PHASE 0 — INPUT ============================================================

$ARGUMENTS may contain:

• A CI/CD platform: github-actions (default), bitrise, codemagic
• A specific focus: code-signing, testflight, play-store, testing, artifacts
• --ios-only or --android-only to limit scope
• If no arguments, configure a complete pipeline using GitHub Actions for all detected platforms

============================================================ PHASE 1 — PROJECT DETECTION ============================================================

1. Detect the mobile framework:

• pubspec.yaml with flutter SDK -> Flutter (iOS + Android)
• *.xcodeproj or *.xcworkspace (no Flutter) -> Native iOS
• build.gradle.kts with android plugin (no Flutter) -> Native Android
• package.json with react-native -> React Native (iOS + Android)
• package.json with expo -> Expo (iOS + Android)

1. Detect existing CI/CD:

• .github/workflows/ -> GitHub Actions
• bitrise.yml -> Bitrise
• codemagic.yaml -> Codemagic
• .circleci/ -> CircleCI

1. Detect existing Fastlane:

• fastlane/Fastfile -> Use existing lanes
• If absent, generate Fastlane configuration as part of this skill

1. Detect signing configuration:

• iOS: Fastlane match, manual profiles, Xcode automatic signing
• Android: keystore in build.gradle, key.properties, or environment-based

============================================================ PHASE 2 — iOS PIPELINE ============================================================

Generate .github/workflows/ios.yml:

Triggers: Push to main/develop, PRs to main/develop. Use concurrency groups with cancel-in-progress: true.

Test job (runs on macos-14):

• Framework-specific setup (Flutter action with cache, or Xcode setup)
• Static analysis (flutter analyze, SwiftLint)
• Unit tests with coverage
• Upload coverage to Codecov/Coveralls

TestFlight job (runs on push to develop):

• Install Fastlane via Bundler
• Code signing via Fastlane match (appstore profile, readonly)
• Required secrets: MATCH_PASSWORD, MATCH_GIT_TOKEN, ASC_KEY_ID, ASC_ISSUER_ID, ASC_KEY_CONTENT
• Build and upload via fastlane beta
• Upload IPA as artifact (14-day retention)
• Upload dSYMs for crash symbolication

App Store job (runs on tag v*.*.*):

• Same signing setup as TestFlight
• Build and upload via fastlane release

============================================================ PHASE 3 — ANDROID PIPELINE ============================================================

Generate .github/workflows/android.yml:

Triggers: Same as iOS. Concurrency groups.

Test job (runs on ubuntu-latest):

• Java 17 setup with Gradle cache
• Framework-specific setup (Flutter, React Native, or native)
• Static analysis (flutter analyze, ./gradlew lint)
• Unit tests with coverage

Internal Track job (runs on push to develop):

• Decode keystore from base64 secret
• Required secrets: KEYSTORE_BASE64, KEYSTORE_PASSWORD, KEY_ALIAS, KEY_PASSWORD, PLAY_STORE_JSON_KEY
• Build AAB (never APK for Play Store)
• Upload to internal testing track via Fastlane supply
• Upload AAB as artifact (14-day retention)
• Upload mapping files for ProGuard deobfuscation

Production job (runs on tag v*.*.*):

• Same signing setup
• Upload to production with staged rollout (start at 10%)

============================================================ PHASE 4 — BUILD NUMBER MANAGEMENT ============================================================

Configure a build number strategy that guarantees monotonically increasing values:

Recommended: CI run number (${{ github.run_number }}) — simple and monotonic.

Alternative A: Git commit count (git rev-list --count HEAD) — tied to commit history.

Alternative B: Timestamp (date +%Y%m%d%H%M) — works for infrequent builds.

Inject build number per framework:

• Flutter: flutter build --build-number=$BUILD_NUMBER
• iOS Native: Fastlane increment_build_number(build_number: ENV["BUILD_NUMBER"])
• Android Native: Set versionCode from environment variable in gradle

============================================================ PHASE 5 — CODE SIGNING IN CI ============================================================

iOS Signing:

• Fastlane match with git-based encrypted certificate storage
• App Store Connect API key (preferred over password auth in CI)
• Temporary keychain created and destroyed per job (match handles this)

Android Signing:

• Keystore stored as base64-encoded GitHub secret
• Decoded to file before build, deleted after
• Play Store service account JSON key as secret

Generate a signing setup checklist documenting every secret, where to obtain it, and how to encode it.

============================================================ PHASE 6 — AUTOMATED TESTING ============================================================

Configure comprehensive test jobs:

Unit tests: Flutter flutter test --coverage, iOS xcodebuild test, Android ./gradlew test

Static analysis: Flutter flutter analyze, iOS SwiftLint, Android ./gradlew lint

Coverage: Upload to Codecov or Coveralls. Set minimum coverage thresholds.

Optional UI tests:

• iOS: Simulator-based tests on macOS runner
• Android: Firebase Test Lab integration via Fastlane
• Flutter: flutter test integration_test/ on simulator/emulator

============================================================ PHASE 7 — ARTIFACT MANAGEMENT ============================================================

Configure artifact retention:

• IPA / AAB files: 14-day retention for PR builds, 90-day for releases
• Test results: always uploaded as artifacts
• Coverage reports: uploaded to coverage service
• dSYM files: archived for crash symbolication
• Mapping files: archived for ProGuard deobfuscation

============================================================ SELF-HEALING VALIDATION (max 2 iterations) ============================================================

After completing deployment/infrastructure changes, validate:

1. Verify all generated files are syntactically valid (YAML, JSON, HCL, Dockerfile).
2. Run validation commands if available (terraform validate, docker build --check, kubectl dry-run).
3. Verify no secrets, credentials, or sensitive values are hardcoded.
4. If validation fails, diagnose and fix the specific syntax or config error.
5. Repeat up to 2 iterations.

IF STILL FAILING after 2 iterations:

• Document what failed and the exact error
• Include partial output if available

============================================================ OUTPUT ============================================================

## Mobile CI/CD Pipeline Complete

### Platform: {GitHub Actions / Bitrise / Codemagic}
### Framework: {Flutter / iOS Native / Android Native / React Native}

### Pipeline Overview
| Trigger | iOS Action | Android Action |
|---------|------------|----------------|
| PR | Test + analyze | Test + lint |
| Push to develop | Test + TestFlight | Test + Internal Track |
| Tag v*.*.* | Test + App Store | Test + Production (10%) |

### Required Secrets
| Secret | Platform | How to Obtain |
|--------|----------|---------------|
| MATCH_PASSWORD | iOS | Chosen during match init |
| MATCH_GIT_TOKEN | iOS | GitHub PAT with repo scope |
| ASC_KEY_ID | iOS | App Store Connect > Keys |
| ASC_ISSUER_ID | iOS | App Store Connect > Keys |
| ASC_KEY_CONTENT | iOS | .p8 file contents |
| KEYSTORE_BASE64 | Android | base64 -w0 upload-keystore.jks |
| KEYSTORE_PASSWORD | Android | Chosen during keytool |
| KEY_ALIAS | Android | Chosen during keytool |
| KEY_PASSWORD | Android | Chosen during keytool |
| PLAY_STORE_JSON_KEY | Android | GCP service account JSON |

### Files Created
{list all generated workflow and configuration files}

============================================================ NEXT STEPS ============================================================

1. Configure the required secrets in your GitHub repository settings
2. Run deploy/play-store-publish to set up Fastlane lanes for Play Store
3. Run deploy/app-store-publish to set up Fastlane lanes for App Store
4. Run deploy/ota-updates to configure over-the-air update infrastructure

============================================================ SELF-EVOLUTION TELEMETRY ============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /mobile-ci-cd — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.

============================================================ DO NOT ============================================================

• Do NOT store signing keys, keystores, or API keys in the repository
• Do NOT use self-hosted runners for code signing without proper secret isolation
• Do NOT skip test jobs — builds without tests provide false confidence
• Do NOT build APK instead of AAB for Play Store uploads
• Do NOT use password-based App Store Connect auth — API keys are more reliable in CI
• Do NOT hardcode build numbers — they must be dynamic and monotonically increasing
• Do NOT skip artifact upload — build outputs are needed for debugging and compliance
• Do NOT use deprecated action versions — pin to latest major versions