Ci Cd Pipeline Builder
Generate pragmatic CI/CD pipelines from detected project stack signals — fast baseline generation, repeatable checks, environment-aware deployment stages. Use when setting up CI for a new project, ...
Generate pragmatic CI/CD pipelines from detected project stack signals — fast baseline generation, repeatable checks, environment-aware deployment stages. Use when setting up CI for a new project, refactoring existing pipelines, or standardizing deployment workflows across multiple repos.
Install
Quick install
npx skills add https://github.com/alirezarezvani/claude-skills/tree/main/engineering/skills/ci-cd-pipeline-buildernpx skills add alirezarezvani/claude-skills --skill ci-cd-pipeline-builder --agent claude-codenpx skills add alirezarezvani/claude-skills --skill ci-cd-pipeline-builder --agent cursornpx skills add alirezarezvani/claude-skills --skill ci-cd-pipeline-builder --agent codexnpx skills add alirezarezvani/claude-skills --skill ci-cd-pipeline-builder --agent opencodenpx skills add alirezarezvani/claude-skills --skill ci-cd-pipeline-builder --agent github-copilotnpx skills add alirezarezvani/claude-skills --skill ci-cd-pipeline-builder --agent windsurfMore install options
Shorthand — useful for multi-skill repos:
npx skills add alirezarezvani/claude-skills --skill ci-cd-pipeline-builderManual — clone the repo and drop the folder into your agent's skills directory:
git clone https://github.com/alirezarezvani/claude-skills.gitcp -r claude-skills/engineering/skills/ci-cd-pipeline-builder ~/.claude/skills/CI/CD Pipeline Builder
Tier: POWERFUL
Category: Engineering
Domain: DevOps / Automation
Overview
Use this skill to generate pragmatic CI/CD pipelines from detected project stack signals, not guesswork. It focuses on fast baseline generation, repeatable checks, and environment-aware deployment stages.
Core Capabilities
- Detect language/runtime/tooling from repository files
- Recommend CI stages (
lint,test,build,deploy) - Generate GitHub Actions or GitLab CI starter pipelines
- Include caching and matrix strategy based on detected stack
- Emit machine-readable detection output for automation
- Keep pipeline logic aligned with project lockfiles and build commands
When to Use
- Bootstrapping CI for a new repository
- Replacing brittle copied pipeline files
- Migrating between GitHub Actions and GitLab CI
- Auditing whether pipeline steps match actual stack
- Creating a reproducible baseline before custom hardening
Key Workflows
1. Detect Stack
python3 scripts/stack_detector.py --repo . --format text
python3 scripts/stack_detector.py --repo . --format json > detected-stack.json
Supports input via stdin or --input file for offline analysis payloads.
2. Generate Pipeline From Detection
python3 scripts/pipeline_generator.py \
--input detected-stack.json \
--platform github \
--output .github/workflows/ci.yml \
--format text
Or end-to-end from repo directly:
python3 scripts/pipeline_generator.py --repo . --platform gitlab --output .gitlab-ci.yml
3. Validate Before Merge
- Confirm commands exist in project (
test,lint,build). - Run generated pipeline locally where possible.
- Ensure required secrets/env vars are documented.
- Keep deploy jobs gated by protected branches/environments.
4. Add Deployment Stages Safely
- Start with CI-only (
lint/test/build). - Add staging deploy with explicit environment context.
- Add production deploy with manual gate/approval.
- Keep rollout/rollback commands explicit and auditable.
Script Interfaces
python3 scripts/stack_detector.py --help- Detects stack signals from repository files
- Reads optional JSON input from stdin/
--input python3 scripts/pipeline_generator.py --help- Generates GitHub/GitLab YAML from detection payload
- Writes to stdout or
--output
Common Pitfalls
- Copying a Node pipeline into Python/Go repos
- Enabling deploy jobs before stable tests
- Forgetting dependency cache keys
- Running expensive matrix builds for every trivial branch
- Missing branch protections around prod deploy jobs
- Hardcoding secrets in YAML instead of CI secret stores
Best Practices
- Detect stack first, then generate pipeline.
- Keep generated baseline under version control.
- Add one optimization at a time (cache, matrix, split jobs).
- Require green CI before deployment jobs.
- Use protected environments for production credentials.
- Regenerate pipeline when stack changes significantly.
References
- [references/github-actions-templates.md](references/github-actions-templates.md)
- [references/gitlab-ci-templates.md](references/gitlab-ci-templates.md)
- [references/deployment-gates.md](references/deployment-gates.md)
- [README.md](README.md)
Detection Heuristics
The stack detector prioritizes deterministic file signals over heuristics:
- Lockfiles determine package manager preference
- Language manifests determine runtime families
- Script commands (if present) drive lint/test/build commands
- Missing scripts trigger conservative placeholder commands
Generation Strategy
Start with a minimal, reliable pipeline:
- Checkout and setup runtime
- Install dependencies with cache strategy
- Run lint, test, build in separate steps
- Publish artifacts only after passing checks
Then layer advanced behavior (matrix builds, security scans, deploy gates).
Platform Decision Notes
- GitHub Actions for tight GitHub ecosystem integration
- GitLab CI for integrated SCM + CI in self-hosted environments
- Keep one canonical pipeline source per repo to reduce drift
Validation Checklist
- Generated YAML parses successfully.
- All referenced commands exist in the repo.
- Cache strategy matches package manager.
- Required secrets are documented, not embedded.
- Branch/protected-environment rules match org policy.
Scaling Guidance
- Split long jobs by stage when runtime exceeds 10 minutes.
- Introduce test matrix only when compatibility truly requires it.
- Separate deploy jobs from CI jobs to keep feedback fast.
- Track pipeline duration and flakiness as first-class metrics.
SKILL.md source
--- name: ci-cd-pipeline-builder description: Generate pragmatic CI/CD pipelines from detected project stack signals — fast baseline generation, repeatable checks, environment-aware deployment stages. Use when setting up CI for a new project, ... --- # CI/CD Pipeline Builder **Tier:** POWERFUL **Category:** Engineering **Domain:** DevOps / Automation ## Overview Use this skill to generate pragmatic CI/CD pipelines from detected project stack signals, not guesswork. It focuses on fast baseline generation, repeatable checks, and environment-aware deployment stages. ## Core Capabilities - Detect language/runtime/tooling from repository files - Recommend CI stages (`lint`, `test`, `build`, `deploy`) - Generate GitHub Actions or GitLab CI starter pipelines - Include caching and matrix strategy based on detected stack - Emit machine-readable detection output for automation - Keep pipeline logic aligned with project lockfiles and build commands ## When to Use - Bootstrapping CI for a new repository - Replacing brittle copied pipeline files - Migrating between GitHub Actions and GitLab CI - Auditing whether pipeline steps match actual stack - Creating a reproducible baseline before custom hardening ## Key Workflows ### 1. Detect Stack ```bash python3 scripts/stack_detector.py --repo . --format text python3 scripts/stack_detector.py --repo . --format json > detected-stack.json ``` Supports input via stdin or `--input` file for offline analysis payloads. ### 2. Generate Pipeline From Detection ```bash python3 scripts/pipeline_generator.py \ --input detected-stack.json \ --platform github \ --output .github/workflows/ci.yml \ --format text ``` Or end-to-end from repo directly: ```bash python3 scripts/pipeline_generator.py --repo . --platform gitlab --output .gitlab-ci.yml ``` ### 3. Validate Before Merge 1. Confirm commands exist in project (`test`, `lint`, `build`). 2. Run generated pipeline locally where possible. 3. Ensure required secrets/env vars are documented. 4. Keep deploy jobs gated by protected branches/environments. ### 4. Add Deployment Stages Safely - Start with CI-only (`lint/test/build`). - Add staging deploy with explicit environment context. - Add production deploy with manual gate/approval. - Keep rollout/rollback commands explicit and auditable. ## Script Interfaces - `python3 scripts/stack_detector.py --help` - Detects stack signals from repository files - Reads optional JSON input from stdin/`--input` - `python3 scripts/pipeline_generator.py --help` - Generates GitHub/GitLab YAML from detection payload - Writes to stdout or `--output` ## Common Pitfalls 1. Copying a Node pipeline into Python/Go repos 2. Enabling deploy jobs before stable tests 3. Forgetting dependency cache keys 4. Running expensive matrix builds for every trivial branch 5. Missing branch protections around prod deploy jobs 6. Hardcoding secrets in YAML instead of CI secret stores ## Best Practices 1. Detect stack first, then generate pipeline. 2. Keep generated baseline under version control. 3. Add one optimization at a time (cache, matrix, split jobs). 4. Require green CI before deployment jobs. 5. Use protected environments for production credentials. 6. Regenerate pipeline when stack changes significantly. ## References - [references/github-actions-templates.md](references/github-actions-templates.md) - [references/gitlab-ci-templates.md](references/gitlab-ci-templates.md) - [references/deployment-gates.md](references/deployment-gates.md) - [README.md](README.md) ## Detection Heuristics The stack detector prioritizes deterministic file signals over heuristics: - Lockfiles determine package manager preference - Language manifests determine runtime families - Script commands (if present) drive lint/test/build commands - Missing scripts trigger conservative placeholder commands ## Generation Strategy Start with a minimal, reliable pipeline: 1. Checkout and setup runtime 2. Install dependencies with cache strategy 3. Run lint, test, build in separate steps 4. Publish artifacts only after passing checks Then layer advanced behavior (matrix builds, security scans, deploy gates). ## Platform Decision Notes - GitHub Actions for tight GitHub ecosystem integration - GitLab CI for integrated SCM + CI in self-hosted environments - Keep one canonical pipeline source per repo to reduce drift ## Validation Checklist 1. Generated YAML parses successfully. 2. All referenced commands exist in the repo. 3. Cache strategy matches package manager. 4. Required secrets are documented, not embedded. 5. Branch/protected-environment rules match org policy. ## Scaling Guidance - Split long jobs by stage when runtime exceeds 10 minutes. - Introduce test matrix only when compatibility truly requires it. - Separate deploy jobs from CI jobs to keep feedback fast. - Track pipeline duration and flakiness as first-class metrics.
Related skills 6
caveman
Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.
secure-linux-web-hosting
Use when setting up, hardening, or reviewing a cloud server for self-hosting, including DNS, SSH, firewalls, Nginx, static-site hosting, reverse-proxying an app, HTTPS with Let's Encrypt or ACME clients, safe HTTP-to-HTTPS redirects, or optional post-launch network tuning such as BBR.
readme-i18n
Use when the user wants to translate a repository README, make a repo multilingual, localize docs, add a language switcher, internationalize the README, or update localized README variants in a GitHub-style repository.
lark-shared
Use when first setting up lark-cli, running auth login, switching user/bot identity (--as), handling permission denied or scope errors, needing to update lark-cli, or seeing _notice in JSON output.
improve-codebase-architecture
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
paper-context-resolver
Optional RigorPilot helper for README-first deep learning repo reproduction. Use only when the README and repository files leave a narrow reproduction-critical gap and the task is to resolve a specific paper detail such as dataset split, preprocessing, evaluation protocol, checkpoint mapping, or runtime assumption from primary paper sources while recording conflicts. Do not use for general paper summary, repo scanning, environment setup, command execution, title-only paper lookup, or replacin...