opencode-skills-collection 4.0.69 → 4.0.70

package/bundled-skills/devops-pipeline-builder/SKILL.md

@@ -0,0 +1,200 @@
+---
+name: devops-pipeline-builder
+version: 1.0.0
+description: Design and implement CI/CD pipelines, Docker configurations, deployment
+  strategies, and infrastructure automation with production-ready patterns.
+author: yundu-ai
+tags:
+- devops
+- ci-cd
+- docker
+- kubernetes
+- deployment
+- automation
+model: claude
+source_repo: demo112/yunqu-ai-skills
+source_type: community
+source: community
+date_added: '2026-09-21'
+risk: unknown
+---
+## When to Use
+- Use when this upstream workflow matches the user's stated goal.
+- Use when the task requires the procedures documented in this skill.
+
+# DevOps Pipeline Builder
+
+You are a DevOps engineer who has built and maintained pipelines processing millions of deployments. You design for reliability, speed, and security — in that order.
+
+## Decision Framework
+
+Before writing any pipeline/config, establish:
+
+1. **Project type**: Web app, API, library, microservice, monolith?
+2. **Language/stack**: What build tools? What test framework?
+3. **Deployment target**: Docker, K8s, VM, serverless, static?
+4. **Environment strategy**: dev → staging → production?
+5. **Compliance needs**: SOC2? HIPAA? Any audit requirements?
+6. **Team size**: 1 person vs 50 devs changes the complexity budget
+
+## Pipeline Patterns
+
+### GitHub Actions — Standard Web App
+
+```yaml
+name: CI/CD Pipeline
+
+on:
+  push:
+    branches: [main]
+  pull_request:
+    branches: [main]
+
+env:
+  REGISTRY: ghcr.io
+  IMAGE_NAME: ${{ github.repository }}
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+          cache: 'npm'
+      - run: npm ci
+      - run: npm test
+      - run: npm run lint
+      # Security audit
+      - run: npm audit --audit-level=high
+      
+  build-and-push:
+    needs: test
+    if: github.ref == 'refs/heads/main'
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      packages: write
+    steps:
+      - uses: actions/checkout@v4
+      - uses: docker/login-action@v3
+        with:
+          registry: ${{ env.REGISTRY }}
+          username: ${{ github.actor }}
+          password: ${{ secrets.GITHUB_TOKEN }}
+      - uses: docker/build-push-action@v5
+        with:
+          context: .
+          push: true
+          tags: |
+            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
+            ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.sha }}
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
+
+  deploy:
+    needs: build-and-push
+    runs-on: ubuntu-latest
+    environment: production
+    steps:
+      - run: |
+          # Add deployment commands here
+          echo "Deploying ${{ github.sha }} to production"
+```
+
+### Docker — Multi-stage Production Build
+
+```dockerfile
+# Stage 1: Build
+FROM node:22-alpine AS builder
+WORKDIR /app
+COPY package*.json ./
+RUN npm ci --ignore-scripts
+COPY . .
+RUN npm run build
+
+# Stage 2: Production
+FROM node:22-alpine AS runner
+WORKDIR /app
+RUN addgroup --system --gid 1001 appgroup && \
+    adduser --system --uid 1001 appuser
+
+COPY --from=builder /app/dist ./dist
+COPY --from=builder /app/node_modules ./node_modules
+COPY --from=builder /app/package.json ./
+
+USER appuser
+EXPOSE 3000
+HEALTHCHECK --interval=30s --timeout=3s \
+  CMD wget -qO- http://localhost:3000/health || exit 1
+
+CMD ["node", "dist/server.js"]
+```
+
+## Deployment Strategy Decision Tree
+
+```
+Is zero-downtime required?
+├── Yes
+│   ├── Have load balancer/ingress?
+│   │   ├── Yes → Blue/Green or Rolling Update
+│   │   └── No → Canary with traffic splitting
+│   └── Database migrations?
+│       ├── Yes → Backward-compatible migrations first
+│       └── No → Simple rolling update
+└── No
+    ├── Is it a dev/staging env?
+    │   └── Yes → Direct push, recreate containers
+    └── No → Why not? Add zero-downtime.
+```
+
+## Common Anti-Patterns to Avoid
+
+| Anti-Pattern | Why It's Bad | Fix |
+|---|---|---|
+| `latest` tag in production | Non-reproducible, untraceable | Use SHA or semver tags |
+| Build secrets in Dockerfile | Visible in image layers | Multi-stage + build args |
+| No health checks | Orchestration can't detect failures | Add HEALTHCHECK |
+| Running as root | Security risk | Create non-root user |
+| Giant Docker images | Slow pulls, attack surface | Multi-stage builds, alpine |
+| No `.dockerignore` | Slow builds, leaked secrets | Create comprehensive `.dockerignore` |
+| Hardcoded env vars | Inflexible, unsecretive | Runtime env injection |
+| No pipeline caching | Slow CI, wasted compute | Cache layers and dependencies |
+
+## Infrastructure Checklist
+
+For any production deployment, verify:
+
+- [ ] Health check endpoint exists and checks all dependencies
+- [ ] Graceful shutdown (SIGTERM handling)
+- [ ] Structured logging (JSON, correlation IDs)
+- [ ] Secrets management (not in env vars in K8s, use sealed secrets/vault)
+- [ ] Resource limits set (CPU/memory requests and limits)
+- [ ] Monitoring dashboards configured
+- [ ] Alert rules for: high error rate, high latency, low availability
+- [ ] Rollback procedure documented and tested
+- [ ] Database migration strategy (backward compatible)
+- [ ] Rate limiting configured
+
+## When Asked to Debug CI/CD
+
+1. Check the **exact error message** — it usually tells you what's wrong
+2. Verify **secret availability** — most CI failures are auth/secret issues
+3. Check **dependency caching** — stale cache = weird errors
+4. Verify **environment parity** — "works on my machine" = environment difference
+5. Check **resource limits** — CI runners have memory/CPU limits
+6. Look at **timing** — tests that fail intermittently = race condition or flaky test
+
+
+## Examples
+
+```text
+User: Apply this skill to my current task.
+Assistant: Follow the workflow in this skill, cite limitations, and ask before risky steps.
+```
+
+## Limitations
+
+- Imported upstream skill; verify credentials, permissions, and safety boundaries before execution.
+- Does not replace environment-specific validation, testing, or maintainer review.

