收藏了一批 AI 技能，工作时却很少想起它们，这并不奇怪。别人每天要整理 Discord 会议、维护 Notion 项目表，你可能只需要把访谈录音变成一份内部纪要。名称相似，输入、工具和交付对象已经不同。直接复制整套技能，通常还要补不少自己的规则。
solo-skills 值得看的地方，是作者把一些重复工作写成了可以阅读的步骤。按 2026 年 9 月 23 日仓库介绍，作者称自己自动化了 58 项工作，其中公开了 38 个技能和 19 个执行脚本。这些是作者的项目说明，不是第三方验证的节省工时；数量也会随仓库更新变化。项目英文说明
与其逐一介绍几十个名字，不如选两类常见工作看看：整理会议记录，以及把一项日常工作设计成可重复流程。由此可以判断哪些内容能直接借鉴，哪些必须改成自己的版本。本文基于仓库文件审阅，没有在真实账号里运行发布、发送或删除操作。
先挑一个有明确结束点的工作
“提高效率”太宽泛，“每次会后把讨论整理成待办草稿”就具体得多。后者有输入，有输出，也能判断哪里出错。输入是录音转写和会议背景，输出是人可以审阅的纪要；结束点可以设在草稿保存完成。
选择第一项工作时，找最近已经重复做过几次的任务。拿出其中一个真实样本，列出自己当时打开了哪些资料，作了哪些判断，最后把结果放在哪里。这个过程会暴露不少平时没意识到的步骤：核对人名、查上周决定、确认哪条讨论没有形成结论。
其中有些步骤适合程序完成，例如按时间排序、检查字段有没有缺失；有些适合模型提出草稿，例如按议题归纳讨论；有些仍需要业务负责人确认，例如把“可以考虑”写成正式承诺。先把这三类分开，技能文件才不会一会儿要求猜测，一会儿又要求绝不猜测。
第一版最好只覆盖一种输入格式。录音、手写笔记、聊天截图全都支持，听起来方便，但每一种都有不同的缺失信息。先让一份正常转写文本稳定产出草稿，后面再增加其他入口。
迁移 meeting-minutes，先检查依赖与交付位置
仓库中的 meeting-minutes 不只有“请总结会议”一句提示。它涉及转写文件、既有项目资料、Notion 登记和 Discord 通知，还记录了转写缺失与状态判断的问题。这能帮助读者看到一份会议记录如何接入实际工作。meeting-minutes 文件
但里面的项目目录、数据库占位符、频道和辅助脚本，都是使用条件。复制后应逐项核对哪些资源在自己环境中存在。尤其是文件里提到了某个脚本，不代表仓库一定提供了你所需的完整服务，也不代表它已适配你的组织结构。
可以先删去与自己无关的外部发布步骤，改成仅从指定转写文件生成本地草稿。等草稿内容稳定，再增加保存到团队系统的步骤。这样出现错误时，容易区分是纪要写错，还是发布接口和字段配置出了问题。
整理内容时，要把“讨论了”“决定了”“完成了”分开。例如有人说“我明天把入口改掉”，纪要应保留为待办；有人说“已经在测试环境演示”，可以记录已演示的范围；如果只出现一句“应该没问题”，就不能把任务状态自动改为完成。这种区别会影响后续进度跟踪，值得写进验收要求。
缺少转写内容时，不要靠上下文补齐
假设一小时会议只留下十分钟文本，模型仍然能写出一份格式完整的纪要。它可能根据议程、上周记录和几条会后聊天，推断出看似合理的结论。格式完整反而会遮住资料不完整的问题。
自己的流程应该先检查输入。至少确认录音或转写覆盖的时间范围、参与者是否明显缺失，以及文件是否为空。发现缺口时，输出一段明确的资料缺失说明，再整理能够确认的部分。无法确认的负责人和日期留空或标为待确认，不凭会议习惯补上。
会后补充消息也可以使用，但要放在单独的位置，注明来自会后沟通。这样以后找到完整录音，可以清楚地比较哪条是会议决定，哪条是后来调整。对跨时区团队，还应保留实际日期与时区，避免“明天交付”在转发后失去含义。
对于第一版技能，可以用一个有意缺失的样本来测试：删掉转写中决定负责人和日期的一段，看看结果是否仍凭空出现这两个字段。如果出现，说明提示词或检查流程还需要调整。这个测试比反复给它一份资料齐全的文本更有价值。
workshop-prep 可以帮助梳理需求，但前提要核实
仓库的 workshop-prep 通过访谈了解日常工作，再形成技能设计。它提醒我们先弄清工作如何发生，而不是立刻编写很长的指令。但原文件还设置了 Context7 等依赖前提，并包含对应客户端配置步骤。评估时要区分“这个技能当前要求”与“所有自动化工作都必须这样做”。workshop-prep 文件
若只是梳理一项内部纪要流程，可以先回答几件具体的事：输入从哪里来，谁会看结果，哪些内容必须核对，什么情况不能继续。等需要查询外部工具的接口时，再引入相应文档工具。不要为了完成一段本可独立进行的流程梳理，先配置一串暂时用不到的服务。
适配技能时，可以把需求说明写成一个短样本：
工作：把项目例会转写整理成纪要草稿。
输入：完整转写、参会人名单、上次未完成事项。
输出：讨论摘要、已确认决定、待办、待确认问题。
要求：每项决定可追溯到原文；不自动修改任务状态。
结束：保存草稿，并列出仍缺少的资料。
这段说明还不是可执行程序，但已经能让使用者与技能作者讨论同一件事。后面无论选择模型、脚本还是现有工具，都可以围绕这些输入输出逐步实现。
安装时保留自己的版本
仓库提供整体安装与复制技能目录的办法。开始评估时，可以只挑一个技能，把其依赖文件一起放进测试位置，阅读完整内容后再使用。一次引入全部技能，会让触发条件、工具权限和后续更新难以追踪。
改写过的技能应保留来源与所基于的提交版本。把自己的目录、字段映射和流程要求写清楚，避免下一次同步上游时被覆盖。若上游修改了关键步骤，先比较差异，再决定是否采用，而不是每次运行都抓取最新文件并直接执行。
需要外部服务凭据时，使用服务支持的受控配置方式，不把真实密钥写入技能正文，也不把含密钥的命令复制到共享文档。技能文件往往会进入仓库或被多人阅读，其传播范围通常大于单次终端会话。
调用外部系统的动作还应有可检查的结果。例如创建纪要后取得页面标识，重复运行时检查是否已存在；发送通知前确认目标频道和最终文本。否则一次超时后的重试，就可能在团队频道里出现两份同样的通知。
用少量样本决定是否继续投入
第一轮可以准备三份材料：资料完整的常规会议、存在缺口的会议、没有形成明确决定的讨论。分别看草稿是否忠实、缺失是否被指出，以及是否凭空补出任务。检查时回到原文，不以标题齐全或语气专业作为通过标准。
再记录人工修改所花的时间。如果最费力的部分仍然是逐条纠正虚构的负责人，应该先改输入与事实提取；如果内容没问题，只是反复调整格式，就适合增加确定性的模板或脚本。不要在不知道瓶颈在哪里时，继续增加更多技能。
一段时间后，这个流程也许只保留上游的几条检查规则，其余已经变成自己的文件组织和团队约定。这很正常。开源技能提供了可读的起点，日常反复使用的版本，需要贴合自己的资料、工具和交付标准。能可靠完成一项经常发生的工作，就已经值得留下。