用途
Workflow Automation 是一个面向代码仓库的“路由优先”重复性工作流自动化技能。它的目标不是堆砌庞大的 Makefile、Shell 脚本、钩子配置和 CI YAML，而是：对重复性工作流进行分类；选择一种主要自动化模式；让本地入口、钩子、CI 镜像和定时维护对自身范围保持诚实；输出一个可复用、带有明确路由出口的方案包。
主要能力
该技能覆盖以下工作流模式：
- task-entrypoints：为重复性人工调用工作提供单一易记的命令入口。
- bootstrap-onboarding：首次运行设置、种子/初始化或重复的仓库初始化。
- local-ci-parity：一个本地验证命令，镜像关键 CI 检查。
- hook-guardrails：提交/推送前的快速本地卫生检查。
- repo-maintenance：依赖更新、定时清理、发布准备杂务、陈旧项自动化。
- workflow-diagnosis：工作流层混乱，需要先简化再添加更多自动化。
技能会先规范化请求，捕获主要目标、仓库形态、当前表面、主要痛点、影响范围和置信度，然后选择恰好一种主要模式，并挑选最小的自动化表面。
使用方式
使用该技能时，先阅读支持文档：references/automation-modes.md、references/mode-packets-and-route-outs.md、references/handoff-boundaries.md。
技能按以下步骤执行：
- 规范化请求，填写 workflow_intake 结构。
- 选择恰好一种主要模式。
- 挑选最小的自动化表面。
- 保持工作流不变量可见。
- 构建 Workflow Automation Packet。
- 使用模式包，而非庞大的工具目录。
输出格式为简短的 Workflow Automation Packet 或 Automation Hardening Brief，要求：先分类工作流再开工具；选择一种主要模式；优先最小可用表面；让本地命令、钩子、CI 和定时任务对边界保持诚实；明确路由出口，而不是让技能吸收邻近工作。
适用场景
- 用单一可重复的仓库自有命令表面替换 README 命令散乱。
- 在 package scripts、Make、just、Task、Shell 入口、钩子、CI 包装器或维护机器人之间做选择。
- 为仓库设计 setup、bootstrap、dev、test、lint、verify 或 ci 命令。
- 收紧本地工作流胶水与托管 CI 执行之间的边界。
- 判断重复性杂务应放在钩子、任务运行器还是定时自动化中。
- 诊断分散在文档、脚本、钩子和 CI YAML 中的混乱工作流层。
限制
以下情况不应使用该技能：
- 真正的阻塞点是机器设置、服务拓扑、工具链固定或容器/devcontainer 可复现性。
- 真正的阻塞点是发布/部署架构或云运行时自动化。
- 真正的阻塞点是 Git 协作/恢复，而非仓库命令设计。
- 真正的阻塞点是测试策略政策，而非命令如何暴露。
- 命令已经显而易见，唯一的工作是简单实现。
路由出口：当涉及机器/运行时配置、本地服务、devcontainer 或跨机器可复现性时，使用 system-environment-setup；当涉及部署发布、托管 CI/CD 架构、预览/暂存/生产晋升或回滚设计时，使用 deployment-automation 或 vercel-deploy；当涉及分支/rebase/恢复/推送安全时，使用 git-workflow；当涉及测试深度/合并门禁政策时，使用 testing-strategies；当涉及运行时遥测/告警/生产可见性时，使用 monitoring-observability。
最佳实践
从重复性工作流出发，而非从偏好的工具出发；优先一个可发现的前门，而非多个半拥有的表面；将仓库本地胶水与环境、部署、Git 政策和可观测性分开；将交互式提示视为最后手段；如果本地与 CI 不同，明确说明在哪里以及为什么不同；在添加更多自动化之前先简化和去重。
参考
Task: The Modern Task Runner、Just Programmer's Manual、mise tasks、pre-commit、GitHub Actions documentation、act documentation、Development containers。