[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6WZ9Z59M0VCZWDQJPCWT1GA":3,"skill-same:01M6WZ9Z59M0VCZWDQJPCWT1GA":81},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":60,"commitSha":61,"skillDirectory":62,"forksCount":14,"repositoryHtmlUrl":63,"repositoryHomepageUrl":64,"ownerHtmlUrl":65,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":66,"install":67,"resources":80},"01M6WZ9Z59M0VCZWDQJPCWT1GA","ci-cd-setup",null,"CI\u002FCD pipeline setup — GitHub Actions, testing, linting, deployment. Use when setting up CI from scratch, adding GitHub Actions, automating tests, wiring up deployment, or improving an existing build pipeline.","projectious-work\u002Fprocesskit","projectious-work","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F263889726?v=4","01M6N97TJJ118WQ35CHRV8RD0E","projectious.work","01M6N97TPWJPF0BMKYQ4PBY5W8",0,"MIT","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fdevops\u002Fci-cd-setup\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"ci cd","setup","ci cd setup","ci","cd","when","testing","scratch","wiring","Existing","v1","From Scratch","tests","up","use","ci-cd","pipeline","github actions","actions","deployment","2026-11-10 10:12:30",false,"---\nname: ci-cd-setup\ndescription: |\n  CI\u002FCD pipeline setup — GitHub Actions, testing, linting, deployment. Use when setting up CI from scratch, adding GitHub Actions, automating tests, wiring up deployment, or improving an existing build pipeline.\nmetadata:\n  processkit:\n    apiVersion: processkit.projectious.work\u002Fv1\n    id: SKILL-ci-cd-setup\n    version: \"1.1.0\"\n    created: 2026-04-06T00:00:00Z\n    category: devops\n---\n\n# CI\u002FCD Setup\n\n## Intro\n\nA good CI pipeline runs the same checks a developer would run locally, in\nthe same order, fast enough that contributors get feedback before they\ncontext-switch. Lint first, then test, then build, then deploy — and never\nlet secrets or unpinned actions sneak in.\n\n## Overview\n\n### Pipeline stages\n\nOrder stages from cheapest to most expensive so failures surface early:\n\n1. **Lint** — format checking and static analysis (fastest feedback)\n2. **Test** — unit tests first, then integration tests\n3. **Build** — compile, package, create release artifacts\n4. **Deploy** — push to staging, then promote to production\n\n### GitHub Actions basics\n\nTrigger on `push` to main and on `pull_request`. Pin action versions\nexplicitly (`actions\u002Fcheckout@v4`, never `@latest`). Cache dependencies\n(pip, npm, cargo) so reruns are fast. Set `timeout-minutes` on every job\nso a hung step cannot eat your minutes budget.\n\n### Testing in CI\n\nRun the same commands as local development — if `make test` works\nlocally, that is what CI should call. Use matrix builds for OS or\nlanguage-version combinations only when you actually need to support\nthem. Use `fail-fast: true` in matrix strategies so one failure cancels\nthe rest.\n\n### Security\n\nNever put secrets in workflow files. Store them in GitHub Secrets and\ninject through `${{ secrets.NAME }}`. Use the `permissions` key on each\njob to limit the `GITHUB_TOKEN` scope to the minimum needed. Pin\nthird-party actions to a commit SHA, not just a version tag, so an\nattacker who compromises a tag cannot inject code into your build.\n\n### Best practices\n\n- Keep PR pipelines under five minutes wherever possible.\n- Make CI failures actionable — clear error messages, surfaced summaries.\n- Require CI to pass before merge via branch protection rules.\n- Run expensive checks (E2E suites, deploys) only on main, not on PRs.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Pinning an action to a tag instead of a commit SHA.** Tags are mutable — an attacker who compromises an action's tag can inject code into your build. Pin third-party actions to their full commit SHA, not just `@v4`.\n- **Secrets leaking into build logs.** Printing or echoing an environment variable that contains a secret exposes it in the CI log. Never `echo ${{ secrets.FOO }}` — pass secrets only through inputs or masked env vars.\n- **Running expensive checks on every PR.** E2E tests and deploy jobs on every pull request slow the pipeline and teach contributors to bypass CI. Gate slow jobs behind `if: github.ref == 'refs\u002Fheads\u002Fmain'` or a label.\n- **No `timeout-minutes` on jobs.** A hung step runs indefinitely and eats your minutes budget. Every job and every slow step needs a timeout — not just the slow ones you expect.\n- **CI passes but local fails (or vice versa).** Environment divergence — OS, timezone, locale, file path casing, implicit tool versions — causes mismatch. Make CI reproduce local conditions explicitly; never assume the runner matches the developer's machine.\n- **One mega-job that lints, tests, builds, and deploys.** Failures are hard to locate, reruns are expensive, and the job cannot parallelize. Split into separate jobs; each job should do one thing.\n- **Branch protection not enforcing required status checks.** If CI is advisory rather than required for merge, it stops being trusted. Configure branch protection to require every status check that matters before merge.\n\n## Full reference\n\n### Sample workflow shape\n\n```yaml\nname: ci\non:\n  push:\n    branches: [main]\n  pull_request:\njobs:\n  lint:\n    runs-on: ubuntu-latest\n    timeout-minutes: 5\n    permissions:\n      contents: read\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-python@v5\n        with:\n          python-version: \"3.12\"\n          cache: pip\n      - run: pip install -e .[dev]\n      - run: ruff check .\n  test:\n    needs: lint\n    runs-on: ubuntu-latest\n    timeout-minutes: 10\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-python@v5\n        with:\n          python-version: \"3.12\"\n          cache: pip\n      - run: pip install -e .[dev]\n      - run: pytest\n```\n\n### Caching tips by ecosystem\n\n| Ecosystem | Cache key target |\n|---|---|\n| Python (pip) | `setup-python` with `cache: pip` and `cache-dependency-path` |\n| Node (npm\u002Fyarn\u002Fpnpm) | `setup-node` with `cache: npm` (or yarn\u002Fpnpm) |\n| Rust (cargo) | `Swatinem\u002Frust-cache` action keyed on `Cargo.lock` |\n| Go | `actions\u002Fsetup-go` with `cache: true` |\n| Docker layers | `docker\u002Fbuild-push-action` with `cache-from`\u002F`cache-to` |\n\n### Anti-patterns\n\n- **`actions\u002Fcheckout@latest`** — pin to a major version or SHA\n- **Putting tokens in `env:` blocks at the top of a workflow** — use job\n  or step scope so secrets are not over-shared\n- **Running E2E tests on every PR** — gate them behind a label or run\n  only on main\n- **Skipping CI with `[skip ci]` to \"save time\"** — fix the slow step\n  instead; once CI is optional, it stops being trusted\n- **One mega-job that lints, tests, builds, deploys** — split into\n  jobs so failures are localized and reruns are cheap\n\n### Branch protection checklist\n\n- Require pull request reviews before merge\n- Require status checks to pass: `lint`, `test`, and any required builds\n- Require branches to be up to date before merging\n- Restrict who can push directly to `main`\n- Require signed commits if your team has the workflow for it\n","# CI\u002FCD Setup\n\n## Intro\n\nA good CI pipeline runs the same checks a developer would run locally, in\nthe same order, fast enough that contributors get feedback before they\ncontext-switch. Lint first, then test, then build, then deploy — and never\nlet secrets or unpinned actions sneak in.\n\n## Overview\n\n### Pipeline stages\n\nOrder stages from cheapest to most expensive so failures surface early:\n\n1. **Lint** — format checking and static analysis (fastest feedback)\n2. **Test** — unit tests first, then integration tests\n3. **Build** — compile, package, create release artifacts\n4. **Deploy** — push to staging, then promote to production\n\n### GitHub Actions basics\n\nTrigger on `push` to main and on `pull_request`. Pin action versions\nexplicitly (`actions\u002Fcheckout@v4`, never `@latest`). Cache dependencies\n(pip, npm, cargo) so reruns are fast. Set `timeout-minutes` on every job\nso a hung step cannot eat your minutes budget.\n\n### Testing in CI\n\nRun the same commands as local development — if `make test` works\nlocally, that is what CI should call. Use matrix builds for OS or\nlanguage-version combinations only when you actually need to support\nthem. Use `fail-fast: true` in matrix strategies so one failure cancels\nthe rest.\n\n### Security\n\nNever put secrets in workflow files. Store them in GitHub Secrets and\ninject through `${{ secrets.NAME }}`. Use the `permissions` key on each\njob to limit the `GITHUB_TOKEN` scope to the minimum needed. Pin\nthird-party actions to a commit SHA, not just a version tag, so an\nattacker who compromises a tag cannot inject code into your build.\n\n### Best practices\n\n- Keep PR pipelines under five minutes wherever possible.\n- Make CI failures actionable — clear error messages, surfaced summaries.\n- Require CI to pass before merge via branch protection rules.\n- Run expensive checks (E2E suites, deploys) only on main, not on PRs.\n\n## Gotchas\n\nAgent-specific failure modes — provider-neutral pause-and-self-check items:\n\n- **Pinning an action to a tag instead of a commit SHA.** Tags are mutable — an attacker who compromises an action's tag can inject code into your build. Pin third-party actions to their full commit SHA, not just `@v4`.\n- **Secrets leaking into build logs.** Printing or echoing an environment variable that contains a secret exposes it in the CI log. Never `echo ${{ secrets.FOO }}` — pass secrets only through inputs or masked env vars.\n- **Running expensive checks on every PR.** E2E tests and deploy jobs on every pull request slow the pipeline and teach contributors to bypass CI. Gate slow jobs behind `if: github.ref == 'refs\u002Fheads\u002Fmain'` or a label.\n- **No `timeout-minutes` on jobs.** A hung step runs indefinitely and eats your minutes budget. Every job and every slow step needs a timeout — not just the slow ones you expect.\n- **CI passes but local fails (or vice versa).** Environment divergence — OS, timezone, locale, file path casing, implicit tool versions — causes mismatch. Make CI reproduce local conditions explicitly; never assume the runner matches the developer's machine.\n- **One mega-job that lints, tests, builds, and deploys.** Failures are hard to locate, reruns are expensive, and the job cannot parallelize. Split into separate jobs; each job should do one thing.\n- **Branch protection not enforcing required status checks.** If CI is advisory rather than required for merge, it stops being trusted. Configure branch protection to require every status check that matters before merge.\n\n## Full reference\n\n### Sample workflow shape\n\n```yaml\nname: ci\non:\n  push:\n    branches: [main]\n  pull_request:\njobs:\n  lint:\n    runs-on: ubuntu-latest\n    timeout-minutes: 5\n    permissions:\n      contents: read\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-python@v5\n        with:\n          python-version: \"3.12\"\n          cache: pip\n      - run: pip install -e .[dev]\n      - run: ruff check .\n  test:\n    needs: lint\n    runs-on: ubuntu-latest\n    timeout-minutes: 10\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-python@v5\n        with:\n          python-version: \"3.12\"\n          cache: pip\n      - run: pip install -e .[dev]\n      - run: pytest\n```\n\n### Caching tips by ecosystem\n\n| Ecosystem | Cache key target |\n|---|---|\n| Python (pip) | `setup-python` with `cache: pip` and `cache-dependency-path` |\n| Node (npm\u002Fyarn\u002Fpnpm) | `setup-node` with `cache: npm` (or yarn\u002Fpnpm) |\n| Rust (cargo) | `Swatinem\u002Frust-cache` action keyed on `Cargo.lock` |\n| Go | `actions\u002Fsetup-go` with `cache: true` |\n| Docker layers | `docker\u002Fbuild-push-action` with `cache-from`\u002F`cache-to` |\n\n### Anti-patterns\n\n- **`actions\u002Fcheckout@latest`** — pin to a major version or SHA\n- **Putting tokens in `env:` blocks at the top of a workflow** — use job\n  or step scope so secrets are not over-shared\n- **Running E2E tests on every PR** — gate them behind a label or run\n  only on main\n- **Skipping CI with `[skip ci]` to \"save time\"** — fix the slow step\n  instead; once CI is optional, it stops being trusted\n- **One mega-job that lints, tests, builds, deploys** — split into\n  jobs so failures are localized and reruns are cheap\n\n### Branch protection checklist\n\n- Require pull request reviews before merge\n- Require status checks to pass: `lint`, `test`, and any required builds\n- Require branches to be up to date before merging\n- Restrict who can push directly to `main`\n- Require signed commits if your team has the workflow for it\n",{"name":5,"metadata":52,"description":59},{"processkit":53},{"id":54,"created":55,"version":56,"category":57,"apiVersion":58},"SKILL-ci-cd-setup",1775433600000,"1.1.0","devops","processkit.projectious.work\u002Fv1","CI\u002FCD pipeline setup — GitHub Actions, testing, linting, deployment. Use when setting up CI from scratch, adding GitHub Actions, automating tests, wiring up deployment, or improving an existing build pipeline.\n","main","4876a92620ee792aac2ac9a1a806322d8a572367","archive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fdevops\u002Fci-cd-setup","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit","https:\u002F\u002Fprojectious-work.github.io\u002Fprocesskit\u002F","https:\u002F\u002Fgithub.com\u002Fprojectious-work","2026-11-09 00:53:29",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add projectious-work\u002Fprocesskit --skill ci-cd-setup",{"tool":73,"command":74},"bunx","bunx skills add projectious-work\u002Fprocesskit --skill ci-cd-setup",{"tool":76,"command":77},"pnpm","pnpm dlx skills add projectious-work\u002Fprocesskit --skill ci-cd-setup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Farchive\u002Fprocesskit-install-20261101\u002Fcontext\u002Ftemplates\u002Fprocesskit\u002Fv0.18.1\u002Fcontext\u002Fskills\u002Fdevops\u002Fci-cd-setup\u002FSKILL.md",true,[],[82,107,127,148,165,183],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":91,"publishedAt":47},"01M6X5MTC89B4ZGXW3JVSQCPF8","skill-management","Manage Skill package manifests as v1 ontology entities.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fskill-management\u002FSKILL.md",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[92,93,94,95,96,97,98,99,100,101,84,102,103,104,37,105,106],"management","skill management","create","update","package","alpha","work","list","manage","ontology","get","as","manifests","skill package","transition",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":114,"publishedAt":47},"01M6X5MCV74NHW5MEDNHZRF2C8","schema-management","Manage generated processkit schema contracts through deterministic MCP rebuild and inspection workflows.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fschema-management\u002FSKILL.md",[113],{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},[92,115,116,117,118,119,97,98,120,121,100,122,123,124,102,125,126],"schema","schema management","MCP","workflows","validation","generated","rebuild","contracts","wed","deterministic","contract","mode",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":47},"01M6X5M5G6YJ96AMZGSCZJ1D13","proposition-management","Record claims, risks, beliefs, world facts, WSJF estimates, and assumptions through the Proposition interface.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fproposition-management\u002FSKILL.md",[],[92,134,135,94,95,136,97,98,137,138,139,140,102,141,142,143,144,145,146,147],"proposition","proposition management","index","log","world","record","query","creation","event","interface","updates","facts","claims","WSJF",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":47},"01M6X5KMQ83QN9M6MPWZM7344F","ontology-management","Manage generated v1 ontology entities that do not require a dedicated domain server.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fontology-management\u002FSKILL.md",[],[92,101,155,94,97,156,157,120,158,137,100,159,160,102,161,162,142,163,37,164],"ontology management","lifecycle","archive","roadmap","do","domain","iteration","keep","measurement","generic",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":47},"01M6X5KCY2DN3SM21RERSFNEBT","okf-compatibility","Import, export, and validate conformant Open Knowledge Format bundles.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fokf-compatibility\u002FSKILL.md",[],[172,173,174,175,97,176,177,178,98,179,180,181,182],"okf","compatibility","okf compatibility","validate","open","knowledge","format","export","bundles","bundle","import",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":47},"01M6X5JA8S5PNGJVFW4EQY8T83","capability-management","Manage versioned Capability entities and their governed lifecycle.","https:\u002F\u002Fgithub.com\u002Fprojectious-work\u002Fprocesskit\u002Fblob\u002Fmain\u002Fsrc\u002Fcontext\u002Fskills\u002Fprocesskit\u002Fcapability-management\u002FSKILL.md",[],[92,190,191,94,95,136,97,156,98,99,137,192,100,139,102,162,142,143,193,106],"capability","capability management","queries","changes"]