mcpField
S
sop-creator

sop-creator

github.com/ognjengt生产力6491.5k 次安装23 周前更新
代码仓库

关于 sop-creator

sop-creator 可将流程描述整理为逐步执行的标准操作规程,并通过提问补充关键信息。它面向需要编写易懂操作文档的人,包含检查项、警告和版本信息。

主要功能

  1. 01将流程描述转为标准操作规程
  2. 02针对缺失信息提问
  3. 03采用适合初学者的语言
  4. 04列出前提条件和权限
  5. 05加入检查项、警告和常见问题
  6. 06按清单核验文档

适用场景

  1. 01记录可重复的业务流程
  2. 02为缺乏经验的员工编写说明
  3. 03整理质量和安全要求

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/ognjengt/founder-skills --skill sop-creator

安装后在 Claude Code 中输入/sop-creator确认已加载。

详细介绍

SOP 创建器

目的

将非结构化的流程描述转化为清晰、可执行的标准操作规程,阅读难度控制在小学五年级水平。


执行逻辑

先检查 $ARGUMENTS,以确定执行模式:

如果 $ARGUMENTS 为空或未提供:

回复: "sop-creator loaded, describe the process you want to document"

然后等待用户在下一条消息中提供流程描述。

如果 $ARGUMENTS 包含内容:

立即开始执行任务(跳过“已加载”消息)。


任务执行

当流程描述可用时(来自初始 $ARGUMENTS 或后续消息):

1. 检查业务背景

检查项目根目录中是否存在 FOUNDER_CONTEXT.md。

  • **如果存在:**读取该文件,并利用业务背景个性化输出(公司名称、品牌语气、行业细节、受众和所用工具)。
  • **如果不存在:**使用“默认值和假设”中的默认设置继续。
2. 分析初始输入

从用户的初始描述中提取可用信息:

  • 流程名称或标题
  • 执行此流程的人员(角色/技能水平)
  • 涉及的工具或系统
  • 预期结果或最终状态
  • 任何合规或质量要求
  • 提到的关键步骤
3. 提出澄清问题(如有需要)

使用 AskUserQuestion 工具收集缺失的关键信息。最多提出 5 个问题,但越少越好——一旦信息足以编写完整的 SOP,就停止提问。

问题库(按优先级排序):

#问题重要原因以下情况可跳过……
1你希望记录的具体流程是什么?确定范围和标题流程描述清晰
2谁会执行此流程?(角色、技能水平、经验)确定语言复杂度和详细程度用户已说明受众
3此流程涉及哪些工具或系统?明确前提条件和访问要求已列出工具
4成功的最终结果是什么?如何判断流程是否正确完成?确定质量检查标准和成功指标已清楚说明结果
5是否有合规要求、安全注意事项或关键警告?确保包含重要注意事项不涉及监管或安全问题

提问策略:

  • 每轮使用 AskUserQuestion 提出 2-3 个问题
  • 如果第一轮回答已提供足够的细节,就停止提问
  • 总问题数不得超过 5 个
  • 只询问会影响正确执行的问题
4. 生成 SOP

根据收集到的信息,按照输出格式中的结构创建完整的 SOP:

  1. 按小学五年级阅读水平编写——使用短句和简单词语
  2. 每个步骤只执行一项操作——不要合并多条指令
  3. 每个步骤都以动作动词开头——“单击”“打开”“确认”“输入”
  4. 包含预期结果——告诉用户应该看到什么
  5. 为关键步骤添加警告——防止常见错误
  6. 创建质量检查——明确定义“完成”的标准
5. 格式化并验证
  • 按照输出格式部分的要求组织内容
  • 在呈现输出前完成质量检查清单自检
  • 确保不熟悉此流程的人也能按 SOP 操作

写作规则

严格约束,不得变通。

核心规则
  • 按小学五年级阅读水平编写
  • 使用短句(每句最多 10-15 个词)
  • 使用简单、常见的词语——避免行话,或立即解释行话
  • 每个步骤只执行一项操作——绝不合并多项操作
  • 每个步骤都以动作动词开头(单击、打开、输入、确认、检查)
  • 在每个关键步骤后写明预期结果
  • 绝不编造步骤——只记录已描述或确认的内容
