做什么
为现有的GitHub Actions CI/CD工作流程创建正式规格,优化后用于AI消费和工作流程维护.
技能库 智客分类:运维与云 create-github-action-workflow-specification
为现有的GitHub Actions CI/CD工作流程创建正式规格,优化后用于AI消费和工作流程维护.
官方网址:skills.sh
先看中文介绍;官方 description 原文单独保留,不改写 SKILL.md。
为现有的GitHub Actions CI/CD工作流程创建正式规格,优化后用于AI消费和工作流程维护.
官方 description 未单独写出 Use when。按规范,代理会在用户任务与这段 description 的关键词匹配时激活本技能。
按 Agent Skills 渐进披露:启动时只加载 name 与 description(约 100 token);任务匹配后才读入整份 SKILL.md 正文;scripts/、references/、assets/ 仅在需要时再读。 本文件正文结构:Create GitHub Actions Workflow Specification、AI-Optimized Requirements、Specification Template、Workflow Overview、Execution Flow Diagram、Jobs & Dependencies。 其中含规范建议的小节:分步指令。
文件分析:这是一份仅含 SKILL.md 的指令型技能,代理激活后整份正文进入上下文。
Create a formal specification for an existing GitHub Actions CI/CD workflow, optimized for AI consumption and workflow maintenance.
Create GitHub Actions Workflow SpecificationAI-Optimized RequirementsSpecification TemplateWorkflow OverviewExecution Flow DiagramJobs & DependenciesRequirements MatrixFunctional RequirementsSecurity RequirementsPerformance RequirementsInput/Output ContractsInputs
来源分类:skills.sh agent-skill
namecreate-github-action-workflow-specificationdescription具体调用语法与可用工具以目标 Agent 客户端为准。 查看调用机制说明 ↗
先选择目标 Agent 和安装范围,保留技能包的附属文件,安装后检查客户端能否发现该技能。
复制安装指令给支持 Agent Skills 的代理,确认其中的目标目录与客户端匹配。
把 Agent Skill「create-github-action-workflow-specification」安装到我的项目:SKILL.md 原文与官方 description 见 https://zicq.com/zh/skills/skl-c8f0ae5c76bfae69-Create-Github-Action-Workflow-Specificat.html 请存为 .cursor/skills/create-github-action-workflow-specification/SKILL.md 或 .claude/skills/create-github-action-workflow-specification/SKILL.md,frontmatter 的 name 与 description 保持原样,不要改写。
需要 Node.js 与 npx。先查看仓库技能列表,确认实际名称。
npx skills add 'https://github.com/github/awesome-copilot' --list
npx skills add 'https://github.com/github/awesome-copilot' --skill 'create-github-action-workflow-specification'
CLI 会交互选择目标 Agent,默认安装到项目;用户级安装使用 -g。先通过查看命令核对仓库内容,再用 npx skills list 检查已安装技能。
Create a comprehensive specification for the GitHub Actions workflow: ${input:WorkflowFile}.
This specification serves as a specification for the workflow's behavior, requirements, and constraints. It must be implementation-agnostic, focusing on what the workflow accomplishes rather than how it's implemented.
Save as: /spec/spec-process-cicd-[workflow-name].md
---
title: CI/CD Workflow Specification - [Workflow Name]
version: 1.0
date_created: [YYYY-MM-DD]
last_updated: [YYYY-MM-DD]
owner: DevOps Team
tags: [process, cicd, github-actions, automation, [domain-specific-tags]]
---
## Workflow Overview
**Purpose**: [One sentence describing workflow's primary goal]
**Trigger Events**: [List trigger conditions]
**Target Environments**: [Environment scope]
## Execution Flow Diagram
```mermaid
graph TD
A[Trigger Event] --> B[Job 1]
B --> C[Job 2]
C --> D[Job 3]
D --> E[End]
B --> F[Parallel Job]
F --> D
style A fill:#e1f5fe
style E fill:#e8f5e8
| Job Name | Purpose | Dependencies | Execution Context | |----------|---------|--------------|-------------------| | job-1 | [Purpose] | [Prerequisites] | [Runner/Environment] | | job-2 | [Purpose] | job-1 | [Runner/Environment] |
| ID | Requirement | Priority | Acceptance Criteria | |----|-------------|----------|-------------------| | REQ-001 | [Requirement] | High | [Testable criteria] | | REQ-002 | [Requirement] | Medium | [Testable criteria] |
| ID | Requirement | Implementation Constraint | |----|-------------|---------------------------| | SEC-001 | [Security requirement] | [Constraint description] |
| ID | Metric | Target | Measurement Method | |----|-------|--------|-------------------| | PERF-001 | [Metric] | [Target value] | [How measured] |
# Environment Variables
ENV_VAR_1: string # Purpose: [description]
ENV_VAR_2: secret # Purpose: [description]
# Repository Triggers
paths: [list of path filters]
branches: [list of branch patterns]
# Job Outputs
job_1_output: string # Description: [purpose]
build_artifact: file # Description: [content type]
| Type | Name | Purpose | Scope | |------|------|---------|-------| | Secret | SECRET_1 | [Purpose] | Workflow | | Variable | VAR_1 | [Purpose] | Repository |
| Error Type | Response | Recovery Action | |------------|----------|-----------------| | Build Failure | [Response] | [Recovery steps] | | Test Failure | [Response] | [Recovery steps] | | Deployment Failure | [Response] | [Recovery steps] |
| Gate | Criteria | Bypass Conditions | |------|----------|-------------------| | Code Quality | [Standards] | [When allowed] | | Security Scan | [Thresholds] | [When allowed] | | Test Coverage | [Percentage] | [When allowed] |
| Condition | Severity | Notification Target | |-----------|----------|-------------------| | [Condition] | [Level] | [Who/Where] |
| System | Integration Type | Data Exchange | SLA Requirements | |--------|------------------|---------------|------------------| | [System] | [Type] | [Data format] | [Requirements] |
| Workflow | Relationship | Trigger Mechanism | |----------|--------------|-------------------| | [Workflow] | [Type] | [How triggered] |
| Scenario | Expected Behavior | Validation Method | |----------|-------------------|-------------------| | [Edge case] | [Behavior] | [How to verify] |
| Version | Date | Changes | Author | |---------|------|---------|--------| | 1.0 | [Date] | Initial specification | [Author] |
## Analysis Instructions
When analyzing the workflow file:
1. **Extract Core Purpose**: Identify the primary business objective
2. **Map Job Flow**: Create dependency graph showing execution order
3. **Identify Contracts**: Document inputs, outputs, and interfaces
4. **Capture Constraints**: Extract timeouts, permissions, and limits
5. **Define Quality Gates**: Identify validation and approval points
6. **Document Error Paths**: Map failure scenarios and recovery
7. **Abstract Implementation**: Focus on behavior, not syntax
## Mermaid Diagram Guidelines
### Flow Types
- **Sequential**: `A --> B --> C`
- **Parallel**: `A --> B & A --> C; B --> D & C --> D`
- **Conditional**: `A --> B{Decision}; B -->|Yes| C; B -->|No| D`
### Styling
```mermaid
style TriggerNode fill:#e1f5fe
style SuccessNode fill:#e8f5e8
style FailureNode fill:#ffebee
style ProcessNode fill:#f3e5f5
For workflows with 5+ jobs, use subgraphs:
graph TD
subgraph "Build Phase"
A[Lint] --> B[Test] --> C[Build]
end
subgraph "Deploy Phase"
D[Staging] --> E[Production]
end
C --> D
Focus on creating a specification that serves as both documentation and a template for workflow updates.
运维与云
用于容器管理,图像操作,调试的基本道克命令和工作流程.
运维与云
从开放的代理技能生态系统中发现并安装技能. 使用时:(1)用户问"我如何做X",X可能拥有现有技能,(2)用户说"为X找到技能"或"是否为X有技能",(3)用户问"你能否做X",X是专门能力,(4)用户想扩展代理能力,(5)用户想搜索工具,模板,或工作流程,(6)用户提到他们希望…
运维与云
Azure上使用AppLens,AzureMonitor,资源健康,安全分型的调试Azure生产问题. 当:调试生产问题,故障解答应用服务,应用服务高CPU,应用服务部署失败,故障解答容器应用,故障解答功能,故障解答AKS,VM RDP,Linux SSH,VM黑屏幕,无法连接到…
运维与云
准备 azd 用于部署的Azure项目:为Azure开发者CLI(azd)工作流程生成azure.yaml,基础设施(Bicep/Terraform)和多克文件. 仅当用户明确想要使用 azd 作为部署工具时使用, 或项目已经有一个 azure 。 雅姆尔文件。 不使用: 非az…