business-operations-skills

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Business Operations — Domain Orchestrator

业务运营——领域编排器

The BizOps surface is internal: how the company actually runs. This orchestrator forks its conversation context, routes your inquiry to one of six sub-skills, then returns a tight digest to the parent thread. The heavy ingestion (vendor catalogs, process interviews, multi-doc SOP intake) stays in the forked context.

BizOps的应用场景为内部：即公司实际的运营方式。该编排器会拆分对话上下文，将你的请求路由至六个子技能中的一个，然后向父线程返回简洁的摘要。繁重的 ingestion 操作（供应商目录导入、流程访谈记录、多文档SOP采集）会在拆分后的上下文中完成。

When to invoke

调用时机

Symptom	Sub-skill to route to
"Where does the work spend most of its time waiting?"	`process-mapper`
"Is this vendor delivering against the SLA?"	`vendor-management`
"Do we have enough people to ship in Q3?"	`capacity-planner`
"I need to brief the company on a re-org"	`internal-comms`
"Write me a runbook for the incident response process"	`knowledge-ops`
"Why is our software spend up 40% YoY?"	`procurement-optimizer`

场景描述	路由至的子技能
“工作大部分时间都耗在等待环节？”	`process-mapper`
“该供应商是否符合SLA要求？”	`vendor-management`
“我们有足够人手在第三季度完成交付吗？”	`capacity-planner`
“我需要向全公司通报组织架构调整事宜”	`internal-comms`
“帮我编写一份事件响应流程的运行手册”	`knowledge-ops`
“为什么我们的软件支出同比增长了40%？”	`procurement-optimizer`

Routing logic (deterministic)

路由逻辑（确定性）

The orchestrator classifies the inquiry by signals detected in the prompt. Two-signal threshold for confident routing; one-signal triggers a clarifying question.

编排器会根据提示中检测到的信号对请求进行分类。达到两个信号的阈值时会进行确定性路由；仅检测到一个信号时会触发澄清问题。

Signal table

信号表

Signal class	Keywords	Sub-skill
PROCESS	bottleneck, cycle time, waiting, handoff, BPMN, process map, workflow	`process-mapper`
VENDOR	vendor, supplier, SLA, contract, third-party, MSA, SaaS subscription, renewal	`vendor-management`
CAPACITY	headcount, capacity, utilization, planning, hiring sequence, FTE	`capacity-planner`
COMMS	all-hands, internal newsletter, announcement, change management, FAQ, town hall	`internal-comms`
KNOWLEDGE	SOP, runbook, knowledge base, wiki, playbook, documentation, onboarding doc	`knowledge-ops`
PROCUREMENT	spend, procurement, purchase, supplier rationalization, software audit, SaaS sprawl	`procurement-optimizer`

If signals are mixed (e.g., "vendor SLA + spend audit"), run the highest-confidence sub-skill first, then chain into the second one in a follow-up forked turn.

信号类别	关键词	子技能
PROCESS（流程）	bottleneck, cycle time, waiting, handoff, BPMN, process map, workflow	`process-mapper`
VENDOR（供应商）	vendor, supplier, SLA, contract, third-party, MSA, SaaS subscription, renewal	`vendor-management`
CAPACITY（产能）	headcount, capacity, utilization, planning, hiring sequence, FTE	`capacity-planner`
COMMS（沟通）	all-hands, internal newsletter, announcement, change management, FAQ, town hall	`internal-comms`
KNOWLEDGE（知识）	SOP, runbook, knowledge base, wiki, playbook, documentation, onboarding doc	`knowledge-ops`
PROCUREMENT（采购）	spend, procurement, purchase, supplier rationalization, software audit, SaaS sprawl	`procurement-optimizer`

如果信号混合（例如：“vendor SLA + spend audit”），先运行置信度最高的子技能，然后在后续拆分环节中链式调用第二个子技能。

Fallback

回退机制

If no signal class scores ≥ 2, ask one clarifying question naming the two most likely candidates. Do NOT guess silently.

如果没有任何信号类别的得分≥2，提出一个澄清问题，列出两个最可能的候选子技能。切勿自行猜测。

Workflow (Matt Pocock grill discipline)

工作流（Matt Pocock grill准则）

Derived from Matt Pocock's

grill-with-docs

