| name | simple-skill-creator |
| description | 创建、编辑或改进 AI Skill 的 meta-agent。以下场景必须触发本 skill，不得自行处理： 1. 用户要求创建新 skill； 2. 用户要求打开网页编辑器查看或编辑某个 SKILL.md（唯一方式是运行 serve_skill.py，Agent 不得仅描述内容或让用户自行打开）； 3. 用户要求根据任务轨迹改进已有 skill（启动 diff_skill.py 进行逐条审阅）； 4. 用户提到"skill 编辑器"、"预览 skill"、"修改 SKILL.md" 等。
|
Agile Skill Creator
重要：如果用户要求"打开网页编辑器"或"查看/编辑某个 SKILL.md"，必须直接执行路径 A 的 A4 步骤（运行 serve_skill.py），不得仅描述 SKILL.md 内容后让用户自行处理。
你是一个帮助用户构建自定义 Skill 的 meta-agent，支持两条工作路径：
- 新 Skill：对话起草 → 网页编辑确认 → 完成
- 改进已有 Skill：分析任务轨迹 → 生成改进版 → 逐条审阅变更 → 写回
目录结构
simple-skill-creator/
├── SKILL.md
└── scripts/
├── quick_validate.py ← 格式验证（name/description/frontmatter 合法性）
├── serve_skill.py ← 网页编辑器（左侧编辑 + 右侧预览 + 保存）
└── diff_skill.py ← 变更审阅器（逐条 Accept/Reject + 写回）
路径 A：创建新 Skill
A1. 需求探索
不要立即写 SKILL，先通过对话收集：
- 这个 Skill 要让 Claude 能做什么？输入和预期输出是什么？
- 什么情况下应该触发它？
- 是否依赖特定工具、MCP server 或执行环境？
- 若需求模糊，提 1-2 个针对性问题，等用户确认后再进入下一步
A2. 起草 SKILL.md（渐进式加载结构）
Metadata（frontmatter）
name：kebab-case，≤ 64 字符description：触发时机 + 功能描述，≤ 1024 字符，不含 <>。写得具体，让 Claude 明确知道何时调用
Core Logic（正文，≤ 500 行）
- 用祈使句写指令；解释"为什么"而不是堆砌 MUST/NEVER
- 定义清晰的输出格式（用模板或示例）
Bundled Resources（按需加载）
scripts/：确定性脚本（避免每次重写）references/：大型参考文档templates/：INCAR 模板、文档模板等
A3. 格式验证
草稿写入文件后，先快速验证格式是否合法：
python scripts/quick_validate.py <skill目录>
若输出 ✗ 错误，根据提示修正（常见问题：name 含大写或空格、description 超过 1024 字符、frontmatter 含非法字段）。验证通过后再启动编辑器。
A4. 启动网页编辑器
验证通过后，你必须实际调用 Bash 工具执行以下命令，不得假设已执行或直接声称已启动。
BASE_DIR 来自 Skill 加载时第一行显示的 Base directory for this skill: ...。
BASE_DIR=<从加载信息中读取的 Base directory>
TARGET_SKILL_DIR=<目标 skill 目录路径>
nohup python "$BASE_DIR/scripts/serve_skill.py" "$TARGET_SKILL_DIR" > /tmp/skill_view.log 2>&1 &
sleep 2 && grep '^URL=' /tmp/skill_view.log
必须验证：若 grep 有输出（如 URL=http://...），说明启动成功，将该 URL 告知用户；若输出为空，说明启动失败，执行 cat /tmp/skill_view.log 排查原因后重试。
向用户说明：
- 左侧可直接编辑 Markdown，右侧实时预览
- Ctrl+S 或点击"保存"写回文件
- 编辑完成后告知 Agent，Agent 可以继续读取最新版本
SSH 远程用户：需先在本地开启端口转发
ssh -L 8700:localhost:8700 user@server，再访问 http://localhost:8700
等待用户反馈，根据文字反馈补充调整后，询问是否需要测试验证。若不需要，跳到 A5。
A5.（可选）测试验证
若用户希望测试：让用户提供一个真实测试场景，按照 SKILL 指令执行，向用户展示输出，收集反馈，重复直到满意。
A6. 收尾
kill $(grep '^PID=' /tmp/skill_view.log | cut -d= -f2) 2>/dev/null
告知用户最终 SKILL 的位置。
路径 B：根据任务轨迹改进已有 Skill
适用场景：用户用某个 Skill 完成了一次任务，希望把执行中遇到的问题、规避方案、注意事项补充进 Skill。
B1. 读取旧 SKILL 和轨迹
SKILL_DIR=<skill目录路径>
TRAJ_FILE=<轨迹文件路径>
读取 $SKILL_DIR/SKILL.md 和轨迹文件内容。
B2. 分析轨迹，生成改进版 SKILL
重点关注：
- 错误和重试：哪些步骤失败了？原因是什么？如何规避？
- 隐式知识：Agent 在执行中"发现"的、但原 SKILL 没有写明的事项
- 冗余步骤：Agent 每次都要从头做的事，是否可以抽象成
scripts/ 中的脚本
改进原则：
- 泛化而非过拟合（不要只针对这一次任务的特定值）
- 精简：删掉在执行中没有实际效果的指令
- 解释原因：把"踩坑经验"转化为 Skill 能理解的"为什么"
快照旧版，将改进版写入 SKILL.md：
SNAPSHOT=/tmp/SKILL_snapshot_$(date +%s).md
cp "$SKILL_DIR/SKILL.md" "$SNAPSHOT"
echo "Snapshot: $SNAPSHOT"
B3. 启动变更审阅器
你必须实际调用 Bash 工具执行以下命令，不得假设已执行或直接声称已启动。
BASE_DIR 来自 Skill 加载时第一行显示的 Base directory for this skill: ...。
BASE_DIR=<从加载信息中读取的 Base directory>
nohup python "$BASE_DIR/scripts/diff_skill.py" \
--old "$SNAPSHOT" \
--new "$SKILL_DIR/SKILL.md" \
--trajectory "$TRAJ_FILE" \
> /tmp/skill_diff.log 2>&1 &
sleep 2 && grep '^URL=' /tmp/skill_diff.log
必须验证：若 grep 有输出，说明启动成功；若输出为空，执行 cat /tmp/skill_diff.log 排查后重试。
将 URL 告知用户，说明审阅界面的使用方式：
- 📝 变更审阅 标签：逐条查看变更（绿色=新增，红色=删除）
- 每条默认为"接受"（绿框）；点击"✗ 拒绝"可拒绝该条
- 点击"应用已接受的变更"将结果写回 SKILL.md
- 📜 执行轨迹 标签：查看完整执行过程，辅助判断变更是否合理
等待用户完成审阅并点击应用。
B4. 确认结果
用户应用后，读取最新的 $SKILL_DIR/SKILL.md 确认写入正确：
kill $(grep '^PID=' /tmp/skill_diff.log | cut -d= -f2) 2>/dev/null
向用户报告改进摘要：接受了几处变更、拒绝了几处、最终 SKILL 文件位置。
通用写作准则
- 可泛化：好的 Skill 处理的是一类问题，不只是用户当前的例子
- description 是触发关键：写得具体但不冗长，让 Claude 能在合适的时机自动调用
- 若多个测试用例都独立产生了类似的辅助脚本，应将其提取到
scripts/ 中统一维护
- VASP / 材料计算类 Skill：须在正文中写明与项目 system_prompt 一致的 ITERATIVE EXECUTION RULE（禁止
for/while 或 monolithic 脚本一次提交多点、多阶段、多目录 VASP；每步单独核查后再继续），并与 Skill run-vasp 的探针、STRICT HARDWARE ALIGNMENT、vasp_runner.py --dirs 分批策略对齐。措辞可参考同仓库 workflow-relax、workflow-electronic-structure、workflow-eos-lattice-constant、research-literature 等已有「执行方式」「核心原则」段落。
