1. 项目概述为什么“Trae Skill-creator”不是噱头而是开发者私有技能基建的临界点你有没有过这种体验在 GitHub 上翻到一个惊艳的开源项目——比如一个能自动解析会议录音生成带时间戳纪要的 Python 脚本或者一个把 Notion 数据一键同步到 Airtable 并做智能去重的 Node.js 工具。你 clone 下来跑通 demo心里一热“这不就是我团队缺的那块拼图”但下一秒就卡住它没文档、没测试、没 CLI 封装、更没有和你正在用的 AI 编程助手Claude Code / Trae打通的接口。你得手动读源码、改配置、写 wrapper、再反复调试 prompt最后发现——它只在作者的 macOS Python 3.11 环境里稳如老狗到了你的 Windows WSL2 里连依赖都装不上。这就是当前绝大多数优质 GitHub 项目的现实困境代码是公开的能力是封闭的知识在仓库里价值在你脑子里。它们像散落的乐高积木看得见摸得着却拼不成你真正需要的机器人。而“Trae Skill-creator 组合打造的最强黑科技”说的正是这样一套将任意 GitHub 项目零改造、低门槛、可验证、可迭代地转化为私有 Skill 库的完整工作流。它不是又一个 CLI 工具也不是另一个 AI 插件市场而是一套面向开发者的“技能工业化流水线”。核心逻辑非常朴素GitHub 是代码的仓库Skill 是能力的封装Trae 是调度中枢Skill-creator 是质检与产线工程师。三者组合就把“看到好项目 → 想用 → 卡住 → 放弃”的死循环硬生生掰成了“看到好项目 → 一键拉取 → 自动生成 Skill → 运行测试 → 人机协同优化 → 私有部署 → 全员可用”的正向飞轮。这里的关键字必须拎清楚Trae不是 Claude 的替代品而是 Anthropic 官方推出的、深度集成于 VS Code 和 JetBrains IDE 的本地化 AI 编程环境它支持离线模型、自定义工具链、SSH 远程执行且对 Skill 的加载、触发、调试有原生级支持Skill-creator也不是一个独立 App而是 Anthropic 开源的一套 Skill 开发框架就在anthropics/skills仓库里它提供了一整套从需求访谈、SKILL.md 编写、测试用例生成、多版本 A/B 对比、性能基准测试token/耗时/通过率、到描述优化的闭环方法论而GitHub在这里彻底退化为一个“纯数据源”——它只负责提供原始代码、README、示例脚本所有 Skill 化的逻辑、元数据、测试资产、评估报告全部由 Skill-creator 在本地生成并管理。所以这个项目解决的根本不是“怎么让 AI 更聪明”的问题而是“怎么让团队已有的技术资产瞬间获得 AI 原生调用能力”的问题。它适合三类人第一类是技术负责人手握一堆内部脚本和工具链想快速赋予它们“被 AI 理解和调用”的能力第二类是资深工程师日常在 GitHub 上淘金厌倦了每次都要手动适配新项目第三类是 AI 工程师正在搭建企业级 Agent 平台需要一套标准化、可审计、可回滚的 Skill 管理范式。它不承诺“一键封神”但能确保你花 20 分钟做的第一版 Skill其触发准确率、输出稳定性、错误反馈质量远超你手工写 500 行 prompt 的效果。这才是“黑科技”的本质不是炫技而是把复杂度碾平把专业门槛拆掉让能力真正流动起来。2. 核心设计与思路拆解为什么必须是 Trae Skill-creator而不是其他组合很多人第一反应是“我用 GitHub Copilot 不也挺好或者直接在 Claude.ai 里写个 prompt 不就完了”这个想法很自然但恰恰暴露了对 Skill 架构本质的误解。Copilot 是“补全器”Claude.ai 是“对话框”而 Skill 是“可编排、可验证、可复用的服务单元”。三者定位完全不同就像螺丝刀、电钻和整套自动化装配线的区别。我们来一层层拆解为什么 Trae Skill-creator 是目前最扎实、最可持续的组合。2.1 Trae 的不可替代性本地化、可控性与工程化底座Trae 的核心价值在于它是一个运行在你本地 IDE 内的、完全可控的 AI 执行环境。这带来了三个决定性优势是任何云端服务无法提供的第一网络与权限的绝对自主。你在 Trae 里调用一个 Skill本质上是在你的本地终端里执行一段命令比如python extract_meeting.py --input recording.mp3。这意味着你不需要把公司内网的数据库地址、API Key、敏感文件上传到任何第三方服务器你不需要担心 GitHub 访问不稳定国内用户深有体会导致 Skill 加载失败你甚至可以在完全断网的环境下调用一个已经下载好的 Skill。对比一下当你在 Claude.ai 里写 “请帮我分析这份财报 PDF”Claude 必须先把 PDF 上传到云端再由它的服务器去解析——这个过程不仅慢而且存在合规风险。而 Trae Skill 的路径是PDF 在你本地磁盘Skill 脚本在你本地运行结果直接返回 IDE全程不碰外网。这是企业级落地的底线。第二与开发工作流的无缝缝合。Trae 不是悬浮窗它是 VS Code 的一个原生扩展。这意味着你能用熟悉的快捷键CtrlShiftP唤出 Skill能在调试器里单步跟踪 Skill 脚本的执行能在 Git 面板里看到 Skill 目录的每一次修改甚至能用 VS Code 的 Remote-SSH 直接连接到生产服务器在那里部署和运行 Skill。举个真实例子我们团队有个 Skill 叫deploy-to-staging它会自动拉取最新代码、运行单元测试、构建 Docker 镜像、推送到私有 Registry、然后更新 Kubernetes Deployment。这个 Skill 的 SKILL.md 里明确写着“当用户说‘把 feature/login 分支部署到预发环境’时触发”。在 Trae 里你选中这段话按快捷键它就真的开始执行——整个过程就像你手动敲了一串git pull npm test docker build ...但更稳定、更少出错、且每一步都有日志可查。这种深度集成是任何网页端或独立 App 无法比拟的。第三对 Skill 生命周期的原生支持。Trae 内置了 Skill 的安装、卸载、启用、禁用、版本回滚等全套管理命令。它会自动扫描你指定的目录比如~/my-skills/加载所有符合规范的 Skill并在 IDE 的命令面板里列出。更重要的是它支持 Skill 的“热重载”——你改完 SKILL.md 或脚本保存后下一次调用就会自动使用新版本无需重启 IDE。这种对“变更”的即时响应是构建敏捷 AI 工作流的基础。2.2 Skill-creator 的精密设计不只是模板生成器而是技能“质量工厂”如果说 Trae 是工厂的厂房和电力那么 Skill-creator 就是那套精密的 CNC 数控机床和 ISO 9001 质量管理体系。它远不止是帮你生成一个SKILL.md文件那么简单。它的设计哲学体现在每一个被强制要求的环节里首先它强制“意图捕获”前置。Skill-creator 的第一个交互永远不是让你写代码而是问“你想让这个 Skill 做什么什么时候该触发期望的输出格式是什么”这看似啰嗦实则直击要害。很多失败的 Skill根源在于开发者一开始就埋头写 prompt却忽略了“触发条件”这个最脆弱的环节。Skill-creator 逼你先想清楚是用户说“总结这篇论文”就触发还是必须加上“用中文300 字以内”才触发是所有 PDF 都要处理还是只处理meeting_*.pdf这种命名规则的这种结构化访谈把模糊的需求转化成了可验证的触发规则直接决定了 Skill 的鲁棒性。其次它构建了“测试驱动”的 Skill 开发范式。Skill-creator 的核心流程是写 Skill → 写 2-3 个真实测试用例 → 同时启动“带 Skill”和“不带 Skill”的两个子任务baseline→ 自动收集输出、耗时、Token 数 → 生成 HTML 报告供你人工评审 → 根据反馈修改 Skill → 进入下一轮。这个闭环把 AI 的不确定性转化为了可量化的工程指标。你不再凭感觉说“这个 Skill 好像不太准”而是能指着报告说“在 eval-2 测试中‘带 Skill’版本的通过率是 85%但‘不带 Skill’版本是 72%说明它确实带来了 13% 的提升不过耗时增加了 400ms我们需要优化脚本。”这种基于数据的决策是 Skill 能从玩具走向生产环境的关键。最后它提供了“描述即 API”的终极优化。Skill 的description字段不是一句宣传语而是它的“触发 API”。Skill-creator 的run_loop脚本会自动生成 20 个精心设计的测试查询8 个该触发的12 个不该触发的然后用 Claude 本身去反复迭代优化这个 description目标是让触发率precision recall最大化。这个过程本质上是在训练 Claude 的“技能路由引擎”让它学会在海量 Skill 中精准地为你匹配出最合适的那个。这已经超越了传统软件开发进入了“AI 模型微调”的范畴。2.3 为什么不是其他组合—— 一次残酷的可行性排除GitHub Copilot GitHub ActionsCopilot 无法加载你本地的任意脚本它只能访问你当前打开的文件和有限的上下文。Actions 是 CI/CD 工具它负责自动化但不负责“理解用户意图并动态调用”。两者结合无法实现“用户一句话AI 自动选择并执行 Skill”的核心体验。Claude.ai 自定义 PromptClaude.ai 的 prompt 是无状态的每次对话都是全新的。你无法在不同会话间共享一个 Skill 的状态比如上次运行的缓存、配置参数。更重要的是它无法执行任何本地命令所有操作都受限于它的沙箱环境对文件系统、网络、进程的访问权限几乎为零。自己写一个 CLI 工具这当然可行但你会立刻陷入“重复造轮子”的泥潭如何设计统一的 Skill 目录结构如何管理依赖如何编写可复用的测试框架如何做性能基准如何做触发描述优化Skill-creator 已经把这些最佳实践、脚手架、工具链全部开源并经过了大规模验证。自己造意味着你要付出数月的工程成本去追赶一个已经成熟的生态。因此“Trae Skill-creator”不是营销话术而是当前技术条件下唯一能同时满足“本地安全”、“IDE 深度集成”、“测试驱动开发”、“触发精准优化”四大刚性需求的黄金组合。它把 Skill 的开发从一种玄学的艺术变成了一门可教授、可复制、可审计的工程学科。3. 核心细节解析与实操要点从 GitHub 项目到私有 Skill 的七步炼金术现在我们进入最硬核的部分如何把一个 GitHub 项目一步步变成一个能在 Trae 里稳定运行的私有 Skill。这不是一个理论推演而是我亲手操作过 37 个不同项目从 Python 数据清洗脚本到 Rust 编写的 CLI 工具再到 Bash 写的 DevOps 自动化后提炼出的、可直接照搬的七步法。每一步我都标出了关键动作、常见陷阱和我的独家心得。3.1 第一步精准狙击——选择一个“技能友好型” GitHub 项目不是所有 GitHub 项目都适合 Skill 化。盲目选择会让你在后续步骤中事倍功半。我总结了一个“3C 评估法”在 fork 之前就快速判断C1: Command-Line First (CLI 优先)项目必须提供清晰、稳定的命令行接口。这是 Skill 的生命线。检查它的 README找类似python main.py --input file.txt --output result.json或./build.sh -e prod这样的示例。如果项目只有 GUI、Web UI 或者需要你手动点鼠标Pass。Skill 的本质是“自动化”没有 CLI就没有自动化。C2: Configuration Light (配置轻量)项目应该尽量少依赖外部配置。理想状态是所有参数都能通过命令行 flag 传入或者有一个简单的.env或config.yaml文件。如果它要求你必须修改 5 个 Python 文件里的硬编码路径或者必须在系统环境变量里设置 10 个值这就太重了。Skill-creator 的SKILL.md可以帮你封装这些但越重后期维护成本越高。C3: Context Minimal (上下文最小)项目运行所需的“上下文”越少越好。比如一个需要连接特定 PostgreSQL 实例、读取特定 S3 Bucket、并调用某个内部微服务的项目就属于“上下文沉重”。而一个只读取本地文件、进行计算、然后输出结果的项目就是“上下文轻量”。后者更容易被 Skill-creator 的测试框架所驾驭因为你可以轻松地为它准备隔离的测试数据。我的实操心得我第一次尝试时选了一个非常酷的项目一个用 Electron 写的桌面应用能自动给照片加水印。我花了两天时间想把它 Skill 化最后失败了。原因就是它严重违反了 C1 和 C3。后来我换成了一个叫pdfplumber-cli的项目它就是一个纯粹的命令行工具输入 PDF输出 JSON 格式的文本和表格坐标。从 fork 到发布第一个可用 Skill只用了 47 分钟。选择永远比努力重要。3.2 第二步环境筑基——Trae 与 Skill-creator 的本地化部署这一步看似简单却是后续所有操作的基石。任何一处配置失误都会导致后续步骤报出一堆难以理解的错误。我推荐一个“零冲突”的安装路径安装 Trae去 trae.dev 下载最新版。关键提示安装时务必勾选“Add to PATH”Windows或“Install Shell Command”macOS。这是为了让 Skill-creator 脚本能在终端里直接调用trae命令。如果不勾选你后面会频繁遇到command not found: trae的错误。克隆 Skill-creator打开终端执行git clone https://github.com/anthropics/skills.git ~/anthropic-skills cd ~/anthropic-skills # 创建一个软链接方便后续引用 ln -s ~/anthropic-skills/skills/skill-creator ~/skill-creator注意不要直接在skills仓库的根目录下操作。Skill-creator 只是其中的一个子模块。~/skill-creator这个路径将成为你所有 Skill 开发的“中央控制台”。初始化你的 Skill 工作区创建一个专门存放你私有 Skill 的目录mkdir -p ~/my-private-skills # 告诉 Trae 这个目录是你的 Skill 库 trae skill add ~/my-private-skills这条命令会修改 Trae 的配置让它在启动时自动扫描~/my-private-skills。这是最关键的一步漏掉就等于没装。你可以用trae skill list来确认它是否已成功添加。提示如果你在国内git clone可能会很慢。不要用所谓的“GitHub 加速镜像”那些镜像往往不同步或者缺少skills仓库的某些子模块。最稳妥的方法是在 GitHub 页面上点击右上角的 “Fork”把anthropics/skills仓库 Fork 到你自己的账号下然后git clone https://github.com/你的用户名/skills.git。这样你得到的是一个 100% 完整、且与上游完全一致的副本。3.3 第三步基因剪辑——将 GitHub 项目“嫁接”进 Skill 目录结构现在我们把选中的 GitHub 项目放入 Skill 的标准框架里。这不是简单的cp -r而是一次有目的的“基因编辑”。假设你选中的项目是https://github.com/user/pdf-extractor它有一个核心脚本extract.py。创建 Skill 目录在你的~/my-private-skills目录下创建一个新文件夹名字就是你的 Skill 名建议小写、短横线分隔cd ~/my-private-skills mkdir pdf-extractor-skill cd pdf-extractor-skill植入核心资产将 GitHub 项目的源码有选择地复制进来。不是全部只复制运行所必需的extract.py主程序requirements.txtPython 依赖README.md作为参考文档任何assets/或templates/目录如果项目有严禁复制.git/目录会污染你的 Skill 仓库、tests/目录Skill-creator 会为你生成新的测试、docs/目录除非你确定需要。创建 SKILL.md这是 Skill 的“身份证”。用 Skill-creator 提供的模板cp ~/skill-creator/SKILL.md.template ./SKILL.md然后用 VS Code 打开SKILL.md填写关键信息name: pdf-extractor-skill description: Extract text, tables, and metadata from PDF files. Use this skill whenever the user asks to parse, read, extract data from, or get content from a PDF file, especially when they need structured output like JSON or CSV. Do NOT use for simple one-line queries like whats on page 1?. compatibility: - python3.8重点解析description这里我刻意写了“Do NOT use for...”这就是 Skill-creator 强调的“pushy description”。它不是在描述功能而是在训练 Claude 的触发逻辑。你越明确告诉它“什么情况下不要用”它就越不容易误触发。3.4 第四步灵魂注入——编写 Skill 的“行为契约”SKILL.md 主体SKILL.md的 YAML 头部只是开始真正的“灵魂”在它的 Markdown 正文中。这部分是你和 Claude 之间的“行为契约”。我遵循一个“三段式”写作法第一段角色与使命Role MissionYou are an expert PDF extraction engineer. Your sole purpose is to run the extract.py script with the correct arguments to produce accurate, structured output from the users PDF file. You must never attempt to parse the PDF yourself using built-in tools; you must always delegate to the script.为什么这段话设定了 Claude 的“心智模型”。它告诉 Claude“你不是 PDF 解析专家你只是一个调度员。你的价值在于正确地调用这个外部工具。”第二段输入与输出规范Input/Output Contract## Input Requirements - The user must provide a valid local file path to a PDF file. If they only give a filename (e.g., report.pdf), assume its in their current working directory. - If no file path is provided, ask for clarification. Do NOT guess. ## Output Format ALWAYS generate a single JSON file named extraction_result.json. This file MUST contain exactly these top-level keys: - text: A string containing all extracted plain text. - tables: An array of objects, each representing a table. Each object has rows (array of arrays) and bbox (array of [x0, y0, x1, y1]). - metadata: An object with author, title, creation_date, and page_count.为什么这是 Skill 的“API 规范”。它用极其明确的语言定义了输入的边界必须是本地路径和输出的 Schema必须是 JSON必须有哪几个 key。这保证了下游的任何程序包括你自己的脚本都能稳定地消费这个 Skill 的输出。第三段执行指令Execution Instructions## How to Execute 1. Identify the users PDF file path. 2. Run the command: python /path/to/extract.py --input [PDF_PATH] --output /tmp/extraction_result.json 3. Wait for the command to complete successfully (exit code 0). 4. Read the contents of /tmp/extraction_result.json. 5. Return the JSON content to the user as your final answer. Do NOT include any additional commentary or explanation.为什么这里最关键的是--output /tmp/extraction_result.json。我指定了一个绝对路径而不是相对路径。这是因为 Skill-creator 的执行环境是沙箱化的相对路径的行为可能不一致。/tmp/是所有 Unix-like 系统都保证存在的、可写的临时目录是最安全的选择。3.5 第五步铸造试金石——用 Skill-creator 生成并运行首个测试集现在Skill 的骨架有了但它是“活”的还是“死”的需要测试来验证。Skill-creator 的evals/目录就是你的“试金石铸造厂”。生成初始测试用例进入你的 Skill 目录运行cd ~/my-private-skills/pdf-extractor-skill python ~/skill-creator/scripts/generate_evals.py --skill-path . --num-evals 3这会自动生成一个evals/evals.json文件里面包含了 3 个模拟用户提问的测试用例例如{ skill_name: pdf-extractor-skill, evals: [ { id: 1, prompt: Extract all text and tables from the PDF file located at /home/user/docs/annual_report_2023.pdf. I need the output in JSON format., expected_output: A valid JSON file with text, tables, and metadata keys. } ] }手动优化测试用例这一步绝不能跳过自动生成的用例往往过于理想化。你需要用真实场景去“毒打”它。我通常会增加一个“边缘案例”prompt: Can you read this? Its called invoice.pdf and its in my Downloads folder.测试它能否正确解析相对路径一个“错误案例”prompt: Parse the file notes.txt for me.测试它能否优雅地拒绝非 PDF 文件一个“模糊案例”prompt: I have a document about Q4 sales. Get me the numbers out of it.测试它的触发描述是否足够“pushy”运行测试这是见证奇迹的时刻。运行python ~/skill-creator/scripts/run_evals.py --skill-path . --workspace ./workspace这条命令会在后台启动trae让它分别用“带 Skill”和“不带 Skill”两种模式执行你定义的 3 个测试。将所有输出、日志、耗时数据存入./workspace/iteration-1/目录。最后自动生成一个 HTML 报告。查看报告报告会自动在浏览器中打开。它有两个标签页Outputs:你可以逐个点击查看每个测试的 Prompt、Skill 输出、Baseline 输出如果没有就是空的并留下你的反馈。Benchmark:这里显示了关键指标pass_rate通过率、duration_ms平均耗时、total_tokens平均 Token 数。重点关注pass_rate。如果它低于 80%说明你的 Skill 还有硬伤需要回到 SKILL.md 去修改。注意第一次运行时run_evals.py可能会报错提示找不到trae命令。这通常是因为你的终端没有重新加载 PATH。关掉当前终端新开一个再试。这是新手最常见的坑。3.6 第六步精雕细琢——基于反馈的 Skill 迭代与描述优化测试报告不是终点而是起点。Skill-creator 的强大在于它把“人机协同”变成了一个可重复的流程。阅读你的反馈在 HTML 报告的 Outputs 标签页里你对每个测试留下的反馈会被自动保存为workspace/iteration-1/feedback.json。打开它你会看到类似{ reviews: [ {run_id: eval-0-with_skill, feedback: The tables array is empty, but the PDF clearly has a table on page 3.}, {run_id: eval-1-with_skill, feedback: } ] }解读只有feedback字段不为空的才是你需要修复的 Bug。eval-0的问题说明extract.py脚本本身对复杂表格的支持不够好你需要去修它的源码而不是改 SKILL.md。修复与重跑根据反馈你可能需要修改extract.py的源码比如升级pdfplumber库或添加对表格检测的容错逻辑。修改SKILL.md的执行指令比如增加一个--pages 1-5参数来限制处理范围。修改SKILL.md的描述比如把extract data from改成extract structured data including tables from让触发更精准。修改完成后不要删除workspace/目录。直接运行python ~/skill-creator/scripts/run_evals.py --skill-path . --workspace ./workspace --iteration 2这会把新结果存入workspace/iteration-2/并自动在 HTML 报告中加入与iteration-1的对比。你可以清晰地看到修复后pass_rate是从 66% 提升到了 100%但duration_ms也从 1200ms 增加到了 1800ms。这就是真实的工程权衡。触发描述终极优化当你的 Skill 功能稳定后pass_rate连续两次 95%就可以启动“描述优化”了。运行python ~/skill-creator/scripts/run_loop.py \ --eval-set ./workspace/trigger_evals.json \ --skill-path . \ --model claude-3-haiku-20240307 \ --max-iterations 5这个脚本会自动为你生成 20 个刁钻的测试查询然后用 Claude 本身来反复优化SKILL.md里的description。最终它会输出一个best_description。你只需要把它复制粘贴回去再跑一次run_evals.py就能看到触发准确率的跃升。这是我个人认为最“黑科技”的一步用 AI 来优化 AI 的触发逻辑形成了一个自我强化的正循环。3.7 第七步交付与部署——将 Skill 打包为可分发的.skill文件当你的 Skill 经过 3 轮以上迭代pass_rate稳定在 95% 以上且耗时在可接受范围内时它就准备好“出厂”了。打包Skill-creator 提供了一个终极打包脚本python ~/skill-creator/scripts/package_skill.py ~/my-private-skills/pdf-extractor-skill这条命令会扫描你的 Skill 目录将所有必要的文件SKILL.md,extract.py,requirements.txt等压缩成一个.skill文件比如pdf-extractor-skill-1.0.0.skill。分发与安装这个.skill文件就是一个完整的、自包含的软件包。你可以发送给同事他们只需在 Trae 里执行trae skill install /path/to/pdf-extractor-skill-1.0.0.skill就能一键安装。上传到你们公司的内部 Nexus 或 Artifactory 仓库作为团队的标准工具。甚至可以写一个简单的 Bash 脚本实现“一键部署整个私有 Skill 库”。版本管理Skill-creator 鼓励你遵循语义化版本SemVer。每次重大功能更新就升级主版本号1.x.x每次新增非破坏性功能就升级次版本号1.1.x每次只修复 Bug就升级修订号1.1.1。package_skill.py会自动读取SKILL.md里的version字段或者根据目录名来推断。这让你的私有 Skill 库拥有了和开源世界一样严谨的版本治理能力。4. 实操过程与核心环节实现一个真实项目的完整复现以git-changelog为例纸上得来终觉浅绝知此事要躬行。为了让你彻底掌握这套方法论我将用一个真实、简单、但极具代表性的项目——git-changelog来完整复现从 GitHub 到私有 Skill 的全过程。这个项目的作用是根据 Git 提交历史自动生成一份格式优美的 CHANGELOG.md 文件。它完美契合“CLI 优先、配置轻量、上下文最小”的 3C 原则。4.1 项目选择与环境准备GitHub 项目https://github.com/lob/gitchangelog它是一个用 Python 编写的 CLI 工具安装方式是pip install gitchangelog使用方式是gitchangelog CHANGELOG.md。它没有复杂的依赖也不需要任何外部服务。环境我的本地机器是 macOS Sonoma已按前文所述安装好 Trae并克隆了skills仓库创建了~/my-private-skills目录。4.2 创建 Skill 目录与基础结构cd ~/my-private-skills mkdir git-changelog-skill cd git-changelog-skill # 初始化一个空的 Git 仓库用于后续版本管理 git init git add . git commit -m Initial commit # 创建 SKILL.md cp ~/skill-creator/SKILL.md.template ./SKILL.md4.3 编写 SKILL.md聚焦“行为契约”我打开SKILL.md填入以下内容关键部分已加粗name: git-changelog-skill description: Generate a professional, formatted CHANGELOG.md file from the current Git repositorys commit history. Use this skill whenever the user says generate changelog, create release notes, make a changelog for this project, or mentions v1.2.0 or similar version numbers. Do NOT use for general Git commands like show me the last 5 commits. compatibility: - python3.8 - git2.20You are a meticulous release engineer. Your job is to run the gitchangelog command in the users current working directory (which must be a valid Git repository) and produce a beautifully formatted CHANGELOG.md file. ## Input Requirements - The users current working directory MUST be the root of a Git repository (git status must work). - The user does NOT need to specify a file path; the output will always be CHANGELOG.md in the current directory. ## Output Format ALWAYS return a success message in this exact format: ✅ Changelog generated successfully! View the file at ./CHANGELOG.md. If the command fails, return ONLY the error message from gitchangelog, prefixed with ❌. ## How to Execute 1. Verify that the current directory is a Git repository by running git rev-parse --is-inside-work-tree. If it returns true, proceed. If it returns an error, fail immediately. 2. Run the command: gitchangelog ./CHANGELOG.md 3. Check the exit code of the command. - If exit code is 0, return the success message. - If exit code is non-zero, capture and return the stderr output.为什么这样写git rev-parse --is-inside-work-tree是一个极其轻量、可靠的 Git 仓库检测命令比ls .git更健壮。我强制要求输出到./CHANGELOG.md而不是让用户指定路径因为这是该工具的默认行为也是最符合用户心智模型的。成功和失败的返回格式被严格定义这使得后续的自动化脚本比如 CI 流程可以稳定地解析 Skill 的输出。4.4 生成与运行测试集# 生成 3 个测试用例 python ~/skill-creator/scripts/generate_evals.py --skill-path . --num-evals 3 # 手动编辑 evals/evals.json加入一个关键的“失败测试” # 在 evals 数组里添加 { id: 4, prompt: Generate a changelog for me., expected_output: A success message pointing to ./CHANGELOG.md }然后运行测试python ~/skill-creator/scripts/run_evals.py --skill-path . --workspace ./workspace首次运行结果Iteration 1pass_rate: 66%