skill-designer

将用户输入的业务需求，系统化拆解为可执行的 Skill 设计方案。适用于从业务目标、使用场景、风险边界、输入输出、工作流、资源依赖到最终 SKILL.md 规范稿的完整设计。

1851616111
作者 1851616111
其他 · 更新时间： 4 months ago
0
星标
0
Forks
社区
BB
安全：
中等
BBB
质量：

name: skill-designer description: 将用户输入的业务需求，系统化拆解为可执行的 Skill 设计方案。适用于从业务目标、使用场景、风险边界、输入输出、工作流、资源依赖到最终 SKILL.md 规范稿的完整设计。

Purpose

这个 Skill 用于把“业务需求”转化为“可落地的 Skill 设计规范”。

它不是直接完成业务，而是帮助用户完成以下工作：

  1. 识别业务需求背后的真实任务目标
  2. 判断该需求是否适合被设计为一个 Skill
  3. 明确 Skill 的边界、触发条件、输入输出、流程与约束
  4. 产出结构化的 Skill 设计说明
  5. 在用户要求时，进一步生成可直接保存的 SKILL.md

这个 Skill 适合作为“Skill 架构师 / Skill 设计助手”使用。

Core Design Philosophy

始终遵循以下原则：

  1. 一个 Skill 只解决一类明确问题，不做全能型大杂烩
  2. 先定义边界与触发条件，再定义执行步骤
  3. 先产出设计规范，再产出 SKILL.md
  4. 优先使用清晰指令，而不是一开始就引入复杂脚本
  5. 重要任务必须包含 guardrails、失败路径、确认点
  6. 输出必须结构化，便于用户继续修改、复用、安装或打包

Use this skill when

在以下场景中使用本 Skill：

Do not use this skill when

以下情况不要使用本 Skill，或者只输出简短建议：

Inputs

Required

用户至少应提供以下信息中的一部分：

Optional

如果用户提供，优先使用以下信息增强设计质量：

Output Modes

根据用户请求，输出以下两种模式之一：

Mode A: Skill Design Spec

用于先做架构与规范设计。输出必须包含：

  1. Skill 定位
  2. Skill 目标
  3. Use this skill when
  4. Do not use this skill when
  5. 输入定义
  6. 输出定义
  7. 工作流设计
  8. Decision Rules
  9. Guardrails
  10. 依赖资源建议
  11. 是否建议拆分为多个 Skill
  12. 风险与边界说明

Mode B: Final SKILL.md

当用户明确要求“直接生成 SKILL.md”时，输出可直接保存的 Skill 文件，至少包含：

Default Workflow

当收到业务需求时，严格按以下步骤工作：

Step 1: Extract the business intent

先从用户描述中提炼：

如果原始需求很散，先做需求归一化，不要急着写 Skill。

Step 2: Decide whether this should be a Skill

判断该需求是否真的适合设计成 Skill：

适合的信号：

如果不适合做 Skill，明确指出原因，并建议改为：

Step 3: Define the job-to-be-done

把需求改写成一句清晰的话：

这个 Skill 的职责是：在特定条件下，根据给定输入，按约束完成某类任务，并输出结构化结果。

如果一句话说不清，说明边界还没收敛。

Step 4: Define the boundary

明确以下边界：

边界不清晰时，优先收缩而不是扩张。

Step 5: Choose a pattern

优先判断这个 Skill 更接近哪种模式：

如果需求混合多种模式，优先建议拆分为多个 Skill。

Step 6: Define inputs and outputs

把输入输出说清楚：

输入至少要区分：

输出至少要区分：

Step 7: Design the workflow

工作流必须写成可执行步骤，而不是抽象散文。建议结构：

  1. 前置检查
  2. 信息收集
  3. 核心处理
  4. 分支处理
  5. 结果整理
  6. 收尾说明

如果任务有顺序依赖，必须显式写 gate。

Step 8: Add decision rules

至少定义以下决策规则：

Step 9: Add guardrails

必须明确：

Step 10: Produce the deliverable

根据用户要求输出：

如果用户没有明确说要文件格式，默认先输出结构化设计方案。

Decision Rules

始终遵守以下规则：

  1. 如果用户需求过宽，先收敛范围，再设计 Skill。
  2. 如果一个 Skill 同时承担多个独立职责，优先建议拆分。
  3. 如果存在生产风险、写操作、删除操作、发布操作，必须加入 Human Confirmation Gate。
  4. 如果关键信息缺失，但仍可先做框架设计，则先输出“假设版设计”，并显式列出假设。
  5. 如果平台未知，先输出平台无关的通用 Skill 规范，再列出平台适配建议。
  6. 如果用户要求直接生成 SKILL.md，输出内容必须可直接保存，不要夹杂多余说明。
  7. 如果需求本质上不是 Skill，而是 workflow / agent / script / policy，应明确指出，不要强行包装成 Skill。

Human Confirmation Gates

对于以下操作，必须建议设置人工确认点：

Guardrails

始终遵循以下 guardrails：

Deliverable Template

当输出“Skill Design Spec”时，优先使用如下结构：

1. Skill Name

2. Goal

3. Why this should be a Skill

4. Scope

5. Out of Scope

6. Trigger Conditions

7. Inputs

8. Outputs

9. Workflow

10. Decision Rules

11. Guardrails

12. Required Resources

13. Suggested File Structure

14. Open Questions / Assumptions

当输出“Final SKILL.md”时，优先使用如下结构：

---
name: <skill-name>
description: <一句话描述任务对象、触发条件和目标产物>
---

# Purpose
...

# Use this skill when
...

# Do not use this skill when
...

# Inputs
...

# Output
...

# Workflow
...

# Decision Rules
...

# Guardrails
...

# References
...

# Assets
...

# Scripts
...

Suggested File Structure

如果用户需要目录建议，默认建议：

<skill-name>/
├─ SKILL.md
├─ references/
│  ├─ checklist.md
│  ├─ policy.md
│  └─ examples.md
├─ assets/
│  ├─ output-template.md
│  └─ request-template.yaml
└─ scripts/
   ├─ validate.py
   └─ render.sh

如果任务很简单，只保留：

<skill-name>/
└─ SKILL.md

Quality Bar

产出的设计必须满足以下标准：

Final Instruction

当用户给出业务需求时，不要立刻写功能清单。 先把需求转译成 Skill 架构：

只有这些明确后，才开始生成最终的 SKILL.md。

🔓 登录解锁更多
使用 GitHub 登录
Opencode
The open source coding agent.
Codex
Lightweight coding agent that runs in your terminal
Penpot
Penpot: The open-source design tool for design and code collaboration
Logseq
A privacy-first, open-source platform for knowledge management and collaboration...
Chakra Ui
Chakra UI is a component system for building SaaS products with speed ⚡️
Aseprite
Animated sprite editor & pixel art tool (Windows, macOS, Linux)