Skill: dazhuangjammy/dazhuangskill-creator (version 1.0.0)

--- name: dazhuangskill-creator description: 用来创建、修改、评估、打包和优化其他 skill。用户提到从零做 skill、把一段工作流程沉淀成 skill、改现有 skill、设计评测、验证 skill 是否真的更好、优化触发描述，或打包交付 skill 时，都应使用这个 skill。 --- # Dazhuangskill Creator 用这个 skill 来创建、重塑、评估、打包其他 skill。把当前 `SKILL.md` 所在目录视为 `<skill-base>`，所有 bundled resources 都从这里解析，不要依赖调用方当前工作目录。 # 核心规则 - 先判断这个 skill 或改动值不值得存在，再决定怎么写。如果拿掉一块不会伤筋动骨，就优先删掉或不要加进去。 - 执行过程中始终显式维护两个状态：`current_path` 和 `current_step`。 - `current_path` 只能是：新建 / 修改 / 评估 / 优化 / 打包 - `current_step` 只能是当前正在执行的 `Step N` - 每次切换分支或进入重型操作前，先复述：当前路径、当前步骤、下一动作 - 如果对话变长、插入大量工具输出、或任务目标变化，先回到 Step 1 重新判路，不要凭惯性继续 - 维持层级分工： - 主 `SKILL.md`：只放耐久规则、默认工作流、工作流内嵌指针 - `references/`：长解释、示例、schema、低频模块说明 - `assets/`：Claude 应该直接使用、复制、填写的模板或文件 - `scripts/`：确定性或重复性执行 - `config.yaml`：人会频繁修改的参数 - 默认路径要轻。不要一上来就跑重型 benchmark、blind comparison 或触发优化，除非用户真的需要这一级证据。 - 默认交付物也要轻。不要因为“以后可能有用”就顺手创建 `evals/`、workspace、`config.yaml`、`agents/openai.yaml`；只有当前任务真的需要，才把它们带进最终 skill。 - skill 内部文件指针默认写成可移植形式，例如 `<skill-base>/references/...`。不要把一次运行中的绝对路径写进最终交付物，除非用户明确要求做成只在当前机器使用的临时版本。 - 文件指针和命令都尽量写死、写全，例如 `cd "<skill-base>" && python3 scripts/...`。 - 根据用户技术水平调整术语密度；必要时简短解释，不要炫术语。 - 修改已有 skill 时，除非用户明确要求，否则保留原名。 - 修改 skill 后，要明确说明：主 body 留了什么、下沉了什么、删了什么。 - 不要把“记住流程”完全寄托在上下文残留上；要用状态播报主动刷新 workflow 锚点。 - 给新 skill 加 `# 索引` 不是默认强制项；只有当复杂度已经高到容易漂移时，才加入一个紧凑索引。 - 如果目标 skill 的默认产物本来就是单个极简结果（例如单行 commit、单条命令、单个标题），就把“默认只输出这一项”写成硬规则，并在最终检查里主动删掉不必要的 body、解释、备选项。 - 如果目标 skill 是 Conventional Commit、单行命令这类极简输出，不要把 body 触发条件写成“有帮助时可加”。要写成更窄的闭集：通常只有明确的 breaking change、迁移/弃用说明，或用户显式要求更多上下文时才允许 body；普通补充细节、测试更新、第二个子动作都不够构成扩写理由。 - 如果目标 skill 属于 Conventional Commit、PR 标题压缩、changelog 单行这类“高压缩判型”输出，而且某个边界误判代价很高，就允许保留 1 个极短 canonical example 或一条写死的边界规则来钉住它。尤其是公开接口变更：旧 public CLI flag / option / env var / config key / API field 只要被拒绝、移除、重命名，或被新名字替代，就按 breaking interface change 处理；默认倾向 `feat(scope)!`，必要时再补一行迁移 body，不要降成普通 `fix`。 # 默认工作流 ## Step 1：先判断当前是什么任务 - 判断当前请求属于哪条路径： - 新建 skill - 修改现有 skill - 评估输出质量 - 优化触发行为 - 打包或交付 skill - 进入这一步时，先设置： - `current_path` = 上面五种路径之一 - `current_step` = `Step 1` - `next_action` = 用一句话说明接下来要做什么 - 如果用户还在探索或讨论阶段，就停留在结构判断/评审模式，不要强行进入实现或重型评测。 - 如果路径不清楚，先做最轻的结构判断，再决定是否继续下钻。 ## Step 2：先定结构，再动笔 - 先确认最小必要信息： 1. 这个 skill 要让 Agent 做什么？ 2. 它应该在什么情况下触发？ 3. 它应该产出什么结果或文件？ 4. 哪些内容必须留在主 body，哪些应该进 `references/`、`assets/`、`scripts/`、`config.yaml`？ 5. 这个 skill 是否需要额外的 `# 索引` 来帮助恢复上下文？ - 进入这一步时，更新： - `current_step` = `Step 2` - `next_action` = 补齐最小必要信息，先定结构再写正文 - 主 body 只保留耐久规则和默认工作流。 - 如果需要展开版写法指南，读 `<skill-base>/references/skill-architecture.md`。 - 如果只是想评审一个现有 skill 是否太胖、太散、太难执行，也先停在这一步，不要过早改写实现细节。 - 如果预计最终 skill 只是单文件、单产物，就先把“不创建额外目录/元数据/评测资产”视为默认方案，除非后面出现明确需求再加。 - 判断新 skill 要不要加 `# 索引` 时，优先看是否至少满足下面两条： - 有 2 条以上路径分流 - 有 3 个以上 `references/`、`agents/`、`scripts/` 指针 - 会出现长工具输出、多轮迭代或批量运行 - 有 Claude.ai / Codex / Cowork 之类的环境分支 - 主 body 已经不是很短的单路径说明 ## Step 3：起草或重写 skill - 进入这一步时，更新： - `current_step` = `Step 3` - `next_action` = 起草或重写最小可用结构 - 新 skill 如果适合先搭脚手架，就执行：`cd "<skill-base>" && python3 scripts/init_skill.py ...` - 改已有 skill 时，优先保留真正承重的结构；把低频细节移到 bundled resources，而不是继续塞胖主 body。 - 长示例、长输出规格、长解释默认不要放在主 body，除非它们又短又关键。 - 如果任务属于“输入很脏、输出很稳”的结构化整理（例如访谈纪要、brief、研究总结），优先考虑补一份短而专的 `references/` 指南，而不是把抽取 heuristics 全塞进主 body。 - 如果这类结构化任务的最终输出本来就有固定章节或固定标题层级，把准确结构下沉到 `<skill-base>/assets/` 模板里，例如直接写死 `## Summary` 这类 heading level；不要只在正文里提章节名，让模型自己猜最终排版。 - 只有当目标交付环境真的需要 OpenAI 界面元数据时，才执行 `cd "<skill-base>" && python3 scripts/generate_openai_yaml.py ...`；不要把它当默认产物。 - 改写时优先让每个 Step 都只回答一件事：现在在哪条路径、下一步做什么、需要读哪个精确文件。 - 如果目标 skill 需要 `# 索引`，就让它只承担“恢复方向”这一件事： - 先复述 `current_path`、`current_step`、`next_action` - 再按当前路径直达精确文件 - 明确写出“索引不替代 workflow” - 如果目标 skill 很短、单路径、资源很少，就不要为了形式统一硬加 `# 索引`。 - 如果目标 skill 的默认交付物应该非常短，就把“什么时候允许扩写”写窄、写死；宁可偏保守，也不要让模型每次都顺手补一段解释或 body。优先写成明确条件列表，不要写成“有帮助时”“必要时补充更多背景”这种开放描述。 - 如果目标 skill 负责输出 Conventional Commit 这类高压缩结果，不要把高代价边界只留在脑补里；至少把反复出错的接口变更判型写死。旧 flag 被拒绝且新 flag 替代旧 flag，属于 breaking interface change，不是普通 `fix`。 ## Step 4：选择最轻但有效的验证路径 - 进入这一步时，更新： - `current_step` = `Step 4` - `next_action` = 选一条最轻但仍可信的验证路径 - 只是讨论结构或架构：直接读文件并做判断。 - 快速体检：执行 `cd "<skill-base>" && python3 scripts/quick_validate.py <skill-dir>`，再配少量真实 prompt 做 sanity check。 - 标准输出质量迭代：读 `<skill-base>/references/eval-loop.md`；如果需要机器写入格式，再读 `<skill-base>/references/schemas.md`。 - 触发优化：读 `<skill-base>/references/description-optimization.md`。 - Blind A/B 对比：读 `<skill-base>/agents/comparator.md` 和 `<skill-base>/agents/analyzer.md`。 - 打包或交付：读 `<skill-base>/references/package-and-present.md`。 - 运行环境不是标准本地 Codex：按需读 `<skill-base>/references/runtime-claude-ai.md` 或 `<skill-base>/references/runtime-cowork.md`。 - 如果只是做轻量 sanity check，不要顺手把 `evals/`、workspace、benchmark 资产写进最终 skill 目录；这些重资产只有在用户真的要评测闭环时才存在。 - 进入任何 benchmark、blind comparison、批量 eval 之前，先做一次状态播报，确认不是因为惯性把任务拉进重路径。 ## Step 5：继续迭代，或者及时停下 - 进入这一步时，更新： - `current_step` = `Step 5` - `next_action` = 判断继续迭代还是停止，并说明理由 - 当 skill 已经足够好，继续加结构也买不来明显收益时，就停下。 - 不要因为“还有一种情况”就继续加规则。只有当新增结构能稳定避免重复失败或重复劳动时，才值得保留。 - 汇报时要说明： - 主 body 现在包含什么 - 哪些内容被下沉 - 哪些内容被删除 - 为什么新结构更轻，但没有丢能力 - 如果目标 skill 的默认输出应该极简，停下前再专门检查一次：最终规则有没有把模型锁回单个结果，实际样例有没有偷偷长出 body、解释或多方案。 - 如果需要继续下一轮，先回到 Step 1 重判当前路径，而不是默认沿用上一轮的惯性路径。 # 索引 - 如果上下文变长、刚看完一大段工具输出、或需要重新找回方向，先复述一次： - `current_path` - `current_step` - `next_action` - 然后按当前路径直达对应材料： - 结构起草或重写：`<skill-base>/references/skill-architecture.md` - 输出质量评测：`<skill-base>/references/eval-loop.md` - 触发描述优化：`<skill-base>/references/description-optimization.md` - 打包与交付：`<skill-base>/references/package-and-present.md` - 环境差异：`<skill-base>/references/runtime-claude-ai.md` 或 `<skill-base>/references/runtime-cowork.md` - 机器写入 schema：`<skill-base>/references/schemas.md` - 专用评测 agents：`<skill-base>/agents/grader.md`、`<skill-base>/agents/comparator.md`、`<skill-base>/agents/analyzer.md` - 这个索引只用来快速恢复上下文，不替代 workflow；真正决定下一步的，仍然是 Step 1 到 Step 5。


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)