generate-cicd

从 vfarcic/dot-ai 的 shared-prompts/generate-cicd.md 移植（MIT，Copyright (c) 2025 Viktor Farcic）。原作者：Viktor Farcic。

生成 CI/CD 工作流

通过交互式对话，为当前项目生成合适的 CI/CD 工作流。此提示词会分析整个代码库，展示分析结果，询问工作流偏好，并根据你确认的选择生成工作流。

说明

你将帮助开发者为其项目设置 CI/CD 工作流。与基于模板的生成器不同，你将：

1. 分析整个代码库，包括源代码、自动化脚本、配置、文档和现有 CI
2. 展示分析结果和工作流选项，供用户决策
3. 根据用户确认的选择生成工作流

这种交互模式至关重要，因为 CI/CD 工作流涉及策略决策（PR 与直接推送、发布触发条件、部署策略），无法仅从代码推断出来——这些决策反映了团队偏好和组织政策。

关键规则

核实所有内容：添加任何步骤、密钥或配置之前，都要检查实际代码库并加以核实。绝不妄加假设。有不确定之处时请询问。

始终展示工作流选项：CI/CD 涉及需要用户输入的策略决策。即使你检测到测试和 Dockerfile，也无法知道测试应在 PR 还是 main 上运行、发布由什么触发、使用哪个镜像仓库，或如何部署。这些工作流选择需要用户输入。

---

最佳实践

生成工作流时，请遵循以下实践。

使用项目自动化，而非内联命令

CI 工作流应调用项目自动化，而不是包含内联命令逻辑。

# ❌ BAD - Logic in CI, can't run locally the same way
- run: |
    jest --coverage --ci
    eslint src/ --format=stylish

# ✅ GOOD - CI calls project automation
- run: npm test
- run: npm run lint

原因：确保本地与 CI 环境一致、支持跨 CI 平台移植、便于调试，并保持单一事实来源。

如果项目中没有自动化脚本，请询问用户：

I didn't find automation for [operation]. Would you like me to:
1. Add it to the project (recommended for local/CI parity)
2. Use inline command in workflow

基础设施使用 Actions，逻辑使用项目命令

类别	示例	方式
CI 基础设施	checkout、设置运行环境、缓存、登录镜像仓库	✅ 使用 Actions
项目逻辑	构建、测试、lint、docker build、部署	✅ 使用项目自动化

密钥处理

只有配置了密钥的组织或所有者才能访问这些密钥。来自 fork 的 PR 无法访问基础仓库的密钥。

使用条件判断，在密钥不可用时跳过步骤：

- name: Run integration tests
  if: secrets.API_KEY != ''
  run: npm run test:integration
  env:
    API_KEY: ${{ secrets.API_KEY }}

生成的工作流需要密钥时，请清晰地说明：

## Required Secrets

| Secret Name | Description | How to Create |
|-------------|-------------|---------------|
| `REGISTRY_USERNAME` | Container registry username | Your registry account username |
| `REGISTRY_TOKEN` | Container registry access token | Registry settings > Access Tokens |

**To create secrets via CLI:**
gh secret set REGISTRY_USERNAME
gh secret set REGISTRY_TOKEN

将 gh secret set 命令作为指引展示，但不要执行。

安全

实践	说明
最小权限	使用 permissions: 代码块，仅授予所需权限
优先使用 OIDC，而非长期有效令牌	对于云服务提供商，优先采用 OIDC 联合身份验证
固定 Action 版本	使用 SHA 或版本标签，绝不使用 @latest
禁用凭据持久化	在 actions/checkout 中设置 persist-credentials: false
防止脚本注入	绝不将不受信任的输入（分支名称、PR 标题）直接插入 run: 命令
避免使用 pull_request_target	此触发器可以访问密钥，但也能检出 fork 的代码——这两者组合起来非常危险
环境保护	使用 GitHub 环境，并为生产部署设置必需的审核人员

测试

实践	说明
快速失败	先运行快速检查（lint），再运行耗时较长的检查（测试）
先测试再构建	测试失败时，不要浪费时间构建
并行作业	并发运行相互独立的检查
测试矩阵	如果适用，考虑多个版本或平台

缓存

根据检测到的包管理器和锁文件实施适当的缓存。

---

流程

重要：请按顺序执行此流程。每个步骤都可能改变对话方向。不要一次性提出所有问题——每次只询问一个阶段的问题，并等待用户回复后再继续。

工作流分为三个阶段：

┌─────────────────────────────────────────────────────────────────┐
│ PHASE 1: ANALYZE                                                │
│ Discover what CAN be built/tested/deployed                      │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 2: PRESENT & ASK                                          │
│ Show findings + present workflow choices for user decision      │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ PHASE 3: GENERATE                                               │
│ Create workflows based on confirmed user choices                │
└─────────────────────────────────────────────────────────────────┘

步骤 0：确定 CI 平台（阻断关卡）

关键：这是一个阻断关卡。首先且仅询问 CI 平台。在用户确认使用 GitHub Actions 之前，不要询问任何其他问题，也不要进行任何分析。

询问用户使用哪个 CI/CD 平台。仅提供以下选项：

1. GitHub Actions
2. 其他

如果是 GitHub Actions → 继续步骤 1（分析）

如果是其他平台 → 停止。询问用户使用哪个平台，然后回复：

[Platform] is not yet supported. Would you like me to open a feature
request issue at https://github.com/vtmocanu/skills/issues so we
can prioritize adding it?

1. Yes, open a feature request
2. No, I'll use a different approach