pattern: explore-then-ask, one question per turn with a recommended answer, walk the decision tree depth-first, track dependencies, anchor every challenge in the documented canon (

references/

源自Matt Pocock的

grill-with-docs

模式：先探索再提问，每轮只提一个问题并给出推荐答案，深度遍历决策树，跟踪依赖关系，每个挑战都锚定在文档规范中（

references/

目录）。

Step 1 — Explore before asking

步骤1 — 提问前先探索

Before any clarifying question, check:

Does the user's working directory already contain a process map, vendor catalog, SOP, or org chart we can grep?
Does the inquiry already disambiguate the lane (e.g., "vendor SLA review" — that's
```
vendor-management
```
, no question needed)?
Is the lane unambiguous from filenames mentioned (
```
procurement-Q3.csv
```
→ procurement)?

If the codebase resolves the lane, route silently. Don't ask.

在提出任何澄清问题前，先检查：

用户的工作目录中是否已包含可检索的流程地图、供应商目录、SOP或组织架构图？
请求是否已明确区分所属领域（例如：“vendor SLA review” — 明确属于
```
vendor-management
```
，无需提问）？
是否可通过提及的文件名明确所属领域（
```
procurement-Q3.csv
```
→ 采购领域）？

如果代码库可明确所属领域，直接静默路由，无需提问。

Step 2 — If still ambiguous, ONE forcing question with a recommended answer

步骤2 — 若仍存在歧义，提出一个带推荐答案的明确问题

Matt's rule: never bundle questions. Never default to "what do you think?". Always offer your recommendation.

Pattern:

Q1/1: [precise question naming the two candidate lanes]
Recommended: [Lane X, because <one-sentence rationale from the signal table>]

(Confirm, or override?)

Wait for the user's response. Then route. Never guess silently after a turn that asked a question.

Matt的规则：切勿捆绑多个问题。切勿默认问“你怎么看？”。始终给出你的推荐方案。

格式示例：

Q1/1: [明确列出两个候选领域的精准问题]
推荐方案：[领域X，因为<信号表中的一句话理由>]

（请确认，或选择其他领域？）

等待用户回复。之后再进行路由。提问后切勿自行猜测。

Step 3 — Forking decision-tree walk (only if the inquiry crosses lanes)

步骤3 — 拆分决策树遍历（仅当请求跨领域时）

If the user's inquiry legitimately crosses two lanes (e.g., "vendor SLA + spend audit" = VENDOR + PROCUREMENT), walk the tree depth-first:

Resolve the higher-confidence lane first → run that sub-skill in forked context → return digest
Ask: "Should we now run [second lane]? My recommendation: yes, because [dependency reason]."
Only after explicit user confirmation, run the second sub-skill

Do NOT chain silently. Each fork is an explicit user-confirmed step.

如果用户的请求确实涉及两个领域（例如：“vendor SLA + spend audit” = 供应商 + 采购），深度遍历决策树：

先解决置信度更高的领域 → 在拆分后的上下文中运行该子技能 → 返回摘要
询问：“我们现在是否要运行[第二个领域]？我的推荐：是，因为[依赖关系理由]。”
仅在用户明确确认后，再运行第二个子技能

切勿静默链式调用。每个拆分环节都需用户明确确认。

Step 4 — Invoke sub-skill in forked context

步骤4 — 在拆分后的上下文中调用子技能

Each sub-skill is invoked with the original prompt + a digest of any structured inputs (file paths, JSON inputs). The fork keeps heavy ingestion (vendor catalog, process transcripts, SOP source documents) out of the parent context.

调用每个子技能时，会传入原始提示 + 所有结构化输入的摘要（文件路径、JSON输入）。拆分操作可避免繁重的 ingestion 操作（供应商目录、流程记录、SOP源文档）占用父上下文资源。

Step 5 — Return digest with cited canon challenge

步骤5 — 返回带有规范引用挑战的摘要

When the sub-skill completes, return a ≤ 200-word digest to the parent thread:

What was analyzed
Top 3 findings (each anchored in a reference doc citation — e.g., "Goldratt's Theory of Constraints: optimize the bottleneck, not the non-constraint")
Top 3 next actions (named owners if possible)
Path to the artifact(s) produced
One grill challenge for the user, cited: "Your value-add ratio is 12%. Lean canon (Womack & Jones 1996) classifies <15% as waste-heavy. What's blocking process redesign — political, technical, or budget?"

The parent agent can then ask follow-ups (each triggering new forked invocations).

子技能完成后，向父线程返回**≤200字的摘要**：

分析内容
三大核心发现（每个发现都锚定在参考文档引用中 — 例如：“Goldratt约束理论：优化瓶颈环节，而非非瓶颈环节”）
三大后续行动（尽可能指定负责人）
生成产物的路径
一个基于规范的挑战问题：“你的价值增值比为12%。精益规范（Womack & Jones 1996）将<15%的比例归类为高浪费。是什么阻碍了流程重构——政治因素、技术因素还是预算因素？”

父Agent随后可发起跟进请求（每个请求都会触发新的拆分调用）。

Forcing-question library (grill-with-docs pattern)

明确问题库（grill-with-docs模式）

When the user has provided enough context to enter a lane, the orchestrator may grill them on the decisions inside that lane before invoking the sub-skill. One question per turn, each with a recommended answer + canon citation. Examples:

PROCESS lane: "Before mapping: do you have measured cycle times per stage, or only estimates? Recommended: insist on measured data for the top-3 longest stages. Anti-pattern (Goldratt 1984): map estimates, optimize the wrong constraint."
VENDOR lane: "Before scoring: what's your tier-1 criticality threshold — by spend ($X/year), or by operational dependency (revenue-blocking if vendor fails)? Recommended: operational dependency. Anti-pattern (Gartner TPRM): spend-only tiering misses critical low-spend vendors like the HVAC vendor in the Target breach."
CAPACITY lane: "Before modeling: are you planning for utilization or throughput? Recommended: throughput (Little's Law). Anti-pattern (DORA): planning for utilization > 80% destroys throughput via queueing."

Never run a sub-skill until the lane-defining decision is locked.

当用户提供的上下文足够进入某个领域时，编排器可能会在调用子技能前，针对该领域内的决策向用户提问。每轮只提一个问题，每个问题都带有推荐答案 + 规范引用。示例：

PROCESS领域：“绘制流程前：你是否有各阶段的实测周期时间，还是仅为估算值？推荐方案：要求获取前3个最长阶段的实测数据。反模式（Goldratt 1984）：基于估算值绘制流程，优化错误的约束环节。”
VENDOR领域：“评分前：你的一级关键供应商阈值是按支出（每年$X）还是按运营依赖度（供应商故障会影响营收）？推荐方案：按运营依赖度。反模式（Gartner TPRM）：仅按支出分级会遗漏关键的低支出供应商，例如Target数据泄露事件中的HVAC供应商。”
CAPACITY领域：“建模前：你是针对利用率还是吞吐量进行规划？推荐方案：吞吐量（Little定律）。反模式（DORA）：利用率>80%的规划会因排队问题破坏吞吐量。”

在领域定义决策确定前，切勿运行子技能。

Assumptions

假设前提

The user is acting on behalf of an organization with ≥ 10 employees (smaller orgs don't need this surface).
The user has access to the data the sub-skill needs (process docs, vendor list, spend export, etc.) — or accepts the skill's templated dummy data.
The user wants deterministic, repeatable analysis over LLM-flavored prose. Every sub-skill ships stdlib-only Python tools.

用户代表员工规模≥10人的组织（更小的组织无需此工具）。
用户可访问子技能所需的数据（流程文档、供应商列表、支出导出文件等）——或接受技能提供的模板化模拟数据。
用户需要确定性、可重复的分析，而非大语言模型生成的散文式内容。每个子技能都仅使用标准库Python工具。

Non-goals

非目标

Not a substitute for an ERP, vendor management platform (Vendr, Tropic), or capacity-planning SaaS (Float, Runn).
Does not store state across sessions — every invocation is self-contained.
Does not call external APIs from Python tools (stdlib only, by design).

不能替代ERP、供应商管理平台（Vendr、Tropic）或产能规划SaaS（Float、Runn）。
不会跨会话存储状态——每次调用都是独立的。
不会通过Python工具调用外部API（设计上仅使用标准库）。

Distinct from

与其他工具的区别

business-growth/*
— that's the external sales motion (CSM, sales engineering, RevOps). BizOps is internal.
c-level-advisor/coo-advisor
— that's strategic COO judgment ("should we restructure?"). BizOps is tactical ("here's the process map with bottlenecks").
engineering/slo-architect
— that's system reliability with SLO/SLI/error budgets.
```
process-mapper
```
is business process reliability, not system reliability.
engineering/llm-wiki
— that's a personal PKM (Karpathy's pattern).
```
knowledge-ops
```
is company-wide SOP authoring.

business-growth/*
— 针对外部销售流程（客户成功经理、销售工程师、营收运营）。BizOps则聚焦内部。
c-level-advisor/coo-advisor
— 提供战略层面的COO判断（“我们是否应该重组？”）。BizOps则聚焦战术层面（“这是带有瓶颈环节的流程地图”）。
engineering/slo-architect
— 针对系统可靠性，涉及SLO/SLI/错误预算。
```
process-mapper
```
则聚焦业务流程可靠性，而非系统可靠性。
engineering/llm-wiki
— 针对个人知识管理（Karpathy模式）。
```
knowledge-ops
```
则聚焦全公司范围的SOP编写。

Output artifacts

输出产物

Every sub-skill produces at least one artifact (markdown, CSV, or JSON) saved to the user's working directory. The orchestrator surfaces the file path in the digest.

每个子技能至少会生成一个产物（markdown、CSV或JSON格式），保存至用户的工作目录。编排器会在摘要中显示文件路径。

Anti-patterns (do not)

反模式（禁止操作）

❌ Run all 6 sub-skills "to be thorough" — pick one based on signal, return digest, let user chain
❌ Auto-approve a vendor or process change — surface findings; the human decides
❌ Edit production process docs without asking — write to a new file, propose the diff
❌ Skip the digest step — parent context needs ≤ 200-word digest, not the full sub-skill output

❌ 为了“全面”而运行全部6个子技能——根据信号选择一个，返回摘要，由用户决定是否链式调用
❌ 自动批准供应商或流程变更——展示分析结果；由人工做出决策
❌ 未经询问编辑生产环境的流程文档——写入新文件，提出差异修改建议
❌ 跳过摘要步骤——父上下文需要≤200字的摘要，而非子技能的完整输出

References

参考文献

See
```
c-level-advisor/coo-advisor
```
for strategic COO framing

Path-B build pattern:

documentation/implementation/bizops-commercial-expansion-plan.md

如需战略层面的COO框架，请查看
```
c-level-advisor/coo-advisor
```

Path-B构建模式：

documentation/implementation/bizops-commercial-expansion-plan.md