dazhuangskill-creator

by dazhuangjammy

Install this Skill

curl -fsSL -o dazhuangskill-creator.zip https://skill.seembox.com/api/v1/skills/dazhuangskill-creator/download && unzip dazhuangskill-creator.zip

Download dazhuangskill-creator.zip

SKILL.md About

---
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。

_meta.json Metadata

{
  "ownerId": "kn74h3g1pqwqcvhabap76gznms822hps",
  "publishedAt": 1775282038296,
  "slug": "dazhuangskill-creator",
  "version": "1.0.0"
}