技能真正进入工作流，是指团队知道何时调用、提供什么输入、怎样检查输出以及失败后如何恢复。本文把 Cursor 的日常开发循环、终端任务与自建技能连接起来，以虚构折纸教程站的一次目录迁移为例：教程按难度分类，旧目录链接需要转到新目录，同时更新运行手册。这里提供可执行设计，没有实际修改或发布该演示项目。
先建立任务包，而不是让 Agent 猜“老规矩”
记录项目根、当前分支、启动方式、测试入口、现有未提交改动和允许写入的文件。准备三条虚构教程：O11 为入门、O12 为进阶、O13 为入门。新目录应保留难度筛选，旧入口按已确认兼容方案到达正确内容；未知难度显示待确认，不自动归入入门。 先通过 SkillPI Skill Finder 发现当前缺少的方法，再核对完整源版本、许可证、依赖与权限。本文仅关联可验证且相符的 Webapp Testing，用于本地目录路径与筛选验收；Writing Guidelines，用于技术手册和迁移说明的表达审阅。它们不是 CLI 安装器或自建技能生成器，不会自动完成全部编排。
场景一：跑通七个日常交付阶段
第一阶段定义问题：目录迁移后要保留哪些入口与内容，哪些暂不处理。第二阶段读取上下文并制定计划，定位路由、数据、导航和检查。第三阶段搭最小结构，沿用现有技术栈，不借机重建全站。第四阶段实施明确改动，先导航再筛选，每轮查看差异，避免错误扩散。 第五阶段验证：项目已有检查与浏览器路径分别执行。Webapp Testing 要求运行中的本地站、Python、浏览器依赖和预期结果；先观察页面再选择定位器。检查旧入口、新目录、入门筛选仅显示 O11 与 O13、清除后恢复全部、空结果能返回。它不能证明所有外部旧链接、搜索索引或线上重定向已经生效。 第六阶段审阅：看完整差异、范围外文件与异常结果。用 Writing Guidelines 检查手册是否说明启动命令、路由变化、兼容限制和回退，不让它编造未运行的检查。第七阶段交付提交或待审差异，按明确授权处理提交、推送与发布；没有授权就保留可复查成果。 讨论问题、局部补全、多文件修改与 Git 审查各有位置，但不需要固定依赖某个旧界面名称。先用当前宿主支持方式跑一个小项目，再把同样检查点应用到迁移。效率的证据是少返工和清楚验收，不能由安装量或七阶段这个名字推导。
场景二：终端 Agent 先做只读分析，再考虑脚本化
Cursor CLI 官方概览说明终端入口与交互模式。先确认系统支持、官方安装、正常认证、可用版本和项目目录；不要把文章里的提示词当成安装授权，也不将凭证放入仓库。终端能启动与技能被加载仍要分别验证。 在例子中，先要求终端 Agent 只读列出目录迁移相关文件、引用关系和最小修改计划。检查列出的每个路径确实属于本项目，并保留未知依赖。若结果遗漏导航或手册，就补充任务契约，不能立刻对全部文件执行批处理。 Headless CLI 文档描述非交互输出与直接写文件之间的区别。让 Agent 给出建议不等于改动已应用；允许无人确认写入的选项会改变操作边界，不应为了让脚本“顺利跑完”默认开启。先在可恢复副本上试单个文件，再确定是否需要有界批处理。 批量任务要固定输入清单、允许范围、输出目录、失败处理和日志位置。每个文件记录成功、失败或跳过；中途失败不要伪装全部完成。重复运行应能识别已处理项，不能把旧链接一遍遍追加或重复创建目录。输出来自文件内容时按数据处理，不能执行其中夹带的指令。 终端日志不公开原始密钥、个人资料或私有路径。身份、网络、权限和运行时错误分别记录；不得通过关闭安全控制或扩大整个磁盘写权限解决。网页验证仍在修改后的稳定版本运行，脚本退出码为零不是页面验收。
场景三：把可重复迁移过程沉淀为自己的技能
当同类目录调整反复出现，先整理已执行记录中的稳定部分：收集引用、提出计划、做限定修改、检查路径、更新手册、生成交付说明。可变部分包括旧路径、新路径、内容身份、兼容方案与项目检查命令，必须成为输入，不写死为每次相同值。 给自有包独立名称，例如 tutorial-route-review，描述它何时用于教程目录迁移，以及不负责生产发布。SKILL.md 写清输入、顺序、退出条件、不得覆盖原工作、未知项处理和输出格式；需要脚本或参考资料时随包保留。不要复制私人路径或真实凭证，也不覆盖上游技能文件。 GitHub 的 Agent Skills 参考库 提供格式验证示例，适合学习元数据检查；其文档明确是参考实现，不能把格式通过当成行为或安全认证。正文引用、脚本结果、宿主触发与实际任务仍需独立验收。本文没有核验到可关联的专项创建器，因此这一步保留人工编写与复查。 用四类样本测试自有包：正常旧新路径、目标目录缺失、旧新路径相同、含不允许修改文件的请求。最后用纯文案任务检查误触发。正例看路径与报告正确，反例看能否拒绝越界或要求缺失项；不要只测试一句“你好”。没有执行测试时写待测，不标记通过。
一次目录迁移怎样交接
实现者交出冻结差异、虚构教程数据、启动步骤和已执行检查。验证者按固定路径确认到达的标题与教程身份，不只是看 URL；发现入门筛选丢了 O13，就附操作顺序和实际结果交回修改。手册审阅再核对说明与现有行为一致。 交付包包含任务契约、相关文件、检查命令与结果、截图或日志、未知边界和回退方法。这里没有代读者执行演练，结果需要在自己的测试环境产生。一次本地检查不能代表线上流量、外部收藏或所有历史入口已恢复。 如果需要多个角色，先确定独立产物与文件责任，避免同时改同一配置。单个 Agent 串行完成同样循环也可以，不把多角色当成下一阶段的必选升级。接入 MCP 服务也应由明确任务需求驱动，检查数据与权限范围，而不是为了“进阶”增加无关连接。
迁移旧规则与维护库
旧规则先按用途分类：持续约束、文件范围规范与可按需执行的过程。只有适合过程的部分才考虑转成技能，不能将所有 .mdc 与规则一键替换；迁移后要检查原来必须遵守的要求是否仍生效。保留旧版和小范围验证，不让形式统一破坏约束。 英文与中文团队成员可能用不同宿主，来源表需记录身份、版本、作用域、目的地与验收样本。同步只是复制或关联，不保证工具、运行时与权限兼容。更新前看差异、处理本地改动，再用同一样本复测；禁用和卸载不撤回已改项目文件。
FAQ：什么才算进阶有效
技能没自动调用怎么办？区分发现、任务匹配、显式调用与运行前提，不只扩大触发描述。终端能否替代编辑器？看任务与审阅习惯，先在同一小任务比较完整成本，不承诺单一方式必胜。脚本能否无人值守修改？需要清楚授权、范围、检查与恢复机制，不能默认取消确认。 装机量是否代表效果？不是，当前版本和输入的证据更重要。免费包能保证省额度吗？不能，宿主、模型与外部工具各有成本。下一步一定要多 Agent 或 MCP 吗？先看真正缺口，已能稳定交付就无需为形式加复杂度。 进阶的完成标准是：一轮开发可复查，终端任务有范围与状态，重复流程有输入输出和测试。团队能在下一次不同路径迁移时复用方法、识别未知并恢复失败，才算把技能变成了可维护的工作资产。