sop-creator

Name: sop-creator
Author: harryleemedia

15stars10forks

How to install sop-creator?

harryleemedia/second-brain/sop-creator

$npx -y skills add harryleemedia/second-brain --skill sop-creator

Installs into the current project.

Summary

Create runbooks, playbooks, and technical documentation for engineering teams. Use when the user wants to document a process, create a runbook, build operational docs, or formalize any repeatable technical procedure. Triggers on requests like "create a runbook for...", "document

Files · 1

View on GitHub

SKILL.md

1	# SOP 與 Runbook 建立器
2
3	建立人們真的會照著做的實用文件。
4
5	## 理念
6
7	沒有人會讀 50 頁的文件。讓它可掃描、可執行，而且不可能被誤解。
8
9	核心原則：
10	- 可掃描 - 標題、條列、表格。不要整片文字牆。
11	- 可執行 - 每個步驟都是你要「做」的事，而不是你要「考慮」的事
12	- 具體明確 - 數字、名稱、閾值。不要用「視需要」或「適當時」
13	- 可測試 - 明確的成功標準。你怎麼知道它成功了？
14	- 持續維護 - 負責人、最後更新日期、審查排程
15
16	## SOP 類別
17
18	根據你的使用情境選擇正確的格式：
19
20	### 技術/工程
21	\| 類型 \| 何時使用 \|
22	\|------\|-------------\|
23	\| Runbook \| 緊急回應、事件、值班 \|
24	\| 部署 Playbook \| 版本發佈、遷移、維護 \|
25	\| 故障排除指南 \| 除錯、診斷樹 \|
26	\| 操作指南 \| 一次性設定、組態 \|
27	\| ADR \| 架構決策 \|
28
29	### 營運/業務
30	\| 類型 \| 何時使用 \|
31	\|------\|-------------\|
32	\| 流程 SOP \| 可重複的業務工作流程 \|
33	\| 檢查清單 \| 品質控制、驗證 \|
34	\| 決策樹 \| 複雜的條件判斷場景 \|
35	\| 交接文件 \| 角色交替、班次交接 \|
36
37	### 內容/創意
38	\| 類型 \| 何時使用 \|
39	\|------\|-------------\|
40	\| 製作工作流程 \| 內容產出管線 \|
41	\| 審查流程 \| 審批工作流程 \|
42	\| 發佈檢查清單 \| 上線前驗證 \|
43
44	### 通用
45	\| 類型 \| 何時使用 \|
46	\|------\|-------------\|
47	\| 標準 SOP \| 任何可重複的流程 \|
48	\| 快速參考 \| 較長 SOP 的精簡版 \|
49	\| 入職指南 \| 新人上手 \|
50
51	## 通用結構
52
53	每個 SOP 至少需要：
54
55	```markdown
56	# [這做什麼]
57
58	> 摘要：一句話——做什麼、何時做、誰來做。
59
60	## 完成定義
61
62	以下全部達成即為完成：
63	- [ ] [主要成果]
64	- [ ] [驗證步驟]
65	- [ ] [任何交接/通知]
66
67	## 何時使用
68
69	[觸發條件]
70
71	## 前提條件
72
73	[開始前需要什麼]
74
75	## 流程
76
77	[編號步驟——實際的工作]
78
79	## 驗證完成
80
81	[回到完成定義，確認全部勾選]
82
83	## 出問題時怎麼辦
84
85	[常見問題與修復方式]
86
87	## 有問題？
88
89	[聯絡誰]
90	```
91
92	完成定義是最重要的區段。放在最前面。做成檢查清單。要具體。
93
94	## 撰寫規則
95
96	### 要具體
97
98	\| 不要這樣寫 \| 改成這樣 \|
99	\|-------------\|---------------\|
100	\| 「聯絡團隊」 \| 「在 #ops-team 頻道中 @sarah」 \|
101	\| 「等到準備好」 \| 「等到狀態顯示『完成』（約 5 分鐘）」 \|
102	\| 「仔細審查」 \| 「在儀表板中檢查項目 A、B、C」 \|
103	\| 「適當時」 \| 「如果數值 > 100」 \|
104	\| 「定期」 \| 「每週一上午 9 點」 \|
105	\| 「盡快」 \| 「2 小時內」 \|
106
107	### 步驟以動作開頭
108
109	```markdown
110	# 不好
111	「報告在發送之前應該先經過審查，以確保
112	所有資料欄位的正確性和完整性。」
113
114	# 好
115	1. 在 [系統] 中開啟報告
116	2. 驗證以下欄位已填寫：
117	- [ ] 客戶名稱
118	- [ ] 金額
119	- [ ] 日期
120	3. 點擊「發送」
121	```
122
123	### 警告放在前面
124
125	```markdown
126	# 不好
127	1. 刪除舊記錄
128	注意：此操作無法復原
129
130	# 好
131	> 警告：這會永久刪除記錄。如有需要請先匯出。
132
133	1. 刪除舊記錄
134	```
135
136	### 決策點要清楚
137
138	```markdown
139	# 不好
140	「依優先等級處理請求」
141
142	# 好
143	如果優先等級是：
144	- 緊急：放下一切，立刻處理，通知主管
145	- 高： 4 小時內處理
146	- 一般： 24 小時內處理
147	- 低：加入每週批次處理
148	```
149
150	## 格式選擇指南
151
152	問你自己：
153
154	1. 這是用於緊急情況嗎？ → Runbook
155	2. 這是複雜的多階段專案嗎？ → Playbook
156	3. 這是簡單的重複性任務嗎？ → 標準 SOP 或檢查清單
157	4. 有很多條件判斷分支嗎？ → 決策樹
158	5. 這是用於除錯嗎？ → 故障排除指南
159	6. 這是記錄一個決策嗎？ → ADR
160	7. 這是給新人看的嗎？ → 入職指南
161
162	## 中繼資料（保持簡潔）
163
164	```yaml
165	---
166	title: [清楚的名稱]
167	owner: [負責人或團隊]
168	last_updated: [日期]
169	review_schedule: [季度/年度/視需要]
170	---
171	```
172
173	就這樣。除非你真的需要，否則不用文件編號、版本矩陣或審批流程。
174
175	## 範本
176
177	每個範本都在 `references/` 中：
178
179	\| 範本 \| 用途 \|
180	\|----------\|---------\|
181	\| [runbook.md](references/runbook.md) \| 事件、緊急情況、值班 \|
182	\| [standard-sop.md](references/standard-sop.md) \| 任何可重複的流程 \|
183	\| [how-to-guide.md](references/how-to-guide.md) \| 一次性任務、設定 \|
184	\| [onboarding-guide.md](references/onboarding-guide.md) \| 新人上手 \|
185	\| [decision-tree.md](references/decision-tree.md) \| 複雜的條件判斷流程 \|
186	\| [checklist.md](references/checklist.md) \| 品質控制、驗證 \|
187
188	所有範本都以完成定義作為主要的成功標準。
189
190	## 品質檢查清單
191
192	發佈前：
193	- [ ] 不熟悉的人能照著做嗎？
194	- [ ] 所有步驟都是可執行的嗎（動詞，不是描述）？
195	- [ ] 有提供具體資訊嗎（名稱、數字、閾值）？
196	- [ ] 有明確的「完成」狀態嗎？
197	- [ ] 負責人/聯絡資訊是最新的嗎？
198	- [ ] 最近測試過嗎？
199
200	## 反模式
201
202	消滅這些：
203	- 「根據公司政策...」（直接說該做什麼）
204	- 「建議...」（直接說「做 X」）
205	- 「請確保...」（直接說「檢查 X」）
206	- 被動語態（「表單應被提交」→「提交表單」）
207	- 描述要做什麼而不是展示
208	- 沒有結構的文字牆
209	- 一個月後就過時的截圖
210
211	要做這些：
212	- 從最常見的路徑開始
213	- 把邊緣情況放在底部
214	- 連結到相關文件而不是複製
215	- 用表格呈現參考資訊
216	- 用檢查清單做驗證步驟
217	- 包含「我卡住了」的逃生出口

