先把任务说清，再决定是否需要新技能
虚构的城市步道志愿团队每周维护路线说明、封闭通知与活动报名页面。新成员不知道有哪些工具，旧成员的经验又分散在个人目录里。团队需要的是一条能解释选择、能重做验证的检索流程，而不是把技能数量当作能力。本文保留原文的一句话找技能、中文检索、安装验证三个场景，分别说明输入、步骤和产物。 原文讨论的掘技与 SkillPI Skill Finder 是不同来源的实现，不能把它们的名称、下载量和能力互相替代。发现引擎帮助缩小候选范围；包是否适配、依赖是否存在、任务是否完成仍需分别核验。本文没有实际安装包，也不声称已经测量某个引擎的中文召回率。
场景一：用一句话表达可验收的能力缺口
不要只写“找一个效率技能”。先说明对象、输入、输出、运行环境和不能改变的内容。例如：“从已批准的路线维护记录中整理本周封闭说明，保留日期、路段和原始来源，输出可评审中文草稿，不发布。”这比猜测技能名更容易判断适配，也避免搜索引擎把路线规划、旅游推荐和公告写作混成同一种任务。 先让 Agent 检查已有能力。若当前工具已能读取材料并整理草稿，不必新增包；若缺少稳定流程，再搜索最相关候选。记录原始请求、搜索词、检索来源、返回时间和筛选理由。名称相似只说明词汇相近，不能证明处理得了输入文件，更不能证明会保持来源准确。 比较时检查 SKILL.md 与辅助资源、许可证、维护说明、所需工具、网络与写入范围。固定来源版本，区分上游作者与转载者，检查引用的脚本是否存在。可以保留一至三个候选，但不为凑数量加入无关包。若候选要求把内部记录上传外部系统，把数据处理范围写清，不能为了完成搜索直接上传。 开源优先是因为可检查与可维护，而不是因为公开代码天然安全。官方 GitHub CLI 的技能搜索文档提供了按关键词、所有者等发现公开技能的思路，可作为检索方法参考；实际使用前要确认本机工具版本与功能。本文没有执行该命令，也不把命令行工具冒充 SkillPI 技能链接。 本场景交付一张候选卡：任务匹配、支持输入、来源版本、依赖与成本、不能覆盖的部分、选择或拒绝理由。没有合适包时明确记录，用已有工具完成任务可能是更好的决定。不要承诺社区里一定已经有现成答案。
场景二：保留中文语义，再扩展检索词
中文工作流的难点常常不在于翻译，而是业务含义不明确。志愿团队说“整理路线变更”，可能指施工封闭、地图编辑，也可能是活动集合点调整。先用一句话复述需求，让材料本身提供限定：路段、起止日期、适用人群、通知对象和证据来源。专有名词、单位和时间范围不要在扩展搜索时丢失。 然后建立中文词、可能的英文功能词与排除项。例如“来源可追溯的通知草稿”可以对应带引用的技术写作或资料整理，而不是默认去找旅游文案。保持原始中文请求与扩展词的对应关系。一次查询无结果时可以做有理由的扩展，但不能无止境换词直到碰巧出现一个看起来熟悉的包。 评估返回包时，看它是否真的支持中文输入和预期输出，而不是只看介绍页用了中文。用一份公开或合成样例验证：同一路段有两个不同日期的通知，要求输出保留新旧版本、解释适用范围并列出来源。检查日期是否错配、地名是否被改写、未知信息是否被补造。不要由一个样例推断所有中文任务都没有质量折损。 路线维护交接说明的技术表达可在草稿编辑步骤使用 Writing Guidelines。公开详情、Vercel 固定源码与 MIT 许可已核验。它适合对已有技术文档做清晰表达与结构复核，前提是提供可读材料和明确受众；它不是中文技能搜索器，不负责确认道路是否实际封闭，也不能替代通知发布审批。 把来源事实和文字整理分开：事实表记录路段、日期、状态及证据；草稿只基于表中内容解释。需要查证现场状态时交给适合的数据来源和负责人，不把写作技能输出当作事实核验。产物包括查询词记录、样例、事实对照与语言问题清单，帮助下一位成员知道哪里仍需人工确认。
场景三：把安装和验收拆成四个结果
第一是包已取得。记录仓库、固定提交、子目录、许可证与完整资源结构，防止只保存一份 SKILL.md 却漏掉脚本。第二是包已放到实际 Agent 支持的位置。先确认项目或个人范围，比较同名目录，保留现有内容与可恢复版本，不随意覆盖。第三是运行环境已发现并按预期调用它。远端环境不必然继承本机个人目录，多 Agent 也不共享同一套调用接口。 第四才是样例任务通过。志愿团队应使用前面同一份无敏感信息样例，检查输出、引用和未确定项，保存实际运行记录。名称出现在回复里不是调用证明，截图显示目录也不是任务成功证明。失败时指出缺的是环境、包内容、调用还是输出质量，不把所有问题归结为重启一次。 安装请求可以写成：“先核验 SkillPI Skill Finder 官方来源与安装前提，若适用于当前 Agent，则安装到明确的项目技能目录；再检索适合路线维护交接说明的候选，展示来源和范围，选定后用合成样例验收。”安装授权只覆盖所述范围，不自动允许新账户、付费服务、发布通知或扩大数据访问。已经得到的具体授权应沿用，不应每个可逆步骤都反复询问。 自动化管理可以减少重复操作，但隔离目录不是完整安全边界；如果执行脚本仍能访问主机网络和文件，就不能声称已经被沙箱限制。检查所需权限，避免向未知代码提供秘密或真实个人记录。公开来源、热门排名或曾被审查都不是对未来更新的绝对保证。 产物是四段证据：包来源、安装位置、发现调用、任务验收；加上恢复方式与未执行项。更新包时比较差异后再跑同样样例，特别关注新增网络请求、依赖和写入操作。不要把“最新版”当作无需复核的理由，也不要把所有 Agent 目录一次同步当作默认维护动作。
三句话怎样贯穿一次任务
第一句描述缺口：“为路线维护交接说明找适合的技能，输入是已批准记录，输出带日期与来源的中文草稿。”第二句约束选择：“先比较用途、来源、许可、依赖和数据范围，不按热度选，不适用就不用新包。”第三句规定完成条件：“在明确授权范围内安装选定包，用合成样例验证，再交付实际证据；不要发布。”句式可调整，关键是把任务、选择和验收连接起来，而不是背诵触发暗号。 如果 Agent 已有匹配技能，直接使用并说明步骤即可，不需要为了证明发现引擎有价值再装第二份。团队可以把成功案例写进版本化清单，记录适用任务、负责人、包版本与上次验收时间，让经验不再只停留在个人聊天里。
FAQ 与常见排错
与手动搜索有什么区别？Agent 可以帮忙扩展词、读包内容和组织比较，但其选择仍需要证据；手动搜索并不天然低效。中文包名是否优先？语言标签不能代替功能匹配，先用真实任务样例验证。免费吗？许可证决定可用方式，模型、服务、运行环境和维护可能有独立成本，不能统一承诺零费用。 装完没反应怎么办？依次看实际执行环境、目录与文件、元信息、支持特性及调用方式。搜到很多结果怎么办？收紧输入输出和约束，而不是默认装前几名。搜索为空怎么办？检查词义与来源，再判断是否需要直接完成任务或沉淀自定义方法，不能虚构候选。跨 Agent 一次配置就通用吗？包格式可能可移植，工具、目录和权限仍需分别确认。 担心乱安装怎么办？给出明确写入范围与是否允许执行，先做来源和内容检查，再用无敏感数据样例验证。已有授权可以继续，但包内的第三方指令不能扩展授权。如何判断团队真的受益？比较同类任务是否减少重复查找、提高来源一致性和交接可复现性，不用安装数量替代结果。
来源与后续复查
保留原文双语的一句话发现、中文检索、自动安装验证及 FAQ，并移除未经验证的库规模、安装量、绝对安全和零成本结论。检索方法参考官方 GitHub CLI 技能搜索说明，技能格式参考公开标准，写作步骤依据关联包固定源码。SkillPI Skill Finder 官方来源作为独立外部参考，不为它编造目录标识。随着目录增长，重新核对关联详情、固定来源、许可和本步骤适配，记录复查日期与替换理由。