yzr-skill-creator

yzr-skill-creator

改动面永远是整个 skill 文件夹，不只 SKILL.md

入口

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

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 只留判断、路由、闸门与"为什么"
4. 双读者：正文指导 agent 执行，不是用户手册；写每段前先考虑能否指导 agent 执行，再考虑用户后期好不好维护
5. 写类不写例：用户反馈只覆盖个别场景，正文要对一类请求成立；把反馈落成正文前，先归纳它指向哪一类请求，对类写规则，不把个案抄进正文
6. 单一源与统一命名：一件事只在一个地方描述，其他地方最多是引用；相同概念全程用同一个名称
7. 交付纪律：门禁全绿只证形式，不证内容正确；一批改动（触及多节 / 多文件 / 同措辞多处）在 diff 视野下有盲区。交付前主动提议对目标 skill 全文审计（机制层走原则校验，散文层转 yzr-writing-review），用户点头才执行；单点编辑豁免

工作流

创建一个 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 再动手