[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73FYQAFS00AC66ZKEE76N58":3,"skill-same:01M73FYQAFS00AC66ZKEE76N58":54},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":35,"ownerHtmlUrl":36,"ownerBlogUrl":37,"ownerDescription":38,"updatedAt":39,"install":40,"resources":53},"01M73FYQAFS00AC66ZKEE76N58","cicd-setup",null,"When the user needs to set up or improve CI\u002FCD pipelines — GitHub Actions, GitLab CI, deployment automation, or says \"set up CI\", \"automate deployment\", \"add tests to pipeline\", \"fix my build\".","Horonomos-laps\u002FYana-AI","Horonomos-laps","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F355299122?v=4","01M76B3QPXE88ET2SQPDPVATZT"," Horonomos-laps","01M72ZQRJPCYPSSWT4D00VJR2A",13,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fstartup--cicd-setup\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: cicd-setup\ndescription: When the user needs to set up or improve CI\u002FCD pipelines — GitHub Actions, GitLab CI, deployment automation, or says \"set up CI\", \"automate deployment\", \"add tests to pipeline\", \"fix my build\".\nrelated: [code-review, security-review]\nreads: [startup-context]\norigin: \"startup\"\n---\n\n# CI\u002FCD Setup\n\n## When to Use\n\n- Setting up CI for a new project from scratch\n- Replacing unreliable copied pipeline configurations that do not match the actual stack\n- Transitioning between GitHub Actions and GitLab CI platforms\n- Reviewing whether pipeline stages align with actual project tooling\n- Optimizing slow builds (caching, parallelism, conditional steps)\n- Establishing a stable CI foundation before adding specialized hardening\n\n## Context Required\n\nFrom `startup-context`: tech stack, deployment target, team size. Also detect or ask:\n- Language and framework (auto-detect from repo files before asking)\n- Deployment target (Vercel, AWS, GCP, Fly.io, etc.)\n- CI\u002FCD platform (default: GitHub Actions; also supports GitLab CI)\n- Environments (dev, staging, production) and existing test coverage\n- Secrets and credentials needed for build or deploy\n\n## Workflow\n\n1. **Detect stack from repo signals** — Scan for lockfiles (package-lock.json, yarn.lock, poetry.lock, go.sum, Cargo.lock), language manifests (package.json, pyproject.toml, go.mod), and script definitions (test, lint, build commands). Lockfiles indicate package manager choice. Absent scripts trigger conservative defaults. Never assume Node for a Python project.\n2. **Choose pipeline stages** — Start with a dependable baseline: checkout, runtime setup, dependency install with caching, then sequential lint, test, build. Only add complexity after the baseline works.\n3. **Generate pipeline config** — Write CI config for the detected platform. Output machine-readable YAML with correct caching strategy for the detected package manager. Verify all referenced commands actually exist in the project.\n4. **Configure secrets** — List required secrets and how to add them. Use platform-managed secret stores. Recommend OIDC for cloud auth over long-lived keys. Never hardcode credentials in YAML.\n5. **Add deployment stages safely** — Begin CI-only (lint\u002Ftest\u002Fbuild). Add staging deployment with explicit environment info. Add production deployment with manual approval. Maintain transparency in rollout and rollback procedures.\n6. **Validate before merge** — Confirm generated YAML is syntactically valid, all commands exist in the project, caching aligns with the package manager, and branch protections match organizational requirements.\n7. **Deliver config and instructions** — Full config file plus setup steps.\n\n## Output Format\n\n```markdown\n# CI\u002FCD Pipeline: [Project Name]\n## Stack Detection Results — detected language, runtime, tools, and build commands\n## Pipeline Overview — Mermaid flowchart showing stages\n## Pipeline Configuration — Full YAML config file\n## Secrets Required — table: name, where to get, how to add\n## Setup Instructions — step-by-step to activate\n## Validation Checklist — commands verified, caching confirmed, branch rules set\n## Optimization Notes — caching strategy, estimated build time\n```\n\n## Frameworks & Best Practices\n\n### Detection-First Pipeline Generation\n\nAlways detect before generating. The detector relies on concrete file signals:\n- Lockfiles indicate package manager choice (npm, yarn, pip, cargo, go modules)\n- Language manifests identify runtime families\n- Script definitions in package.json\u002Fpyproject.toml inform lint\u002Ftest\u002Fbuild commands\n- Absent scripts trigger conservative default commands rather than assumptions\n\n### Caching Strategies by Ecosystem\n\n| Ecosystem | Cache Path | Cache Key |\n|-----------|-----------|-----------|\n| Node.js | `~\u002F.npm` or `node_modules` | `hashFiles('**\u002Fpackage-lock.json')` |\n| Python | `~\u002F.cache\u002Fpip` | `hashFiles('**\u002Frequirements*.txt')` |\n| Go | `~\u002Fgo\u002Fpkg\u002Fmod` | `hashFiles('**\u002Fgo.sum')` |\n| Rust | `~\u002F.cargo\u002Fregistry`, `target\u002F` | `hashFiles('**\u002FCargo.lock')` |\n| Ruby | `vendor\u002Fbundle` | `hashFiles('**\u002FGemfile.lock')` |\n\n### Pipeline Architecture Principles\n\n- **Lint first** — fail early before expensive test runs\n- **Sequential baseline** — checkout, install, lint, test, build, then artifact publish\n- **Cache aggressively** — cuts 30-60% off build times\n- **Pin action versions** — use SHA hashes, not tags, for supply chain security\n- **Set timeouts** (`timeout-minutes: 15`) and **concurrency** to cancel redundant runs\n- **One enhancement at a time** — do not add matrix builds, security scanning, and deployment in one PR\n\n### Environment Strategy\n\n| Environment | Trigger | Approval | Purpose |\n|-------------|---------|----------|---------|\n| **CI** | Every push\u002FPR | None | Run lint + tests |\n| **Staging** | Merge to `main` | None (auto) | Integration testing, QA |\n| **Production** | Git tag or manual | Required | Live users |\n\n### Common Pitfalls\n\n1. Applying Node-specific pipelines to Python or Go repos (detect first)\n2. Enabling deployment before establishing reliable test coverage\n3. Overlooking dependency caching configuration\n4. Running full matrix builds on minor branch updates (use path filters)\n5. Omitting branch protections on production deployments\n6. Embedding credentials directly in pipeline YAML\n\n### Scaling & Platform Notes\n\n- Split long-running jobs when execution exceeds 10 minutes\n- Implement test matrices only when genuine compatibility concerns exist\n- GitHub Actions for GitHub ecosystem; GitLab CI for self-hosted SCM+CI\n- Maintain a single canonical pipeline source per repository\n\n## Related Skills\n\n- `code-review` — chain to review the CI config itself before committing\n- `security-review` — chain to add or audit security scanning stages (trivy, semgrep, npm audit)\n\n## Examples\n\n**Example prompt:** \"Set up CI\u002FCD for my Next.js app deployed on Vercel.\"\n\n**Good output snippet:**\n```yaml\nname: CI\non:\n  push: { branches: [main] }\n  pull_request: { branches: [main] }\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\njobs:\n  lint:\n    runs-on: ubuntu-latest\n    timeout-minutes: 10\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: 20, cache: 'npm' }\n      - run: npm ci\n      - run: npm run lint && npx tsc --noEmit\n  test:\n    runs-on: ubuntu-latest\n    timeout-minutes: 15\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: 20, cache: 'npm' }\n      - run: npm ci && npm test -- --coverage\n```\n\n**Example prompt:** \"My Python CI takes 8 minutes, how do I speed it up?\"\n\n**Good output snippet:**\n```\nStack detection shows: Python 3.11, pytest, pip. Three fixes to cut to ~3 minutes:\n(1) Add pip caching keyed on hashFiles('requirements*.txt'),\n(2) split unit\u002Fintegration tests into parallel jobs,\n(3) add path filters to skip CI on docs-only changes.\n```\n","# CI\u002FCD Setup\n\n## When to Use\n\n- Setting up CI for a new project from scratch\n- Replacing unreliable copied pipeline configurations that do not match the actual stack\n- Transitioning between GitHub Actions and GitLab CI platforms\n- Reviewing whether pipeline stages align with actual project tooling\n- Optimizing slow builds (caching, parallelism, conditional steps)\n- Establishing a stable CI foundation before adding specialized hardening\n\n## Context Required\n\nFrom `startup-context`: tech stack, deployment target, team size. Also detect or ask:\n- Language and framework (auto-detect from repo files before asking)\n- Deployment target (Vercel, AWS, GCP, Fly.io, etc.)\n- CI\u002FCD platform (default: GitHub Actions; also supports GitLab CI)\n- Environments (dev, staging, production) and existing test coverage\n- Secrets and credentials needed for build or deploy\n\n## Workflow\n\n1. **Detect stack from repo signals** — Scan for lockfiles (package-lock.json, yarn.lock, poetry.lock, go.sum, Cargo.lock), language manifests (package.json, pyproject.toml, go.mod), and script definitions (test, lint, build commands). Lockfiles indicate package manager choice. Absent scripts trigger conservative defaults. Never assume Node for a Python project.\n2. **Choose pipeline stages** — Start with a dependable baseline: checkout, runtime setup, dependency install with caching, then sequential lint, test, build. Only add complexity after the baseline works.\n3. **Generate pipeline config** — Write CI config for the detected platform. Output machine-readable YAML with correct caching strategy for the detected package manager. Verify all referenced commands actually exist in the project.\n4. **Configure secrets** — List required secrets and how to add them. Use platform-managed secret stores. Recommend OIDC for cloud auth over long-lived keys. Never hardcode credentials in YAML.\n5. **Add deployment stages safely** — Begin CI-only (lint\u002Ftest\u002Fbuild). Add staging deployment with explicit environment info. Add production deployment with manual approval. Maintain transparency in rollout and rollback procedures.\n6. **Validate before merge** — Confirm generated YAML is syntactically valid, all commands exist in the project, caching aligns with the package manager, and branch protections match organizational requirements.\n7. **Deliver config and instructions** — Full config file plus setup steps.\n\n## Output Format\n\n```markdown\n# CI\u002FCD Pipeline: [Project Name]\n## Stack Detection Results — detected language, runtime, tools, and build commands\n## Pipeline Overview — Mermaid flowchart showing stages\n## Pipeline Configuration — Full YAML config file\n## Secrets Required — table: name, where to get, how to add\n## Setup Instructions — step-by-step to activate\n## Validation Checklist — commands verified, caching confirmed, branch rules set\n## Optimization Notes — caching strategy, estimated build time\n```\n\n## Frameworks & Best Practices\n\n### Detection-First Pipeline Generation\n\nAlways detect before generating. The detector relies on concrete file signals:\n- Lockfiles indicate package manager choice (npm, yarn, pip, cargo, go modules)\n- Language manifests identify runtime families\n- Script definitions in package.json\u002Fpyproject.toml inform lint\u002Ftest\u002Fbuild commands\n- Absent scripts trigger conservative default commands rather than assumptions\n\n### Caching Strategies by Ecosystem\n\n| Ecosystem | Cache Path | Cache Key |\n|-----------|-----------|-----------|\n| Node.js | `~\u002F.npm` or `node_modules` | `hashFiles('**\u002Fpackage-lock.json')` |\n| Python | `~\u002F.cache\u002Fpip` | `hashFiles('**\u002Frequirements*.txt')` |\n| Go | `~\u002Fgo\u002Fpkg\u002Fmod` | `hashFiles('**\u002Fgo.sum')` |\n| Rust | `~\u002F.cargo\u002Fregistry`, `target\u002F` | `hashFiles('**\u002FCargo.lock')` |\n| Ruby | `vendor\u002Fbundle` | `hashFiles('**\u002FGemfile.lock')` |\n\n### Pipeline Architecture Principles\n\n- **Lint first** — fail early before expensive test runs\n- **Sequential baseline** — checkout, install, lint, test, build, then artifact publish\n- **Cache aggressively** — cuts 30-60% off build times\n- **Pin action versions** — use SHA hashes, not tags, for supply chain security\n- **Set timeouts** (`timeout-minutes: 15`) and **concurrency** to cancel redundant runs\n- **One enhancement at a time** — do not add matrix builds, security scanning, and deployment in one PR\n\n### Environment Strategy\n\n| Environment | Trigger | Approval | Purpose |\n|-------------|---------|----------|---------|\n| **CI** | Every push\u002FPR | None | Run lint + tests |\n| **Staging** | Merge to `main` | None (auto) | Integration testing, QA |\n| **Production** | Git tag or manual | Required | Live users |\n\n### Common Pitfalls\n\n1. Applying Node-specific pipelines to Python or Go repos (detect first)\n2. Enabling deployment before establishing reliable test coverage\n3. Overlooking dependency caching configuration\n4. Running full matrix builds on minor branch updates (use path filters)\n5. Omitting branch protections on production deployments\n6. Embedding credentials directly in pipeline YAML\n\n### Scaling & Platform Notes\n\n- Split long-running jobs when execution exceeds 10 minutes\n- Implement test matrices only when genuine compatibility concerns exist\n- GitHub Actions for GitHub ecosystem; GitLab CI for self-hosted SCM+CI\n- Maintain a single canonical pipeline source per repository\n\n## Related Skills\n\n- `code-review` — chain to review the CI config itself before committing\n- `security-review` — chain to add or audit security scanning stages (trivy, semgrep, npm audit)\n\n## Examples\n\n**Example prompt:** \"Set up CI\u002FCD for my Next.js app deployed on Vercel.\"\n\n**Good output snippet:**\n```yaml\nname: CI\non:\n  push: { branches: [main] }\n  pull_request: { branches: [main] }\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\njobs:\n  lint:\n    runs-on: ubuntu-latest\n    timeout-minutes: 10\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: 20, cache: 'npm' }\n      - run: npm ci\n      - run: npm run lint && npx tsc --noEmit\n  test:\n    runs-on: ubuntu-latest\n    timeout-minutes: 15\n    steps:\n      - uses: actions\u002Fcheckout@v4\n      - uses: actions\u002Fsetup-node@v4\n        with: { node-version: 20, cache: 'npm' }\n      - run: npm ci && npm test -- --coverage\n```\n\n**Example prompt:** \"My Python CI takes 8 minutes, how do I speed it up?\"\n\n**Good output snippet:**\n```\nStack detection shows: Python 3.11, pytest, pip. Three fixes to cut to ~3 minutes:\n(1) Add pip caching keyed on hashFiles('requirements*.txt'),\n(2) split unit\u002Fintegration tests into parallel jobs,\n(3) add path filters to skip CI on docs-only changes.\n```\n",{"name":5,"reads":24,"origin":26,"related":27,"description":7},[25],"startup-context","startup",[28,29],"code-review","security-review","main","481dcd7dd2e288b9d627a2bd017db70e64e6c6fa","core\u002Fskills\u002Fstartup--cicd-setup",2,"https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI","https:\u002F\u002Fyana.vutam.link\u002F","https:\u002F\u002Fgithub.com\u002FHoronomos-laps","https:\u002F\u002Fyana.vutam.link","An open-source governed runtime & execution environment for multi-agent AI systems.","2026-11-14 13:24:09",{"source":8,"skillName":5,"commands":41,"prompt":51,"zipAvailable":52},[42,45,48],{"tool":43,"command":44},"npx","npx skills add Horonomos-laps\u002FYana-AI --skill cicd-setup",{"tool":46,"command":47},"bunx","bunx skills add Horonomos-laps\u002FYana-AI --skill cicd-setup",{"tool":49,"command":50},"pnpm","pnpm dlx skills add Horonomos-laps\u002FYana-AI --skill cicd-setup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fstartup--cicd-setup\u002FSKILL.md",true,[],[55,63,70,78,86,94],{"skillNo":56,"name":57,"nameZh":6,"description":58,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":59,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":19},"01M735GKET5YVYKAY62W2P5YXB","openai--sentry--sentry","Use when the user asks to inspect Sentry issues or events, summarize recent production errors, or pull basic Sentry health data via the Sentry API; perform read-only queries with the bundled script and require `SENTRY_AUTH_TOKEN`.","MIT","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fopenai--sentry--sentry\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M73DCAP83T17HY7SMGK7MGFE","ito-basket-compare","Compare Itô prediction-market baskets against a user's knowledge base, portfolio notes, financial context, watchlist, or research thesis. Use for read-only basket comparison and gap analysis without investment advice or live trading.","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fito-basket-compare\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":74,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M734CYEMZFDR3KH6SW0JP8TD","implementing-network-traffic-baselining","Build network traffic baselines from NetFlow\u002FIPFIX data using Python pandas for statistical analysis, z-score anomaly detection, and hourly\u002Fdaily traffic pattern profiling","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-network-traffic-baselining\u002FSKILL.md",[],[],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":82,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":19},"01M73ASZ6NJRJM44Z2P84NGQ3Q","detecting-evasion-techniques-in-endpoint-logs","Detects defense evasion techniques used by adversaries in endpoint logs including log tampering, timestomping, process injection, and security tool disabling. Use when investigating suspicious endpoint behavior, building detection rules for evasion tactics, or conducting threat hunting for stealthy adversary activity. Activates for requests involving evasion detection, defense evasion analysis, log tampering detection, or MITRE ATT&CK TA0005.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002Fcore\u002Fskills\u002Fdetecting-evasion-techniques-in-endpoint-logs\u002FSKILL.md",[],[],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":90,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":19},"01M734AFNXD06Z78QRK0VKGT7Q","implementing-microsegmentation-with-guardicore","Implementing microsegmentation using Akamai Guardicore Segmentation to map application dependencies, create granular network policies, visualize east-west traffic flows, and enforce least-privilege communication between workloads across data centers and cloud.","https:\u002F\u002Fgithub.com\u002Fyanacuti1121\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FLICENSE","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fimplementing-microsegmentation-with-guardicore\u002FSKILL.md",[],[],{"skillNo":95,"name":96,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":19},"01M736TK27QMCXK0DVCH25SJN5","ramdisk-tmpfs-patterns","https:\u002F\u002Fgithub.com\u002FHoronomos-laps\u002FYana-AI\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Framdisk-tmpfs-patterns\u002FSKILL.md",[],[]]