然后处理用户的回复（创建 issue 或结束对话）。对于不支持的平台，不要继续分析仓库。

步骤 1：全面分析仓库

分析所有内容。整个仓库都是上下文。

1.1 检测语言和框架

• 根据源文件和依赖清单识别主要语言
• 根据依赖项检测框架
• 记录版本要求

1.2 发现并了解现有自动化

查找现有的自动化，并阅读脚本以了解其工作方式——它们接受哪些参数、内部处理哪些内容，以及应如何调用。不要只记录某个脚本存在；要了解它的具体用途。

• 如果已有用于某项任务的自动化 → 在生成的工作流中使用它
• 仅在没有找到现有自动化时才生成原始命令
• 如果有多个自动化选项 → 询问用户

原因：现有自动化通常会处理原始命令可能遗漏的设置、测试固件、环境变量和清理工作。维护者选择构建系统自有其原因。

1.3 分析现有 CI

检查是否存在现有 CI 配置。如果存在：

• 分析已配置的内容及其原因
• 在步骤 2 中，询问用户是要更新现有工作流还是创建新工作流

1.4 检测容器和镜像仓库

• 检查是否存在 Dockerfile 和容器配置
• 在现有 CI、自动化或文档中搜索镜像仓库引用
• 如果没有 Dockerfile，但项目可能会受益于容器化，建议使用 /generate-dockerfile 提示词

1.5 分支和发布策略

• 检查现有 CI 触发器的模式
• 查看 git 标签，了解版本控制模式
• 检查文档中的工作流线索

1.6 环境和密钥

• 查找环境变量文档或示例
• 搜索代码中必需的环境变量
• 确定工作流需要哪些密钥

1.7 检测应用定义

识别应用为部署打包的方式：

• Helm charts
• Kustomize 配置
• 纯 Kubernetes 清单
• 仅容器（无 K8s 部署）

1.8 检测部署机制

识别应用的部署方式：

• GitOps（ArgoCD、Flux）
• 直接部署（Helm、kubectl）
• 手动部署
• 外部系统

对于 GitOps：

• CI 不得直接部署——它会更新清单，再由 GitOps 控制器同步
• 确定是否存在 GitOps 资源（ArgoCD Application、Flux Kustomization）
• 如果不存在，可能需要创建它们（在同一仓库或单独的集群配置仓库中）
• 确定镜像标签更新所需的清单位置

如果不明确，请在步骤 2 中询问用户。

1.9 检测工具管理器

检查是否存在工具/环境管理器（DevBox、mise、asdf 等）。如果存在，自动使用。如果没有，则在交互式问答期间询问用户。

步骤 2：展示分析结果以供确认

生成工作流之前，先展示分析摘要。 仅包含与此项目相关的内容——以下示例仅作说明，并非需要填写的模板：

## Analysis Summary

I analyzed your repository and found:

**Language/Framework**: Node.js 20 with Express
**Build Command**: `npm run build` (from package.json)
**Test Command**: `npm test` (from package.json)
**Existing CI**: GitHub Actions workflow found (ci.yml)

**App Definition**: Helm chart in `charts/myapp/`
**Deployment Mechanism**: GitOps with ArgoCD

Is this correct? Would you like to change anything?

用户可以：

• 确认分析结果 → 继续选择工作流
• 更正错误
• 澄清不明确之处

步骤 3：提出工作流选项

根据分析结果，提出与此项目相关的选项。 这些是需要用户输入的策略决策。只询问适用的内容——例如，如果没有 Dockerfile，就不要询问容器注册表；如果项目是一个库，就不要询问部署策略。

常见选项包括：

• PR 工作流：拉取请求中应运行哪些内容？
• 发布触发条件：什么会触发发布构建？
• 发布验证：发布工作流是否应重新运行已在 PR 中通过的检查？（全部重新运行 = 最安全、最慢；跳过验证 = 最快；仅运行安全扫描 = 折中方案）
• 容器注册表：应将镜像推送到哪里？（如果使用容器）
• 环境设置：使用原生 GitHub Actions 还是 DevBox？
• 部署策略：GitOps、直接部署还是手动部署？（如果需要部署）

根据需要提出澄清问题：

• 如果分支策略不明确：“你们使用功能分支并通过拉取请求合并，还是直接推送到 main？”
• 如果有多个自动化选项：“我发现有多种运行测试的方式。哪个是主要的测试命令？”
• 如果检测到 GitOps，但仓库位置不明确：“GitOps 清单存放在哪里——在同一个仓库还是单独的仓库？”

步骤 4：生成工作流

根据分析结果和已确认的用户选择，生成合适的工作流。

步骤 5：验证生成的工作流

向用户展示之前：

1. 语法验证：确保 YAML 和 GitHub Actions 语法有效
2. 引用检查：验证所引用的自动化确实存在
3. 密钥文档：清楚列出所需密钥
4. 权限检查：确保权限块尽可能精简
5. 部署检查：验证部署步骤与所选机制一致

步骤 6：向用户展示

提供：

1. 生成的工作流文件，附带说明性注释
2. 摘要，说明检测到的内容和作出的决策
3. 需要配置的密钥（附配置指南）
4. 所需权限和设置——根据工作流的功能，确定需要哪些权限或仓库设置，并提供配置说明。不要等到工作流失败后才告知用户；请提前说明需要配置的内容。

步骤 7：验证

用户批准后，按照项目既定流程提交工作流。触发工作流、监控运行情况，并针对任何失败进行迭代，直到全部通过。