SOP 专属规则
  • 标题格式:“SOP:[流程名称]”(清晰且便于搜索)
  • 必须包含版本信息 — SOP 必须进行版本控制
  • 必须明确列出前置条件 — 不得隐含任何要求
  • 质量检查必须可衡量 — 避免主观标准
  • 必须包含常见问题部分 — 记录已知故障模式
  • 工具部分必须包括所需的访问权限
受众规则
  • 除非另有说明,否则假设读者没有任何相关知识
  • 首次出现时解释缩写
  • 对不明显的步骤说明原因
  • 在有助于视觉指导的地方加入截图占位符
  • 在具有破坏性或不可逆操作之前添加警告

输出格式

SOP 必须严格遵循以下结构:

# SOP: [Process Name]

**Version:** 1.0
**Last Updated:** [Current Date]
**Owner:** [Role/Name from context or "Process Owner"]
**Audience:** [Who uses this SOP]

---

## 1. Purpose
[One clear sentence describing what this process achieves and why it matters.]

## 2. Who Does This
[Role or skill level of person performing this process]

## 3. Tools You Need
- [Tool 1]
- [Tool 2]
- [Access/permissions required]

## 4. Starting Requirements
Before you start, make sure:
- [ ] [Requirement 1]
- [ ] [Requirement 2]
- [ ] [Everything you need is ready]

## 5. Step-by-Step Instructions

### Step 1: [Action Title]
1. [Do this specific action]
2. [Do this specific action]

**What you should see:** [Expected result or outcome]

### Step 2: [Action Title]
1. [Do this specific action]
   - [If needed, add a sub-step for clarity]
   - [If needed, add another sub-step]

**Warning:** [Important thing that could go wrong or caution]

### Step 3: [Action Title]
1. [Do this specific action]

**What you should see:** [Expected result]

[Continue with numbered steps until process completion...]

## 6. Quality Check
After finishing, verify:
- [ ] [Verification item 1 — specific and measurable]
- [ ] [Verification item 2 — specific and measurable]
- [ ] [Final outcome achieved]

## 7. Common Problems and Fixes

| Problem | Why It Happens | How to Fix |
|---------|---------------|------------|
| [Specific problem] | [Root cause] | [Clear solution] |
| [Specific problem] | [Root cause] | [Clear solution] |

## 8. Notes
**Assumptions made:**
- [List any assumptions about user knowledge, tools, or environment]

**Who to ask for help:** [Role or person]

## 9. Version History

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | [Date] | [Author] | Initial version |

质量检查清单(自我验证)

定稿前,请核实以下所有内容:

执行前检查
  • 我检查了是否存在 FOUNDER_CONTEXT.md,并在有相关信息时应用了业务背景
  • 我只针对确实缺失的信息提出了澄清问题
  • 我总共提出的问题不超过 5 个
内容检查
  • 流程标题清晰且具体
  • 目的说明是一个清晰的句子
  • 已列出所有工具和访问要求
  • 前置条件明确且可核查
  • 每个步骤都以一个动作动词开头
  • 没有任何步骤假设读者具备未说明的知识
  • 关键步骤包含预期结果
  • 风险操作之前已添加警告
写作检查
  • 语言难度相当于小学五年级
  • 句子简短(10–15 个单词)
  • 没有未加解释的术语
  • 每个步骤只包含一个操作
  • 步骤顺序正确
输出检查
  • 质量检查具体且可衡量
  • 常见问题部分包含可能出现的问题
  • 明确说明成功状态
  • 无需额外背景信息即可遵循 SOP
  • 版本信息完整

如果任何一项检查未通过 → 修改后再提交。


默认值与假设

除非用户另有说明,否则采用以下默认值:

  • 受众: 对此特定流程毫无经验的初学者
  • 阅读水平: 小学五年级(用词简单,句子简短)
  • 版本: 1.0
  • 作者: 如果 FOUNDER_CONTEXT.md 中有相关信息,则使用其中的作者;否则使用“流程负责人”
  • 最后更新日期: 当前日期
  • 流程类型: 可重复执行的业务流程(非一次性任务)
  • 完成时间: 除非另有说明,否则不指定
  • 权限: 除非另有说明,否则使用标准用户权限

在 SOP 的 备注 部分记录所有作出的假设。


评论

支持 Markdown