package/bundled-skills/eas-app-stores/SKILL.md

@@ -0,0 +1,197 @@
+---
+description: Curated upstream guidance for Eas App Stores; use when the workflow matches the user goal.
+name: eas-app-stores
+version: 1.1.0
+license: MIT
+source_repo: expo/skills
+source_type: official
+source: expo
+date_added: '2026-09-21'
+risk: unknown
+---
+## When to Use
+- Use when this upstream workflow matches the user's stated goal.
+- Use when the task requires the procedures documented in this skill.
+
+# App Store Deployment
+
+> **EAS service - costs apply.** Cloud builds use EAS plan resources, and EAS services have free-tier and paid-plan limits. Apple Developer and Google Play memberships are separate. Check https://expo.dev/pricing for the requested service.
+
+This skill covers building and releasing iOS and Android apps with EAS: Expo and other React Native projects, plus existing native apps. EAS is a delivery service; native apps can use it without adding Expo or React Native to their runtime. The native setup walkthrough currently covers SwiftUI/UIKit on iOS.
+
+## Choose the project path
+
+- **SwiftUI/UIKit app with no React Native runtime:** read [references/native-ios.md] before changing its build configuration. Keep the Xcode project and Swift code as the app's source of truth. The Expo/React Native quick-start and development-client examples below do not apply to this path.
+- **Native Android app with no React Native runtime:** preserve its existing native build setup. See [references/play-store.md] for submission; the Swift/iOS setup instructions do not apply. A dedicated native Android setup walkthrough is not yet included.
+- **Expo/React Native app:** use the quick-start below, then the relevant store reference.
+- **Adding React Native screens to an existing native app:** use `expo-brownfield` for that integration; return here for distribution.
+
+Use the archive and icon checks in [references/native-ios.md] during initial native iOS setup, after changing versioning, bundle IDs, or icons, or when diagnosing a rejected upload. Routine releases follow the EAS build/submit flow and the processing and availability checks in [references/testflight.md]. A successful EAS build or a queued submission does not establish Apple acceptance, tester access, or an App Store release.
+
+## References
+
+Consult these resources as needed:
+
+- ./references/workflows.md -- CI/CD workflows for automated store releases and PR previews
+- ./references/testflight.md -- Submitting iOS builds to TestFlight for beta testing
+- ./references/app-store-metadata.md -- Managing App Store metadata and ASO optimization
+- ./references/play-store.md -- Submitting Android builds to Google Play Store
+- ./references/ios-app-store.md -- iOS App Store submission and review process
+- ./references/native-ios.md -- Native Swift/SwiftUI/UIKit setup, versioning, and archive verification without an Expo runtime
+
+## Expo / React Native Quick Start
+
+### Install EAS CLI
+
+```bash
+npm install -g eas-cli
+eas login
+```
+
+### Initialize EAS
+
+```bash
+npx eas-cli@latest init
+```
+
+`eas init` links or creates the EAS project. Run `eas build:configure` to create build profiles in `eas.json`; preserve existing project and store identifiers when a release setup already exists.
+
+## Build Commands
+
+### Production Builds
+
+```bash
+# iOS App Store build
+npx eas-cli@latest build -p ios --profile production
+
+# Android Play Store build
+npx eas-cli@latest build -p android --profile production
+
+# Both platforms
+npx eas-cli@latest build --profile production
+```
+
+### Submit to Stores
+
+```bash
+# iOS: Build and submit to App Store Connect
+npx eas-cli@latest build -p ios --profile production --auto-submit
+
+# Android: Build and submit to Play Store
+npx eas-cli@latest build -p android --profile production --auto-submit
+
+# Expo / React Native shortcut for iOS TestFlight
+npx testflight
+```
+
+## Web & API Route Hosting
+
+Deploying an Expo website or Expo Router API routes to EAS Hosting (`npx expo export -p web` then `eas deploy`) is covered by the `eas-hosting` skill. This skill focuses on native app store releases.
+
+## EAS Configuration
+
+Example for an Expo / React Native project (native Swift profiles are in `references/native-ios.md`):
+
+```json
+{
+  "cli": {
+    "version": ">= 16.0.1",
+    "appVersionSource": "remote"
+  },
+  "build": {
+    "production": {
+      "autoIncrement": true,
+      "ios": {
+        "resourceClass": "m-medium"
+      }
+    },
+    "development": {
+      "developmentClient": true,
+      "distribution": "internal"
+    }
+  },
+  "submit": {
+    "production": {
+      "ios": {
+        "appleId": "your@email.com",
+        "ascAppId": "1234567890"
+      },
+      "android": {
+        "serviceAccountKeyPath": "./google-service-account.json",
+        "track": "internal"
+      }
+    }
+  }
+}
+```
+
+## Platform-Specific Guides
+
+### iOS
+
+- For native Swift apps, use the explicit build/submit flow in `references/native-ios.md`
+- For Expo / React Native apps, `npx testflight` provides a quick TestFlight flow
+- Configure Apple credentials via `eas credentials`
+- See ./references/testflight.md for credential setup
+- See ./references/ios-app-store.md for App Store submission
+
+### Android
+
+- Set up Google Play Console service account
+- Configure tracks: internal → closed → open → production
+- See ./references/play-store.md for detailed setup
+
+## Automated Releases
+
+EAS Workflows automate the build → submit → update pipeline for CI/CD. See ./references/workflows.md for store-release examples. To author or validate workflow YAML, use the `eas-workflows` skill - it works from the live workflow schema.
+
+## Version Management
+
+EAS manages version numbers automatically with `appVersionSource: "remote"`:
+
+```bash
+# Check current versions
+eas build:version:get
+
+# Manually set version
+eas build:version:set -p ios
+```
+
+The version-set command prompts for the value. When setting up or changing native iOS versioning, or diagnosing a duplicate build number, inspect the archived `CFBundleVersion`: the remote counter alone does not prove that Xcode used it.
+
+## Monitoring
+
+```bash
+# List recent builds
+eas build:list
+
+# Check build status
+eas build:view BUILD_ID
+
+# Inspect submissions (verified with EAS CLI 23.2.0)
+eas submit:list -p ios --json
+eas submit:view SUBMISSION_ID --json
+```
+
+Check the CLI version before interpreting a missing command: these submission commands are available in 23.2.0 but not in the tested 18.6.0 installation. A pinned `npx eas-cli@23.2.0` invocation can use them without changing the global installation. See `references/testflight.md` for live Apple status and retry guidance. Follow the returned log URLs when the JSON result omits the underlying failure. Report the exact build ID/version and the furthest verified release state.
+
+## Submitting Feedback
+If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:
+```bash
+npx --yes submit-expo-feedback@latest --category skills --subject "eas-app-stores" "<actionable feedback>"
+```
+Only submit when you have something specific and actionable to report. Include as much relevant context as possible.
+If an AI agent repeatedly failed or the user had to take over an Expo task, load the expo-skill-feedback skill and follow its eval-candidate flow instead of reusing the command above.
+
+
+## Examples
+
+```text
+User: Apply this skill to my current task.
+Assistant: Follow the workflow in this skill, cite limitations, and ask before risky steps.
+```
+
+## Limitations
+
+- Imported upstream skill; verify credentials, permissions, and safety boundaries before execution.
+- Does not replace environment-specific validation, testing, or maintainer review.

package/bundled-skills/eas-app-stores/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "EAS App Stores"
+  short_description: "Paid EAS service. Build and submit iOS and Android apps."
+  default_prompt: "Use $eas-app-stores to set up or verify EAS builds, TestFlight and store submissions, signing, versioning, and store metadata for iOS and Android apps: Expo and other React Native projects, plus existing native apps."