mcpField
Y
yzr-skill-creator

yzr-skill-creator

github.com/yzr95924Agent 工作流0105 次安装1 周前更新
代码仓库

关于 yzr-skill-creator

yzr-skill-creator 是用于创建、改进和审计 Agent skill 的工作指南，面向维护 skill 的 Agent。它按任务类型分流，并规定评估、授权与交付流程。

主要功能

  1. 01从零创建 skill
  2. 02区分单点与行为性改进
  3. 03单独处理 description 优化
  4. 04按原则审计合规性
  5. 05规定授权与交付流程

适用场景

  1. 01搭建新的 skill 目录
  2. 02修正文案或调整 skill 行为
  3. 03优化 frontmatter 中的 description
  4. 04检查 skill 是否符合执行原则

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/yzr95924/yzr-skill --skill yzr-skill-creator

安装后在 Claude Code 中输入/yzr-skill-creator确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/
skill-template.md
eval/
evals.json
trigger_eval.json
ref/
audit-workflow.md
create-workflow.md
description-workflow.md
improve-workflow.md
schemas.md
ref/agents/
grader.md
tests/
_fixtures.py
smoke_test_anchor_health.py
smoke_test_apply_description.py
smoke_test_audit_rules.py
smoke_test_desc_eval.py
smoke_test_eval_init.py
smoke_test_eval_prep.py
smoke_test_eval_report.py
smoke_test_frontmatter.py
smoke_test_python_style.py
smoke_test_verify.py
tools/
__init__.py
audit_prose.py
check_anchor_health.py
check_python_style.py
check_skill_dependencies.py
desc_eval.py
eval_init.py
eval_prep.py
eval_report.py
quick_validate.py

详细介绍

来自项目 README

yzr-skill-creator

入口

先归类，再动手，执行流程见章节

  1. 创建一个 skill：从零做
  2. 改进 skill：先分单点（正文措辞 / typo / 指称 / 注释）与行为性（规则 / 流程 / 脚本行为 / 新增功能）
  3. description 优化：凡改动触及 frontmatter 的 description（无论意图是触发准确率还是措辞），一律走本入口
  4. 原则校验：审计合规性（只报告）

分流：

  • 用户说"优化描述"而对象不明时，默认泛指（正文措辞与结构）走入口 2，点名 frontmatter 才走入口 3
  • 一次请求同时涉及正文与 description 时，先 2 后 3，不混进同一轮评估

输入与输出

入口交付
1. 创建一个 skill收敛后的完整 skill 目录
2. 改进 skill单点：改后文件 + verify 全绿 + 分类汇报；行为性：另加 workspace 评估产物（见 ref/improve-workflow.md）
3. description 优化用户确认后写回的新 description（附 before/after 触发分数）
4. 原则校验对话内逐条结论 + 证据 + 建议修法

执行原则

  1. 每行自证：改动触及的每段问"删掉它，称职 agent 会做错吗"，不会则删或下放；新增内容须有实录失败支撑，并经用户点头，不预堵假想漏洞
  2. 归位：路由节只装分类判据与指针，不装执行流；闸门 / 纪律句放在它保护的流程入口处；正文只留判断、路由、闸门、 调用契约与"为什么"。执行细节超一屏、被多处共读、或被脚本按节抽取，三者居其一才独立 ref/ 文件，否则留在对应工作流节
  3. 机械操作归脚本：任何内容先问"能用脚本钉死吗"：能机械执行的一律用脚本实现，不靠文字约束；机制靠代码自描述 （命名 / 结构 / --help），docstring 与 md 都不重述机制；脚本是执行黑盒，md 内容类别按"归位"白名单且调用契约 给全（何时调、怎么调），执行 agent 被逼去读源码才能调对 = md 缺陷
  4. 双读者：正文指导 agent 执行，不是用户手册；写每段前先考虑能否指导 agent 执行，再考虑用户后期好不好维护
  5. 写类不写例：用户反馈只覆盖个别场景，正文要对一类请求成立；把反馈落成正文前，先归纳它指向哪一类请求，对类写规则，不把个案抄进正文
  6. 单一源与统一命名：一件事只在一个地方描述，其他地方最多是引用；相同概念全程用同一个名称
  7. 交付纪律：门禁全绿只证形式，不证内容正确；一批改动（触及多节 / 多文件 / 同措辞多处）在 diff 视野下有盲区。交付前主动提议对目标 skill 全文审计（机制层走原则校验，散文层转 yzr-writing-review），用户点头才执行；单点编辑豁免
  8. 整文件夹改动面：任何入口的改动面都是整个 skill 文件夹，不只 SKILL.md

工作流

创建一个 skill

先 Read ref/create-workflow.md 再动手（访谈、裸跑、起草、测试、评估）

改进 skill

授权闸门（行为性）：先问用户是否跑评估循环，不点头不跑、不静默省掉评估；创建场景已有"测试用例先确认"步作隐性授权，改进场景无此嵌入点才显式问。先 Read ref/improve-workflow.md 再动手

description 优化

授权闸门：用户确认后才写回；无触发回归才写回。先 Read ref/description-workflow.md 再动手

原则校验

只审计、不改写（要修由用户点头转入口 2）；散文质量不在此审，转 yzr-writing-review。先 Read ref/audit-workflow.md 再动手

评论

支持 Markdown