opencode-skills-collection 4.0.68 → 4.0.70

package/bundled-skills/eas-app-stores/references/play-store.md

@@ -0,0 +1,244 @@
+# Submitting to Google Play Store
+
+## Prerequisites
+
+1. **Google Play Console Account** - Register at [play.google.com/console](https://play.google.com/console)
+2. **App Created in Console** - Create your app listing before first submission
+3. **Service Account** - For automated submissions via EAS
+
+Once these are complete, the default `eas submit` works for a first-time submission and creates the app's first release on the internal testing track. Store listing, content rating, and pricing are only required before promoting a release to production.
+
+## Service Account Setup
+
+### 1. Create Service Account
+
+1. Go to Google Cloud Console → IAM & Admin → Service Accounts
+2. Create a new service account
+3. Grant the "Service Account User" role
+4. Create and download a JSON key
+
+### 2. Link to Play Console
+
+1. Go to Play Console → Setup → API access
+2. Click "Link" next to your Google Cloud project
+3. Under "Service accounts", click "Manage Play Console permissions"
+4. Grant "Release to production" permission (or appropriate track permissions)
+
+### 3. Configure EAS
+
+Add the service account key path to `eas.json`:
+
+```json
+{
+  "submit": {
+    "production": {
+      "android": {
+        "serviceAccountKeyPath": "./google-service-account.json",
+        "track": "internal"
+      }
+    }
+  }
+}
+```
+
+Store the key file securely and add it to `.gitignore`.
+
+## Environment Variables
+
+For CI/CD, use environment variables instead of file paths:
+
+```bash
+# Base64-encoded service account JSON
+EXPO_ANDROID_SERVICE_ACCOUNT_KEY_BASE64=...
+```
+
+Or use EAS Secrets:
+
+```bash
+eas secret:create --name GOOGLE_SERVICE_ACCOUNT --value "$(cat google-service-account.json)" --type file
+```
+
+Then reference in `eas.json`:
+
+```json
+{
+  "submit": {
+    "production": {
+      "android": {
+        "serviceAccountKeyPath": "@secret:GOOGLE_SERVICE_ACCOUNT"
+      }
+    }
+  }
+}
+```
+
+## Release Tracks
+
+Google Play uses tracks for staged rollouts:
+
+| Track | Purpose |
+|-------|---------|
+| `internal` | Internal testing (up to 100 testers) |
+| `alpha` | Closed testing |
+| `beta` | Open testing |
+| `production` | Public release |
+
+### Track Configuration
+
+```json
+{
+  "submit": {
+    "production": {
+      "android": {
+        "track": "production",
+        "releaseStatus": "completed"
+      }
+    },
+    "internal": {
+      "android": {
+        "track": "internal",
+        "releaseStatus": "completed"
+      }
+    }
+  }
+}
+```
+
+### Release Status Options
+
+- `completed` - Immediately available on the track
+- `draft` - Upload only, release manually in Console
+- `halted` - Pause an in-progress rollout
+- `inProgress` - Staged rollout (requires `rollout` percentage)
+
+## Staged Rollout
+
+```json
+{
+  "submit": {
+    "production": {
+      "android": {
+        "track": "production",
+        "releaseStatus": "inProgress",
+        "rollout": 0.1
+      }
+    }
+  }
+}
+```
+
+This releases to 10% of users. Increase via Play Console or subsequent submissions.
+
+## Submission Commands
+
+```bash
+# Build and submit to internal track
+eas build -p android --profile production --auto-submit
+
+# Submit existing build to Play Store
+eas submit -p android --latest
+
+# Submit specific build
+eas submit -p android --id BUILD_ID
+```
+
+## App Signing
+
+### Google Play App Signing (Recommended)
+
+EAS uses Google Play App Signing by default:
+
+1. First upload: EAS creates upload key, Play Store manages signing key
+2. Play Store re-signs your app with the signing key
+3. Upload key can be reset if compromised
+
+### Checking Signing Status
+
+```bash
+eas credentials -p android
+```
+
+## Version Codes
+
+Android requires incrementing `versionCode` for each upload:
+
+```json
+{
+  "build": {
+    "production": {
+      "autoIncrement": true
+    }
+  }
+}
+```
+
+With `appVersionSource: "remote"`, EAS tracks version codes automatically.
+
+## First Submission Checklist
+
+Before your first Play Store submission:
+
+- [ ] Create app in Google Play Console
+- [ ] Complete app content declaration (privacy policy, ads, etc.)
+- [ ] Set up store listing (title, description, screenshots)
+- [ ] Complete content rating questionnaire
+- [ ] Set up pricing and distribution
+- [ ] Create service account with proper permissions
+- [ ] Configure `eas.json` with service account path
+
+## Common Issues
+
+### "App not found"
+
+The app must exist in Play Console before EAS can submit. Create it manually first.
+
+### "Version code already used"
+
+Increment `versionCode` in `app.json` or use `autoIncrement: true` in `eas.json`.
+
+### "Service account lacks permission"
+
+Ensure the service account has "Release to production" permission in Play Console → API access.
+
+### "APK not acceptable"
+
+Play Store requires AAB (Android App Bundle) for new apps:
+
+```json
+{
+  "build": {
+    "production": {
+      "android": {
+        "buildType": "app-bundle"
+      }
+    }
+  }
+}
+```
+
+## Internal Testing Distribution
+
+For quick internal distribution without Play Store:
+
+```bash
+# Build with internal distribution
+eas build -p android --profile development
+
+# Share the APK link with testers
+```
+
+Or use EAS Update for OTA updates to existing installs.
+
+## Monitoring Submissions
+
+Follow the submission URL returned by `eas submit` for status and logs. Check Play Console for the resulting track and release state.
+
+With EAS CLI 23.2.0, `eas submit:list -p android --json` and `eas submit:view SUBMISSION_ID --json` report EAS submission jobs. `submit:status` currently reads Apple status only; do not treat an EAS job's success as confirmation of Play Console rollout.
+
+## Tips
+
+- Start with `internal` track for testing before production
+- Use staged rollouts for production releases
+- Keep service account key secure - never commit to git
+- Set up Play Console notifications for review status
+- Pre-launch reports in Play Console catch issues before review

package/bundled-skills/eas-app-stores/references/testflight.md

@@ -0,0 +1,62 @@
+# TestFlight
+
+For a SwiftUI/UIKit app with no React Native runtime, start with [native-ios.md](native-ios.md). EAS can build and submit it without adding Expo or React Native. For an established Expo/React Native app, `npx testflight` is also a convenient setup flow.
+
+## Submit an identified build
+
+Use a store-distribution profile and record the source revision and returned build ID:
+
+```bash
+eas build --platform ios --profile testflight --no-wait --non-interactive
+# After checking that build's result:
+eas submit --platform ios --profile testflight --id BUILD_ID --non-interactive
+```
+
+Use the project's actual profile name. If `--non-interactive` exposes missing first-time credentials, configure them with `eas credentials -p ios`; repeated noninteractive retries will not complete that setup. Keep an existing EAS project, Apple team, bundle ID, and App Store Connect app record aligned.
+
+`eas build --auto-submit` can submit the finished build with its matching submit profile. For separate jobs, pass the explicit build ID rather than selecting whichever unrelated build is newest.
+
+## Read status without reopening a submission
+
+The following commands were verified with EAS CLI 23.2.0, including read-only checks of a completed iOS submission and its actual TestFlight state:
+
+```bash
+eas submit:list --platform ios --json
+eas submit:view SUBMISSION_ID --json
+eas submit:status --platform ios --profile testflight --json --non-interactive
+```
+
+Use the project's actual profile. `submit:view` reports the EAS job; `submit:status` reads App Store Connect and reports App Store versions and TestFlight processing/internal/external states. The latter needs an App Store Connect API key from the selected profile, environment, or existing EAS credentials. In noninteractive mode, a missing key is a setup error; it does not mean the build failed or does not exist. A beta state alone does not establish that a particular tester has access.
+
+Older CLIs such as 18.6.0 lack these commands. Check `eas --version` and command help, or use a pinned `npx eas-cli@23.2.0` invocation. Prefer the supported CLI over importing its internal Node modules or writing private GraphQL queries. An errored `submit:view --json` result can still omit the underlying error; follow its log URLs to diagnose it.
+
+## Track the release state
+
+| Verified state | What it establishes | Next check |
+| --- | --- | --- |
+| EAS build finished | An artifact was produced | Confirm the intended build ID, source revision and store-distribution profile |
+| Submission queued | EAS scheduled an upload | Follow the returned submission URL and worker logs |
+| Apple upload/processing succeeded | Apple accepted the binary | Check TestFlight availability and any export-compliance work |
+| Build assigned and available to testers | The intended testers can install it | Verify the beta app on a device |
+| App Review approved and released | Public App Store distribution | Only part of an authorized production release |
+
+Do not report an upload as finished based only on `--no-wait` returning successfully. If a submission fails with an empty summary, inspect its worker logs; the underlying Apple error may be there. Report the exact version/build and the furthest state actually verified.
+
+[Apple's TestFlight overview](https://developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview/) describes tester limits and beta review. Processing, compliance, group assignment and invitations affect availability; do not promise immediate installation. Internal testing and external beta review are separate from public App Review. Add builds to existing requested groups when authorized; do not create invitations or expand distribution implicitly.
+
+## Troubleshooting
+
+| Symptom | Action |
+| --- | --- |
+| Required agreement missing or expired | The Account Holder must resolve it for the app's Apple team. Retrying or rebuilding does not accept an agreement. |
+| App missing in App Store Connect | Check the selected organization and `ascAppId` against the native bundle identifier. One login may belong to several teams. |
+| Duplicate build number despite EAS auto-increment | Inspect the archive's `CFBundleVersion`; for native Swift, check explicit versus generated plist configuration in `native-ios.md`. |
+| Invalid large app icon / alpha channel | For the default (Any/light) AppIcon PNG, remove the alpha channel and rebuild. Even an all-opaque RGBA file can fail. Check the icon selected by that profile; preserve transparency in dark variants and Icon Composer layers. See the icon checks in `native-ios.md`. |
+| Upload accepted but no installable build | Check processing/compliance state and the intended tester group's build assignment in App Store Connect. |
+| Optional release-notes feature rejected by the EAS plan | Complete the required upload without that optional parameter and use App Store Connect for notes. Do not rebuild a valid binary or change the account plan for this. |
+
+After an archive-content failure, fix the cause, validate the new artifact and submit its exact ID. After an account/submission-only failure, reuse the valid existing artifact once the account issue is resolved. Keep the requested release scope; uploading a beta does not authorize a public App Store release.
+
+EAS CLI 23.2.0 also provides `eas submit:retry SUBMISSION_ID --json --non-interactive`. Check `submit:view` for retry eligibility and diagnose the cause first. Retrying an unchanged archive cannot fix its build number or icon; submit the corrected build instead. Use retry only when repeating the existing authorized upload is appropriate.
+
+Use [EAS Submit for iOS](https://docs.expo.dev/submit/ios/) for current CLI/configuration guidance, and [Apple's internal-tester guide](https://developer.apple.com/help/app-store-connect/test-a-beta-version/add-internal-testers/) for group setup. EAS upload success alone does not show that a particular tester has access.

package/bundled-skills/eas-app-stores/references/workflows.md

@@ -0,0 +1,120 @@
+# EAS Workflows
+
+Automate builds, submissions, and PR-preview updates with EAS Workflows. The examples below are store-release-oriented starting points.
+
+When you need to write, edit, or validate a workflow YAML file beyond these examples, use the `eas-workflows` skill. For website and API-route deploy workflows (`type: deploy`), see the `eas-hosting` skill.
+
+## PR Previews with EAS Update
+
+Deploy OTA updates for pull requests:
+
+```yaml
+name: PR Preview
+
+on:
+  pull_request:
+    types: [opened, synchronize]
+
+jobs:
+  publish:
+    type: update
+    params:
+      branch: "pr-${{ github.event.pull_request.number }}"
+      message: "PR #${{ github.event.pull_request.number }}"
+```
+
+## Production Release
+
+Complete release workflow for both platforms:
+
+```yaml
+name: Release
+
+on:
+  push:
+    tags: ['v*']
+
+jobs:
+  build-ios:
+    type: build
+    params:
+      platform: ios
+      profile: production
+
+  build-android:
+    type: build
+    params:
+      platform: android
+      profile: production
+
+  submit-ios:
+    type: submit
+    needs: [build-ios]
+    params:
+      platform: ios
+      profile: production
+
+  submit-android:
+    type: submit
+    needs: [build-android]
+    params:
+      platform: android
+      profile: production
+```
+
+## Build on Push
+
+Trigger builds when pushing to specific branches:
+
+```yaml
+name: Build
+
+on:
+  push:
+    branches:
+      - main
+      - release/*
+
+jobs:
+  build:
+    type: build
+    params:
+      platform: all
+      profile: production
+```
+
+## Conditional Jobs
+
+Run jobs based on conditions:
+
+```yaml
+name: Conditional Release
+
+on:
+  push:
+    branches: [main]
+
+jobs:
+  check-changes:
+    type: run
+    params:
+      command: |
+        if git diff --name-only HEAD~1 | grep -q "^src/"; then
+          echo "has_changes=true" >> $GITHUB_OUTPUT
+        fi
+
+  build:
+    type: build
+    needs: [check-changes]
+    if: needs.check-changes.outputs.has_changes == 'true'
+    params:
+      platform: all
+      profile: production
+```
+
+## Tips
+
+- Use `workflow_dispatch` for manual production releases
+- Combine PR previews with GitHub status checks
+- Use tags for versioned releases
+- Keep sensitive values in EAS Secrets, not workflow files