People who liked this also viewed

6 picks

Type

sop-creator

15stars10forks

View on GitHub

How to install sop-creator?

harryleemedia/second-brain/sop-creator

$npx -y skills add harryleemedia/second-brain --skill sop-creator

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# SOP 與 Runbook 建立器
2
3	建立人們真的會照著做的實用文件。
4
5	## 理念
6
7	沒有人會讀 50 頁的文件。讓它可掃描、可執行，而且不可能被誤解。
8
9	核心原則：
10	- 可掃描 - 標題、條列、表格。不要整片文字牆。
11	- 可執行 - 每個步驟都是你要「做」的事，而不是你要「考慮」的事
12	- 具體明確 - 數字、名稱、閾值。不要用「視需要」或「適當時」
13	- 可測試 - 明確的成功標準。你怎麼知道它成功了？
14	- 持續維護 - 負責人、最後更新日期、審查排程
15
16	## SOP 類別
17
18	根據你的使用情境選擇正確的格式：
19
20	### 技術/工程
21	\| 類型 \| 何時使用 \|
22	\|------\|-------------\|
23	\| Runbook \| 緊急回應、事件、值班 \|
24	\| 部署 Playbook \| 版本發佈、遷移、維護 \|
25	\| 故障排除指南 \| 除錯、診斷樹 \|
26	\| 操作指南 \| 一次性設定、組態 \|
27	\| ADR \| 架構決策 \|
28
29	### 營運/業務
30	\| 類型 \| 何時使用 \|
31	\|------\|-------------\|
32	\| 流程 SOP \| 可重複的業務工作流程 \|
33	\| 檢查清單 \| 品質控制、驗證 \|
34	\| 決策樹 \| 複雜的條件判斷場景 \|
35	\| 交接文件 \| 角色交替、班次交接 \|
36
37	### 內容/創意
38	\| 類型 \| 何時使用 \|
39	\|------\|-------------\|
40	\| 製作工作流程 \| 內容產出管線 \|
41	\| 審查流程 \| 審批工作流程 \|
42	\| 發佈檢查清單 \| 上線前驗證 \|
43
44	### 通用
45	\| 類型 \| 何時使用 \|
46	\|------\|-------------\|
47	\| 標準 SOP \| 任何可重複的流程 \|
48	\| 快速參考 \| 較長 SOP 的精簡版 \|
49	\| 入職指南 \| 新人上手 \|
50
51	## 通用結構
52
53	每個 SOP 至少需要：
54
55	```markdown
56	# [這做什麼]
57
58	> 摘要：一句話——做什麼、何時做、誰來做。
59
60	## 完成定義
61
62	以下全部達成即為完成：
63	- [ ] [主要成果]
64	- [ ] [驗證步驟]
65	- [ ] [任何交接/通知]
66
67	## 何時使用
68
69	[觸發條件]
70
71	## 前提條件
72
73	[開始前需要什麼]
74
75	## 流程
76
77	[編號步驟——實際的工作]
78
79	## 驗證完成
80
81	[回到完成定義，確認全部勾選]
82
83	## 出問題時怎麼辦
84
85	[常見問題與修復方式]
86
87	## 有問題？
88
89	[聯絡誰]
90	```
91
92	完成定義是最重要的區段。放在最前面。做成檢查清單。要具體。
93
94	## 撰寫規則
95
96	### 要具體
97
98	\| 不要這樣寫 \| 改成這樣 \|
99	\|-------------\|---------------\|
100	\| 「聯絡團隊」 \| 「在 #ops-team 頻道中 @sarah」 \|
101	\| 「等到準備好」 \| 「等到狀態顯示『完成』（約 5 分鐘）」 \|
102	\| 「仔細審查」 \| 「在儀表板中檢查項目 A、B、C」 \|
103	\| 「適當時」 \| 「如果數值 > 100」 \|
104	\| 「定期」 \| 「每週一上午 9 點」 \|
105	\| 「盡快」 \| 「2 小時內」 \|
106
107	### 步驟以動作開頭
108
109	```markdown
110	# 不好
111	「報告在發送之前應該先經過審查，以確保
112	所有資料欄位的正確性和完整性。」
113
114	# 好
115	1. 在 [系統] 中開啟報告
116	2. 驗證以下欄位已填寫：
117	- [ ] 客戶名稱
118	- [ ] 金額
119	- [ ] 日期
120	3. 點擊「發送」
121	```
122
123	### 警告放在前面
124
125	```markdown
126	# 不好
127	1. 刪除舊記錄
128	注意：此操作無法復原
129
130	# 好
131	> 警告：這會永久刪除記錄。如有需要請先匯出。
132
133	1. 刪除舊記錄
134	```
135
136	### 決策點要清楚
137
138	```markdown
139	# 不好
140	「依優先等級處理請求」
141
142	# 好
143	如果優先等級是：
144	- 緊急：放下一切，立刻處理，通知主管
145	- 高： 4 小時內處理
146	- 一般： 24 小時內處理
147	- 低：加入每週批次處理
148	```
149
150	## 格式選擇指南
151
152	問你自己：
153
154	1. 這是用於緊急情況嗎？ → Runbook
155	2. 這是複雜的多階段專案嗎？ → Playbook
156	3. 這是簡單的重複性任務嗎？ → 標準 SOP 或檢查清單
157	4. 有很多條件判斷分支嗎？ → 決策樹
158	5. 這是用於除錯嗎？ → 故障排除指南
159	6. 這是記錄一個決策嗎？ → ADR
160	7. 這是給新人看的嗎？ → 入職指南
161
162	## 中繼資料（保持簡潔）
163
164	```yaml
165	---
166	title: [清楚的名稱]
167	owner: [負責人或團隊]
168	last_updated: [日期]
169	review_schedule: [季度/年度/視需要]
170	---
171	```
172
173	就這樣。除非你真的需要，否則不用文件編號、版本矩陣或審批流程。
174
175	## 範本
176
177	每個範本都在 `references/` 中：
178
179	\| 範本 \| 用途 \|
180	\|----------\|---------\|
181	\| [runbook.md](references/runbook.md) \| 事件、緊急情況、值班 \|
182	\| [standard-sop.md](references/standard-sop.md) \| 任何可重複的流程 \|
183	\| [how-to-guide.md](references/how-to-guide.md) \| 一次性任務、設定 \|
184	\| [onboarding-guide.md](references/onboarding-guide.md) \| 新人上手 \|
185	\| [decision-tree.md](references/decision-tree.md) \| 複雜的條件判斷流程 \|
186	\| [checklist.md](references/checklist.md) \| 品質控制、驗證 \|
187
188	所有範本都以完成定義作為主要的成功標準。
189
190	## 品質檢查清單
191
192	發佈前：
193	- [ ] 不熟悉的人能照著做嗎？
194	- [ ] 所有步驟都是可執行的嗎（動詞，不是描述）？
195	- [ ] 有提供具體資訊嗎（名稱、數字、閾值）？
196	- [ ] 有明確的「完成」狀態嗎？
197	- [ ] 負責人/聯絡資訊是最新的嗎？
198	- [ ] 最近測試過嗎？
199
200	## 反模式
201
202	消滅這些：
203	- 「根據公司政策...」（直接說該做什麼）
204	- 「建議...」（直接說「做 X」）
205	- 「請確保...」（直接說「檢查 X」）
206	- 被動語態（「表單應被提交」→「提交表單」）
207	- 描述要做什麼而不是展示
208	- 沒有結構的文字牆
209	- 一個月後就過時的截圖
210
211	要做這些：
212	- 從最常見的路徑開始
213	- 把邊緣情況放在底部
214	- 連結到相關文件而不是複製
215	- 用表格呈現參考資訊
216	- 用檢查清單做驗證步驟
217	- 包含「我卡住了」的逃生出口

People who liked this also viewed

6 picks

Type