CI/CD 持續交付

來源狀態

可用來源

原始名稱: ci-cd-and-automation

原始作者: Addy Osmani

這是第三方 Community Skill；2lus 收錄不代表已完整安全審計或保證安全。

資源類型

Skill

與類似 Skill 有什麼不同？

• Deploy to Vercel 部署流程

  Deploy to Vercel 是 Vercel 平台部署工作；CI/CD 設計跨建置、品質閘門與 artifact 的通用交付流程。

• 發布工程

  Release Engineering 安排一次版本發布、觀察與回復；CI/CD 建立可重複執行的交付 pipeline。

來源描述的能力

這些是來源描述的可能操作，不代表 2lus 已授予權限或已測試。

尚未列出能力，請審查原始來源。

這個 Skill 是什麼？

讓品質檢查與發布授權在流程中可見。

可以做什麼？何時適合使用？

• 建立 PR 品質閘門
• 整理 build artifact
• 規劃漸進部署與回復

如何使用

1. 提供現有 workflow 與環境限制
2. 排列 lint、型別、測試及 build 依賴
3. 設計 artifact、人工核准與 rollback 路徑

使用前你需要準備

• Dockerfile 或 workflow
• 服務依賴與部署限制

你可以替換：

[service]、[environment]

環境與相依需求

• 需要 workflow YAML、建置命令和發布政策；保留共用 references。

使用範例與 Prompt

以下是 2lus 撰寫的示範需求；請替換為你有權處理的檔案與專案，不代表已執行或保證結果。

入門

Review 這份 workflow 的 lint、typecheck 與 build 順序，只提出設定修改。

實務

替 Node 專案草擬 artifact 保留與人工 promotion 閘門，將整合測試標示為待授權工作。

進階

設計 feature flag 漸進發布與失敗 rollback 的 pipeline，列出 secrets 邊界、並行部署鎖與可稽核證據。

實用提醒

• 快速檢查提早執行，部署前明確區分測試與人工核准。

限制與注意事項

• pipeline 設定正確不等於部署或測試已成功。

安全注意事項

• 採最小 token 權限；fork PR 不得取得發布 secrets，未授權不執行 pipeline。

使用與設定

此條目不提供已確認的通用安裝指令；請依官方文件與 Agent 版本操作。

支援平台

未確認特定 Agent 相容性

來源與授權

來源查核日期（非安全認證）: 2026-09-29

MIT

相關 Skills

• Deploy to Vercel 部署流程
• 發布工程

Source status

Active source

Original name: ci-cd-and-automation

Original author: Addy Osmani

This is a third-party community skill. Inclusion by 2lus is not a complete security audit or safety guarantee.

Resource type

Skill

How is this different from similar skills?

• Deploy to Vercel

  Deploy to Vercel is platform-specific deployment; CI/CD designs general delivery pipelines across checks, builds and artifacts.

• Release Engineering

  Release Engineering coordinates one release, observation and recovery; CI/CD builds the reusable delivery pipeline.

Documented capabilities

These are operations described upstream, not permissions granted or tested by 2lus.

Capabilities not declared here; review the original source.

What is this skill?

Make quality checks and deployment authority explicit.

Use cases and when to use it

• Create PR quality gates
• Organize build artifacts
• Plan staged deployment and recovery

How to use it

1. Supply workflows and environment limits
2. Order lint, types, tests and build dependencies
3. Design artifact promotion, approval and rollback

What you need

• Dockerfile or workflow
• Service dependencies and deployment constraints

You can replace:

[service], [environment]

Environment and dependencies

• Provide workflow YAML, build commands and delivery policy; retain shared references.

Usage and prompt examples

These example requests were written by 2lus. Substitute files and projects you may use; examples are not executed results or guarantees.

Beginner

Review lint, typecheck and build ordering in this workflow; propose configuration changes only.

Practical

Draft artifact retention and manual promotion gates for Node; mark integration execution as awaiting authorization.

Advanced

Design a feature-flag rollout pipeline with rollback, secret boundaries, deployment concurrency locks and audit evidence.

Tips

• Run cheap checks early; distinguish evidence from deployment approval.

Limitations

• A pipeline configuration does not prove a successful deployment or test run.

Security notes

• Use least-privilege tokens; never expose deployment secrets to fork PRs or run unauthorized pipelines.

Usage and setup

No verified universal installation command is provided for this entry. Follow the official documentation for your agent version.

Supported agents

Specific agent compatibility unknown

Sources and license

Source check date (not a safety certification): 2026-09-29

MIT

Related skills

• Deploy to Vercel
• Release Engineering