Skill 管的是怎么做，Automation 管的是什么时候自动去做。一个工作流已经足够稳定，而且会重复发生，就值得交给它，在后台按计划触发，不用每次手动发起。

什么时候值得交给自动化

定期查一遍文档死链，每周整理一次 issue 或 PR 摘要，这类活有固定节奏。每天汇总失败的 CI，固定时间提醒补复盘，催人更新文档，也一样。它们做起来没什么新意，最值得交出去。

一个自动化由三部分组成

目标对象，也就是它对应哪个项目，仓库或者线程。触发时机，可以是固定时间，也可以是固定间隔，还能设定稍后回到当前任务继续跟进。执行内容，就是到时具体要它干什么。

这三样想清楚，配置本身没多少难度。

流程走一遍

选中对应的项目，仓库或当前线程，设好执行时间或周期，然后写清这次自动化任务的目标，输出格式和边界。保存之后先看第一次运行结果，没问题再决定要不要长期留着。

prompt 要写成自包含

这一条最容易被忽略。不要默认它记得你之前说过什么，检查范围，输出格式，验证要求，都得写完整。

不太好的写法是一句”请检查一下文档里的链接有没有问题”。它每次触发都得靠猜来补细节，结果自然不稳定。

有效的写法会把边界写死：检查 docs 目录下所有 .md 文件里的外部链接，只查以 http 开头的那部分，锚点和相对路径跳过。输出按文件路径，行号，链接，状态四项列出来，全部正常就说一句全部链接正常。验证方式是每个链接发一次 HEAD 请求，超过 5 秒算失效。最后加一条限制，不修改文件，也不创建新文件。

后一种写法的好处在于，不管哪次执行，在哪个上下文里，行为都是一致可预期的。

两个提醒

不同工作区里的自动化能力可能不完全一样，有的支持项目级任务，有的偏提醒和跟进。

第一次配置时，从低风险，只读的任务开始。如果它要写文件，要访问外部系统，或者触发通知，先把权限边界和人工复核方式确认好。