Update to Agent Skills

{
  "name": "ci-cd-and-automation",
  "description": "Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates, configure test runners in CI, or establish deployment strategies.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 231
    }
  ],
  "skill_md_contents": "---\nname: ci-cd-and-automation\ndescription: Use when setting up or modifying build and deployment pipelines. Use when you need to automate quality gates,\n  configure test runners in CI, or establish deployment strategies.\n---\n\n# CI/CD and Automation\n\n## Overview\n\nAutomate quality gates so that no change reaches production without passing tests, lint, type checking, and build. CI/CD is the enforcement mechanism for every other skill — it catches what humans and agents miss, and it does so consistently on every single change.\n\n**Shift Left:** Catch problems as early in the pipeline as possible. A bug caught in linting costs minutes; the same bug caught in production costs hours. Move checks upstream — static analysis before tests, tests before staging, staging before production.\n\n**Faster is Safer:** Smaller batches and more frequent releases reduce risk, not increase it. A deployment with 3 changes is easier to debug than one with 30. Frequent releases build confidence in the release process itself.\n\n## When to Use\n\n- Setting up a new project's CI pipeline\n- Adding or modifying automated checks\n- Configuring deployment pipelines\n- When a change should trigger automated verification\n- Debugging CI failures\n\n## The Quality Gate Pipeline\n\nEvery change goes through these gates before merge:\n\n```\nPull Request Opened\n    │\n    ▼\n┌─────────────────┐\n│   LINT CHECK     │  eslint, prettier\n│   ↓ pass         │\n│   TYPE CHECK     │  tsc --noEmit\n│   ↓ pass         │\n│   UNIT TESTS     │  jest/vitest\n│   ↓ pass         │\n│   BUILD          │  npm run build\n│   ↓ pass         │\n│   INTEGRATION    │  API/DB tests\n│   ↓ pass         │\n│   E2E (optional) │  Playwright/Cypress\n│   ↓ pass         │\n│   SECURITY AUDIT │  npm audit\n│   ↓ pass         │\n│   BUNDLE SIZE    │  bundlesize check\n└─────────────────┘\n    │\n    ▼\n  Ready for review\n```\n\n**No gate can be skipped.** If lint fails, fix lint — don't disable the rule. If a test fails, fix the code — don't skip the test.\n\n## GitHub Actions Configuration\n\n### Basic CI Pipeline\n\n```yaml\n# .github/workflows/ci.yml\nname: CI\n\non:\n  pull_request:\n    branches: [main]\n  push:\n    branches: [main]\n\njobs:\n  quality:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '22'\n          cache: 'npm'\n\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Lint\n        run: npm run lint\n\n      - name: Type check\n        run: npx tsc --noEmit\n\n      - name: Test\n        run: npm test -- --coverage\n\n      - name: Build\n        run: npm run build\n\n      - name: Security audit\n        run: npm audit --audit-level=high\n```\n\n### With Database Integration Tests\n\n```yaml\n  integration:\n    runs-on: ubuntu-latest\n    services:\n      postgres:\n        image: postgres:16\n        env:\n          POSTGRES_DB: testdb\n          POSTGRES_USER: ci_user\n          POSTGRES_PASSWORD: ${{ secrets.CI_DB_PASSWORD }}\n        ports:\n          - 5432:5432\n        options: >-\n          --health-cmd pg_isready\n          --health-interval 10s\n          --health-timeout 5s\n          --health-retries 5\n\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '22'\n          cache: 'npm'\n      - run: npm ci\n      - name: Run migrations\n        run: npx prisma migrate deploy\n        env:\n          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb\n      - name: Integration tests\n        run: npm run test:integration\n        env:\n          DATABASE_URL: postgresql://ci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432/testdb\n```\n\n> **Note:** Even for CI-only test databases, use GitHub Secrets for credentials rather than hardcoding values. This builds good habits and prevents accidental reuse of test credentials in other contexts.\n\n### E2E Tests\n\n```yaml\n  e2e:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '22'\n          cache: 'npm'\n      - run: npm ci\n      - name: Install Playwright\n        run: npx playwright install --with-deps chromium\n      - name: Build\n        run: npm run build\n      - name: Run E2E tests\n        run: npx playwright test\n      - uses: actions/upload-artifact@v4\n        if: failure()\n        with:\n          name: playwright-report\n          path: playwright-report/\n```\n\n## Feeding CI Failures Back to Agents\n\nThe power of CI with AI agents is the feedback loop. When CI fails:\n\n```\nCI fails\n    │\n    ▼\nCopy the failure output\n    │\n    ▼\nFeed it to the agent:\n\"The CI pipeline failed with this error:\n[paste specific error]\nFix the issue and verify locally before pushing again.\"\n    │\n    ▼\nAgent fixes → pushes → CI runs again\n```\n\n**Key patterns:**\n\n```\nLint failure → Agent runs `npm run lint --fix` and commits\nType error  → Agent reads the error location and fixes the type\nTest failure → Agent follows debugging-and-error-recovery skill\nBuild error → Agent checks config and dependencies\n```\n\n## Deployment Strategies\n\n### Preview Deployments\n\nEvery PR gets a preview deployment for manual testing:\n\n```yaml\n# Deploy preview on PR (Vercel/Netlify/etc.)\ndeploy-preview:\n  runs-on: ubuntu-latest\n  if: github.event_name == 'pull_request'\n  steps:\n    - uses: actions/checkout@v4\n    - name: Deploy preview\n      run: npx vercel --token=${{ secrets.VERCEL_TOKEN }}\n```\n\n### Feature Flags\n\nFeature flags decouple deployment from release. Deploy incomplete or risky features behind flags so you can:\n\n- **Ship code without enabling it.** Merge to main early, enable when ready.\n- **Roll back without redeploying.** Disable the flag instead of reverting code.\n- **Canary new features.** Enable for 1% of users, then 10%, then 100%.\n- **Run A/B tests.** Compare behavior with and without the feature.\n\n```typescript\n// Simple feature flag pattern\nif (featureFlags.isEnabled('new-checkout-flow', { userId })) {\n  return renderNewCheckout();\n}\nreturn renderLegacyCheckout();\n```\n\n**Flag lifecycle:** Create → Enable for testing → Canary → Full rollout → Remove the flag and dead code. Flags that live forever become technical debt — set a cleanup date when you create them.\n\n### Staged Rollouts\n\n```\nPR merged to main\n    │\n    ▼\n  Staging deployment (auto)\n    │ Manual verification\n    ▼\n  Production deployment (manual trigger or auto after staging)\n    │\n    ▼\n  Monitor for errors (15-minute window)\n    │\n    ├── Errors detected → Rollback\n    └── Clean → Done\n```\n\n### Rollback Plan\n\nEvery deployment should be reversible:\n\n```yaml\n# Manual rollback workflow\nname: Rollback\non:\n  workflow_dispatch:\n    inputs:\n      version:\n        description: 'Version to rollback to'\n        required: true\n\njobs:\n  rollback:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Rollback deployment\n        run: |\n          # Deploy the specified previous version\n          npx vercel rollback ${{ inputs.version }}\n```\n\n## Environment Management\n\n```\n.env.example       → Committed (template for developers)\n.env                → NOT committed (local development)\n.env.test           → Committed (test environment, no real secrets)\nCI secrets          → Stored in GitHub Secrets / vault\nProduction secrets  → Stored in deployment platform / vault\n```\n\nCI should never have production secrets. Use separate secrets for CI testing.\n\n## Automation Beyond CI\n\n### Dependabot / Renovate\n\n```yaml\n# .github/dependabot.yml\nversion: 2\nupdates:\n  - package-ecosystem: npm\n    directory: /\n    schedule:\n      interval: weekly\n    open-pull-requests-limit: 5\n```\n\n### Build Cop Role\n\nDesignate someone responsible for keeping CI green. When the build breaks, the Build Cop's job is to fix or revert — not the person whose change caused the break. This prevents broken builds from accumulating while everyone assumes someone else will fix it.\n\n### PR Checks\n\n- **Required reviews:** At least 1 approval before merge\n- **Required status checks:** CI must pass before merge\n- **Branch protection:** No force-pushes to main\n- **Auto-merge:** If all checks pass and approved, merge automatically\n\n## CI Optimization\n\nWhen the pipeline exceeds 10 minutes, apply these strategies in order of impact:\n\n```\nSlow CI pipeline?\n├── Cache dependencies\n│   └── Use actions/cache or setup-node cache option for node_modules\n├── Run jobs in parallel\n│   └── Split lint, typecheck, test, build into separate parallel jobs\n├── Only run what changed\n│   └── Use path filters to skip unrelated jobs (e.g., skip e2e for docs-only PRs)\n├── Use matrix builds\n│   └── Shard test suites across multiple runners\n├── Optimize the test suite\n│   └── Remove slow tests from the critical path, run them on a schedule instead\n└── Use larger runners\n    └── GitHub-hosted larger runners or self-hosted for CPU-heavy builds\n```\n\n**Example: caching and parallelism**\n```yaml\njobs:\n  lint:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with: { node-version: '22', cache: 'npm' }\n      - run: npm ci\n      - run: npm run lint\n\n  typecheck:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with: { node-version: '22', cache: 'npm' }\n      - run: npm ci\n      - run: npx tsc --noEmit\n\n  test:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v4\n      - uses: actions/setup-node@v4\n        with: { node-version: '22', cache: 'npm' }\n      - run: npm ci\n      - run: npm test -- --coverage\n```\n\n## Common Rationalizations\n\n| Rationalization | Reality |\n|---|---|\n| \"CI is too slow\" | Optimize the pipeline (see CI Optimization below), don't skip it. A 5-minute pipeline prevents hours of debugging. |\n| \"This change is trivial, skip CI\" | Trivial changes break builds. CI is fast for trivial changes anyway. |\n| \"The test is flaky, just re-run\" | Flaky tests mask real bugs and waste everyone's time. Fix the flakiness. |\n| \"We'll add CI later\" | Projects without CI accumulate broken states. Set it up on day one. |\n| \"Manual testing is enough\" | Manual testing doesn't scale and isn't repeatable. Automate what you can. |\n\n## Red Flags\n\n- No CI pipeline in the project\n- CI failures ignored or silenced\n- Tests disabled in CI to make the pipeline pass\n- Production deploys without staging verification\n- No rollback mechanism\n- Secrets stored in code or CI config files (not secrets manager)\n- Long CI times with no optimization effort\n\n## Verification\n\nAfter setting up or modifying CI:\n\n- [ ] All quality gates are present (lint, types, tests, build, audit)\n- [ ] Pipeline runs on every PR and push to main\n- [ ] Failures block merge (branch protection configured)\n- [ ] CI results feed back into the development loop\n- [ ] Secrets are stored in the secrets manager, not in code\n- [ ] Deployment has a rollback mechanism\n- [ ] Pipeline runs in under 10 minutes for the test suite\n"
}