← 返回 Skill 仓库

ci-cd-pipeline-builder

根据检测到的项目技术栈信号生成实用的CI/CD流水线——快速生成基线、可重复检查、环境感知的部署阶段。适用于为新项目搭建CI、重构现有流水线,或统一多个仓库的部署流程。

slug: ci-cd-pipeline-builder v1.0.0 工程开发 流程型 作者 Alireza Rezvani 9 个文件 · 26.3 KB 更新 2026-10-20 实测 +0.9% ↓ 0 次下载 💬 0 条反馈 规范度 94/100 by Alireza Rezvani
登录后下载(1 虾条) 使用反馈(0) 查看 JSON
实测评测 基本持平 deepseek-chat · 2 任务 × 1 采样 × 3 重复 · 多轮协作 · 盲评 评测方法 →
+0.9%
带该 Skill vs 不带,
judge 盲评的平均分差。
n=3 次重复均值,区间 -4.6% ~ 7.3%
裸模型 28.3
带技能 28.7
评测时间 2026-10-20 2 个任务 × 1 次采样 盲评 · 同一模型同一组参数
展开 2 个测试任务的逐题明细
任务 1 · 我们团队刚接手一个仓库,想先给它搭一套 GitHub Actions 的 CI 基线,但我不想凭感觉写 YAML,你能不能先帮我判断技术栈再生成流水线?
采样 1 裸 82.0 vs 带技能 88.0 两份质量接近,A 在部署安全性和对用户'仅 main'要求的精确遵循上略优,B 在命令同源与 Poetry 安装方式上更规范但部署占位会假成功。
任务 2 · 我们现有 GitLab CI 文件是从别的项目复制来的,跑得慢还可能跟实际技术栈对不上,你能先看看它到底哪里不合理,再帮我重写一版吗?
采样 1 裸 0.0 vs 带技能 0.0 两份质量接近,A 的配置更简洁一致且诚实标注假设,B 诊断更丰富但个别 YAML 细节(coverage artifacts、needs 依赖)处理不如 A 稳妥。
社区实测 用户用自己的 API Key 跑的结果,模型与环境各不相同,仅供横向参考 登录后用我的 API 测 →
还没有人跑过。装上你自己的 Key,用你日常用的模型测一遍——结果只出现在你的记录里,不进官方榜。
—
☆☆☆☆☆
还没有人评分,用过之后来说句实话

一行命令安装

下载这个 Skill 需要先登录(免费注册,只需用户名和密码)。去登录 →

使用反馈 · 0

用过的同学可以在这里说说效果、坑点或改进建议,也可以直接提出新需求。

登录后可以发表使用反馈。去登录 →

还没有反馈,来做第一个分享的人。

规范度体检 · 94/100

按元信息、示例、可执行性、完整性等 13 项自动检查,供作者自查改进;不影响用户评分。

版本历史

SKILL.md 内容

# 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`

## References

- [references/pipeline-design-notes.md](references/pipeline-design-notes.md) — common pitfalls, best practices, detection heuristics, generation strategy, platform decision notes, pre-merge validation checklist, and scaling guidance
- [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)