技能已经出现在 Cursor 列表中，却没有进入日常任务，通常需要检查触发条件、阶段输入和验收方式，而不是继续批量安装。本文用虚构社区种子交换站的目录页面说明：读者可以筛选品种、查看余量状态并阅读交换规则。我们把技能自动触发、子代理分工和开发循环串起来，同时保留人工审阅与权限边界。这里提供的是执行设计，没有声称已经创建或运行该示例项目。
把技能、规则和执行角色分开
技能提供某类任务的方法，项目规则说明约束，子代理承担分工后的工作。它们不应互相替代：把每条操作都设成永久规则会增加冲突，把一次简单审阅拆成多个角色也可能只增加交接成本。 先确认项目能运行、相关文件可读、已有改动已记录，并用虚构目录数据建立基线。写出这轮唯一目标：目录筛选后正确显示有余量、已领完和未知三种状态，规则说明易读；不接入真实个人信息，不发送交换邀请，不更改生产站点。阶段结束需要留下文件、验证结果与未解决项。 通过 SkillPI Skill Finder 发现候选后，逐个看来源版本、许可证、工具依赖和权限。本文采用已经核验的 Frontend Design 处理目录页面的视觉方向与界面实现；Webapp Testing 验证本地筛选路径；Writing Guidelines 审阅技术交接说明。它们都不是自动触发调度器或子代理创建器，编排仍由任务设计与宿主能力完成。
场景一：让触发条件可以被检验
安装后先做明确调用，再观察是否能按任务相关性使用。不要把“装了技能就保证每次自动使用”作为前提。Cursor 技能文档描述上下文相关调用与手动调用；以当前版本的实际入口和加载行为为准。写一份项目使用表可以帮助团队理解，但表本身不是强制调度机制。 本例的使用表包含阶段、任务信号、目标技能、输入、输出与不适用情况。界面阶段的信号是“实现目录筛选页”，输入为页面任务、设计约束和已批准数据，输出为界面改动；测试阶段的信号是“验证本地筛选后状态”，输入为运行地址和预期，输出为截图与问题；文档阶段的信号是“审阅运行手册”，输出为带位置的建议。一般闲聊、纯数据导出不应调用这些方法。 用正例、近似反例与明确无关任务验证边界。正例要求实现筛选控件；近似反例只要求解释已有 CSS，不需要新设计；无关任务只统计品种数量。记录实际调用与输出，若误触发就缩小任务描述或明确使用方式，不为了命中率把描述扩大成“任何开发任务”。 项目规则可以声明不得修改生成文件、保留既有改动和按项目命令验证。Cursor 规则文档提供作用范围与应用方式。文件范围规则不等于 Skill 的元数据，修改前保存旧配置，避免把所有指令设为始终应用导致互相覆盖。
场景二：只在有独立产物时引入子代理
复杂任务可拆成实现、验证和审阅，但上下文分离不保证没有文件冲突，更不等于安全沙箱。Cursor 子代理文档给出项目级 .cursor/agents/ 等配置方式及取舍。配置字段、可用工具和技能加载应以当前文档与实际行为检查，不能假定隔离角色自动获得另一会话的上下文或技能。 为种子目录写角色合同。实现角色只改页面与样式，读设计说明和虚构数据，交付差异和启动步骤。验证角色等实现稳定后读冻结版本，只写测试证据，不顺手改产品逻辑。文档审阅角色读交接说明，只返回建议。主任务负责人整合结果、处理取舍并决定下一轮修改。 若确实并行，只并行不写同一文件的工作，例如一个角色研究空状态文案，另一个检查既有测试入口；涉及共享组件或同一配置的修改串行。每个角色收到目标、允许范围、来源版本、输入、退出条件与报告格式。缺少前提时返回缺失项，不得假装完成。 Frontend Design 需要明确受众、功能和视觉方向，以及可编辑代码与运行环境；它不证明用户研究结论或可访问性合规。Webapp Testing 需要 Python、浏览器依赖和可用本地服务；它不能证明后端余量并发扣减。Writing Guidelines 需要技术文档与关联指南，不承担事实核验。角色拿到技能也必须遵守这些前提。
场景三：把七个阶段固定为交付检查点
第一阶段定义范围：筛选种类和余量，保留已有导航，未知余量显示待确认。第二阶段计划：定位状态来源、相关页面、必要检查和回退方式。第三阶段搭骨架：沿用项目组件和数据接口，只加本轮需要的结构，不为了演示重建整站。 第四阶段实施：用 Frontend Design 确立清晰的目录层级、状态标签、筛选控件和空状态，再把设计落到项目代码。不要只靠颜色区别有余量与已领完；文本与控件状态也应表达含义。第五阶段验证：先跑相关项目检查，再用 Webapp Testing 观察页面、操作筛选、检查状态和返回路径，保留虚构输入与复现步骤。 第六阶段审阅与交接：查看完整差异，核对范围与问题列表，用 Writing Guidelines 检查启动方法、状态说明与未验证事项。第七阶段形成提交或待提交交付：只有在明确授权下提交、推送或发布；否则保留可审阅差异与说明。七阶段是本文的团队操作设计，不声称某个安装包已经替你执行完全部流程。 每个检查点都有退出条件。状态定义没确认就不进入设计；站点不能启动就先交缺失项；测试失败就回到对应修改；文档缺事实就请负责人补齐。让工作流在证据不足时明确停在哪一层，比盲目继续产生更多文件更容易维护。
实操：从一次筛选请求到可验收交付
准备三条虚构记录：S21 有余量、S22 已领完、S23 未知。请求“只看有余量”时仅显示 S21；清除筛选恢复三条；不存在的品种显示空状态并能返回。说明页对交换条件使用项目负责人批准的文字，不由设计技能创造新规则。 让实现角色先解释数据如何进入列表，再安排最小改动。完成后冻结版本与启动步骤，验证角色按上面的预期检查；发现“清除后仍只显示一条”时，报告选择器、操作顺序和实际结果，交回实现角色修复。不要在验证角色中默默修改筛选逻辑，使测试与被测版本混在一起。 交付包包含范围说明、相关差异、测试证据、文档建议和未验证边界。本文没有运行这套演练，读者需保存自己的结果；尤其真实交换通知、权限与并发余量必须另测。若没有并行条件，一个 Agent 按同样检查点串行也能执行，不必为形式增加角色。
FAQ：触发、冲突、成本与维护
技能为何没自动用？先核对发现、任务匹配、显式调用与运行前提，不能只修改触发词。规则冲突怎么办？列出矛盾条文、适用文件和来源，一次调整一个因素，保留旧版与复测证据。多文件改写时怎么控制？先限制模块和接口，分批审查；功能完成前不要夹带无关格式化。 是否越多子代理越快？不一定，启动、上下文收集与整合都消耗时间和用量。技能能跨工具无缝同步吗？检查目录、版本、运行时和工具支持，不能仅凭文件格式相同保证行为相同。Finder 在哪一步用？当某阶段缺能力时先发现候选并说明用途，来源核验后再考虑安装。 定期维护使用表，移除不再需要的候选，更新前检查源差异并用固定样本复测。卸载不能撤回已写文件，回退要同时看项目变化。衡量工作流的依据应是验收清楚、失败可复现、交接成本可控，而不是自动触发次数或安装总量。