[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71VBV5K4S53E2N17X5293ZY":3,"skill-same:01M71VBV5K4S53E2N17X5293ZY":76},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":61,"updatedAt":62,"install":63,"resources":75},"01M71VBV5K4S53E2N17X5293ZY","ci-cd-and-automation",null,"Automates CI\u002FCD pipeline setup. 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.","mamahoos\u002Fdot-files","mamahoos","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F62762296?v=4","01M71VB2X9CZAQ28WPHV6VQKCP","01M71VB2Y2BC8YW9F2TWF96WRW",5,"MIT","https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files\u002Fblob\u002Fmain\u002Fhome\u002F.cursor\u002Fskills\u002Fci-cd-and-automation\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"ci cd","automation","ci","ci cd and automation","cd","setting","when","true","you","CI\u002FCD","gates","strategies","deployment strategies","up","use","automate","configure","pipeline","runners","deployment","2026-11-10 13:02:02",false,"---\nname: ci-cd-and-automation\ndescription: Automates CI\u002FCD pipeline setup. 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.\ndisable-model-invocation: true\n---\n\n# CI\u002FCD and Automation\n\n## Overview\n\nAutomate quality gates so that no change reaches production without passing tests, lint, type checking, and build. CI\u002FCD 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\u002Fvitest\n│   ↓ pass         │\n│   BUILD          │  npm run build\n│   ↓ pass         │\n│   INTEGRATION    │  API\u002FDB tests\n│   ↓ pass         │\n│   E2E (optional) │  Playwright\u002FCypress\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\u002Fworkflows\u002Fci.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\u002Fcheckout@v4\n\n      - uses: actions\u002Fsetup-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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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:\u002F\u002Fci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432\u002Ftestdb\n      - name: Integration tests\n        run: npm run test:integration\n        env:\n          DATABASE_URL: postgresql:\u002F\u002Fci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432\u002Ftestdb\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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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\u002Fupload-artifact@v4\n        if: failure()\n        with:\n          name: playwright-report\n          path: playwright-report\u002F\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\u002FNetlify\u002Fetc.)\ndeploy-preview:\n  runs-on: ubuntu-latest\n  if: github.event_name == 'pull_request'\n  steps:\n    - uses: actions\u002Fcheckout@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\u002FB tests.** Compare behavior with and without the feature.\n\n```typescript\n\u002F\u002F 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        env:\n          VERSION: ${{ inputs.version }}\n        run: |\n          # Deploy the specified previous version. Pass the input through env,\n          # never interpolate it into the script (shell injection).\n          npx vercel rollback \"$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 \u002F vault\nProduction secrets  → Stored in deployment platform \u002F vault\n```\n\nCI should never have production secrets. Use separate secrets for CI testing.\n\n## Automation Beyond CI\n\n### Dependabot \u002F Renovate\n\n```yaml\n# .github\u002Fdependabot.yml\nversion: 2\nupdates:\n  - package-ecosystem: npm\n    directory: \u002F\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 the setup-node cache option (or actions\u002Fcache) for the package manager cache, not 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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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","# CI\u002FCD and Automation\n\n## Overview\n\nAutomate quality gates so that no change reaches production without passing tests, lint, type checking, and build. CI\u002FCD 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\u002Fvitest\n│   ↓ pass         │\n│   BUILD          │  npm run build\n│   ↓ pass         │\n│   INTEGRATION    │  API\u002FDB tests\n│   ↓ pass         │\n│   E2E (optional) │  Playwright\u002FCypress\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\u002Fworkflows\u002Fci.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\u002Fcheckout@v4\n\n      - uses: actions\u002Fsetup-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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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:\u002F\u002Fci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432\u002Ftestdb\n      - name: Integration tests\n        run: npm run test:integration\n        env:\n          DATABASE_URL: postgresql:\u002F\u002Fci_user:${{ secrets.CI_DB_PASSWORD }}@localhost:5432\u002Ftestdb\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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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\u002Fupload-artifact@v4\n        if: failure()\n        with:\n          name: playwright-report\n          path: playwright-report\u002F\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\u002FNetlify\u002Fetc.)\ndeploy-preview:\n  runs-on: ubuntu-latest\n  if: github.event_name == 'pull_request'\n  steps:\n    - uses: actions\u002Fcheckout@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\u002FB tests.** Compare behavior with and without the feature.\n\n```typescript\n\u002F\u002F 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        env:\n          VERSION: ${{ inputs.version }}\n        run: |\n          # Deploy the specified previous version. Pass the input through env,\n          # never interpolate it into the script (shell injection).\n          npx vercel rollback \"$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 \u002F vault\nProduction secrets  → Stored in deployment platform \u002F vault\n```\n\nCI should never have production secrets. Use separate secrets for CI testing.\n\n## Automation Beyond CI\n\n### Dependabot \u002F Renovate\n\n```yaml\n# .github\u002Fdependabot.yml\nversion: 2\nupdates:\n  - package-ecosystem: npm\n    directory: \u002F\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 the setup-node cache option (or actions\u002Fcache) for the package manager cache, not 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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-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",{"name":5,"description":7,"disable-model-invocation":54},true,"main","f5079c29c332b831168f6d7571d2598e98fe8e64","home\u002F.cursor\u002Fskills\u002Fci-cd-and-automation",0,"https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files","https:\u002F\u002Fgithub.com\u002Fmamahoos","DevOps \u002F Platform Engineer","2026-11-10 03:01:53",{"source":8,"skillName":5,"commands":64,"prompt":74,"zipAvailable":54},[65,68,71],{"tool":66,"command":67},"npx","npx skills add mamahoos\u002Fdot-files --skill ci-cd-and-automation",{"tool":69,"command":70},"bunx","bunx skills add mamahoos\u002Fdot-files --skill ci-cd-and-automation",{"tool":72,"command":73},"pnpm","pnpm dlx skills add mamahoos\u002Fdot-files --skill ci-cd-and-automation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files\u002Fblob\u002Fmain\u002Fhome\u002F.cursor\u002Fskills\u002Fci-cd-and-automation\u002FSKILL.md",[],[77,110,130,159,182,204],{"skillNo":78,"name":79,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":80,"licenseFileUrl":81,"sourceHtmlUrl":82,"categories":83,"keywords":92,"publishedAt":49},"01M71VCZ7RGA06SS6KY978AZTS","discernment-nudge","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files\u002Fblob\u002Fmain\u002Fhome\u002F.cursor\u002Fskills\u002Fdiscernment-nudge\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files\u002Fblob\u002Fmain\u002Fhome\u002F.cursor\u002Fskills\u002Fdiscernment-nudge\u002FSKILL.md",[84,87],{"categoryNo":85,"categoryName":86,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[93,94,95,96,97,42,98,99,100,35,37,101,102,103,104,105,106,107,108,109],"discernment nudge","nudge","conversation","interpretation","short","only","writing","invoke","analysis","code","review","claims","argument","assemble","how","run","recommendations",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":49},"01M71VCTTZ4V9HGZF6E0HCJW7T","diagnosing-bugs","Diagnosis loop for hard bugs and performance regressions. Use when the user says \"diagnose\"\u002F\"debug this\", or reports something broken\u002Fthrowing\u002Ffailing\u002Fslow.","https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files\u002Fblob\u002Fmain\u002Fhome\u002F.cursor\u002Fskills\u002Fdiagnosing-bugs\u002FSKILL.md",[],[117,118,119,120,121,122,123,36,124,43,125,126,35,127,128,129],"bugs","diagnosing bugs","broken","diagnose","for","performance","failing","regressions","loop","debug","reports","diagnosis","user",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":142,"publishedAt":49},"01M71VCQZJWH05YTPC61MAGRNF","deprecation-and-migration","Manages deprecation and migration. Use when removing old systems, APIs, or features. Use when migrating users from one implementation to another. Use when migrating a database schema in production, such as renaming or dropping a column without downtime (expand\u002Fcontract). Use when deciding whether to maintain or sunset existing code.","https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files\u002Fblob\u002Fmain\u002Fhome\u002F.cursor\u002Fskills\u002Fdeprecation-and-migration\u002FSKILL.md",[136,139],{"categoryNo":137,"categoryName":138,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":140,"categoryName":141,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000037","律师与法务",[143,144,145,146,147,148,149,35,102,150,151,36,152,153,43,154,155,156,157,158],"deprecation","deprecation and migration","migration","expand","database schema","maintain","database","features","as","contract","schema","Existing","one","users","systems","column",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":49},"01M71VCMZA9VYSWXX396XRPP1Z","debugging-and-error-recovery","Guides systematic root-cause debugging. Use when tests fail, builds break, something that worked yesterday broke, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need to figure out what broke and why — a systematic approach to finding and fixing the root cause rather than guessing.","https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files\u002Fblob\u002Fmain\u002Fhome\u002F.cursor\u002Fskills\u002Fdebugging-and-error-recovery\u002FSKILL.md",[],[166,167,168,169,170,35,37,171,172,173,174,175,176,36,177,43,178,179,180,181],"error","error recovery","debugging","debugging and error recovery","recovery","guides","why","break","systematic","encounter","root cause","tests","root-cause","behavior","match","root",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":49},"01M71VCGKVYAEHPKH569NVC8ZB","context-engineering","Optimizes agent context setup. Use when starting a new session, when agent output quality degrades, when switching between tasks, or when you need to configure rules files and context for a project.","https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files\u002Fblob\u002Fmain\u002Fhome\u002F.cursor\u002Fskills\u002Fcontext-engineering\u002FSKILL.md",[188],{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},[190,191,192,193,194,195,196,197,198,35,45,37,199,200,201,121,202,36,43,203],"context","context engineering","engineering","project","context setup","new","files","agent context","switching","tasks","agent context setup","new session","session","Rules",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":208,"categories":209,"keywords":210,"publishedAt":49},"01M71VCARZSNE9Y80192V5FTZK","constraint-driven-development","Establishes a project's quality bar as a written contract and stops agents quietly lowering it. Interviews the user on which dimensions matter, supplies sane default thresholds when they have no number in mind, records everything in CONSTRAINTS.md, and watches the diff for a weakened bar — new @ts-ignore or eslint-disable suppressions, skipped or deleted tests, assertions stripped out, unimplemented stubs, thresholds edited down. Use when no quality bar is written down, when the user says \"set up constraints\" or \"define our standards\", when the user wants dimensions they care about — accessibility, web performance, coverage — set up as enforced constraints, when an agent keeps silencing checks or skipping tests to get to green, when you need a coverage or performance threshold and don't know what number to pick, or when an agent writes more code than anyone will read.","https:\u002F\u002Fgithub.com\u002Fmamahoos\u002Fdot-files\u002Fblob\u002Fmain\u002Fhome\u002F.cursor\u002Fskills\u002Fconstraint-driven-development\u002FSKILL.md",[],[211,212,213,214,215,216,217,218,219,193,122,220,221,42,195,35,222,37,102,223],"development","constraint driven development","constraint","driven","coverage","SET","which","get","green","default","pick","number","dimensions"]