Support Operations
This is a Hermes-native support-operations workflow skill.
Why This Exists
support-operations turns a bounded customer case into response and escalation guidance without treating drafts or recommendations as helpdesk actions.
Do Not Use When
- The request clusters a backlog of customer signals to find product patterns or roadmap candidates; use
feedback-triage.
- The user only needs a generic, non-support marketing or email rewrite with no case, severity, or escalation context; use
content-operator.
- The request asks to send a reply, change ticket priority or status, issue a refund, modify an account, or update a helpdesk; use
connector-operator with an explicit target and observed result.
- The request is an active reliability incident or postmortem rather than a support-case response; use
reliability-review.
Examples
Good example:
- Prompt: Draft a calm reply for this login-outage customer and tell me whether it needs an engineering escalation.
- Expected behavior: Prepare a customer-safe reply, severity matrix, engineering escalation recommendation, and owner handoff.
- Why: The request is one support case with reply and escalation decisions, not a feedback backlog or ticket mutation.
Bad example:
- Prompt: Cluster last quarter's support feedback into roadmap opportunities.
- Expected behavior: Route to
feedback-triage, not support-operations.
- Why: A historical signal backlog needs product-pattern triage rather than case-level support guidance.
Completion Checklist
- The source boundary, signal clusters, severity, and follow-up lane are named.
- Bug, feature, research, strategy, and coding handoff outcomes stay separate.
- The next workflow is recommended before any implementation claim.
Recovery Notes
- If feedback lacks source or severity, ask for the missing signal before coding handoff.
- If the item is actually a plan or research request, route to that workflow instead of triage.
Workflow Lane
- Current lane: Research and company ops (
product-docs, source-finder, web-research, research, best-practice-research, autoresearch-goal, model-optimization, inference-serving, +19 more) - research, signals, ops, and briefings.
- If intent belongs to another lane, hand back to
oh-my-hermes or name the adjacent workflow.
- Shared product, routing, compatibility, and evidence rules:
omh-routing/references/skill-common-rail.md.
Use When
Use when one or a bounded set of support contacts needs response drafting, urgency classification, incident/escalation routing, and follow-up ownership.
Strong routing signals: `support escalation`, `customer support reply`, `ticket triage`, `고객 지원 에스컬레이션`, `고객 답변 초안`, `지원 티켓 분류`
Catalog Metadata
Category: triage
Phase: support-operations
Hermes role: operator
Quality tier: triage-gated
Reasoning demand: standard
Quality bar:
- State issue, severity, impact, evidence gaps, owner, and next route.
- Draft a reply without treating it as a sent customer communication.
Handoff policy:
Keep domain framing, clarification, source/evidence synthesis, draft outputs, and next-work routing in Hermes. A prepared brief, review, reply, or plan is not an external action, approval, filing, send, publish, data mutation, implementation, review, CI, or merge claim. Prepare a connector, file, coding, or human-review handoff only when the user explicitly accepts that next step; report it only from observed evidence. Reply text is a draft, escalation is a recommendation, and no ticket state, message send, refund, account action, or customer outcome is claimed.
Required inputs:
- support case
- known facts
- customer impact
- available ownership or escalation path
Expert clarification questions:
support case
- English: Which support case should we examine first?
- Korean: 어떤 지원 사례를 먼저 살펴봐야 하나요?
Expected outputs:
- customer-safe reply draft with stated facts, unknowns, and tone
- issue/severity/impact/escalation matrix
- internal next-step and owner handoff brief
- missing repro, account, entitlement, or approval evidence list
Artifact expectations:
- prepared support case brief when a wrapper captures it
Artifact contracts:
This label denotes the machine-enforcement level, not a skill quality score and not an observed evidence state.
- contract_id:
support-operations; enforcement_level: guidance_only; consumer_id: none
Safety rules:
- Keep customer-safe facts, unknowns, and escalation recommendations distinct.
- Do not claim ticket mutation, message send, refund, account action, or case outcome.
Runtime Evidence
Preferred harness for this skill: ops-review.
omh runtime record --skill support-operations --harness ops-review --status started
Record observed delegation results; otherwise return not_available or not_observed.
Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
- Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.
Preserve workflow intent and stop conditions; verify before claiming completion.
Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.
Shared product, compatibility, topology, memory, harness, and execution rules: omh-routing/references/skill-common-rail.md. Load it when applicable; otherwise name an unavailable capability.
1---
2name: "omh-support-operations"
3description: "[omh] Turn a support case into a clear customer reply, severity path, and owned next step. Use when the user says: support escalation, customer support reply, ticket triage, 고객 지원 에스컬레이션, 고객 답변 초안, 지원 티켓 분류."
4metadata:
5 hermes:
6 tags: [workflow, oh-my-hermes, triage]
7 category: triage
8 phase: support-operations
9 role: operator
10 quality_tier: triage-gated
11---
12
13# Support Operations
14
15This is a Hermes-native `support-operations` workflow skill.
16
17## Why This Exists
18
19`support-operations` turns a bounded customer case into response and escalation guidance without treating drafts or recommendations as helpdesk actions.
20
21## Do Not Use When
22
23- The request clusters a backlog of customer signals to find product patterns or roadmap candidates; use `feedback-triage`.
24- The user only needs a generic, non-support marketing or email rewrite with no case, severity, or escalation context; use `content-operator`.
25- The request asks to send a reply, change ticket priority or status, issue a refund, modify an account, or update a helpdesk; use `connector-operator` with an explicit target and observed result.
26- The request is an active reliability incident or postmortem rather than a support-case response; use `reliability-review`.
27
28## Examples
29
30Good example:
31
32- Prompt: Draft a calm reply for this login-outage customer and tell me whether it needs an engineering escalation.
33- Expected behavior: Prepare a customer-safe reply, severity matrix, engineering escalation recommendation, and owner handoff.
34- Why: The request is one support case with reply and escalation decisions, not a feedback backlog or ticket mutation.
35
36Bad example:
37
38- Prompt: Cluster last quarter's support feedback into roadmap opportunities.
39- Expected behavior: Route to `feedback-triage`, not `support-operations`.
40- Why: A historical signal backlog needs product-pattern triage rather than case-level support guidance.
41
42## Completion Checklist
43
44- The source boundary, signal clusters, severity, and follow-up lane are named.
45- Bug, feature, research, strategy, and coding handoff outcomes stay separate.
46- The next workflow is recommended before any implementation claim.
47
48## Recovery Notes
49
50- If feedback lacks source or severity, ask for the missing signal before coding handoff.
51- If the item is actually a plan or research request, route to that workflow instead of triage.
52
53## Workflow Lane
54
55- Current lane: **Research and company ops** (`product-docs`, `source-finder`, `web-research`, `research`, `best-practice-research`, `autoresearch-goal`, `model-optimization`, `inference-serving`, `+19 more`) - research, signals, ops, and briefings.
56- If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
57- Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.
58
59## Use When
60
61Use when one or a bounded set of support contacts needs response drafting, urgency classification, incident/escalation routing, and follow-up ownership.
62
63 Strong routing signals: `support escalation`, `customer support reply`, `ticket triage`, `고객 지원 에스컬레이션`, `고객 답변 초안`, `지원 티켓 분류`
64
65## Catalog Metadata
66
67Category: `triage`
68Phase: `support-operations`
69Hermes role: `operator`
70Quality tier: `triage-gated`
71Reasoning demand: `standard`
72
73Quality bar:
74
75- State issue, severity, impact, evidence gaps, owner, and next route.
76- Draft a reply without treating it as a sent customer communication.
77
78Handoff policy:
79
80Keep domain framing, clarification, source/evidence synthesis, draft outputs, and next-work routing in Hermes. A prepared brief, review, reply, or plan is not an external action, approval, filing, send, publish, data mutation, implementation, review, CI, or merge claim. Prepare a connector, file, coding, or human-review handoff only when the user explicitly accepts that next step; report it only from observed evidence. Reply text is a draft, escalation is a recommendation, and no ticket state, message send, refund, account action, or customer outcome is claimed.
81
82Required inputs:
83
84- support case
85- known facts
86- customer impact
87- available ownership or escalation path
88
89Expert clarification questions:
90- `support case`
91 - English: Which support case should we examine first?
92 - Korean: 어떤 지원 사례를 먼저 살펴봐야 하나요?
93
94Expected outputs:
95
96- customer-safe reply draft with stated facts, unknowns, and tone
97- issue/severity/impact/escalation matrix
98- internal next-step and owner handoff brief
99- missing repro, account, entitlement, or approval evidence list
100
101Artifact expectations:
102
103- prepared support case brief when a wrapper captures it
104
105Artifact contracts:
106
107This label denotes the machine-enforcement level, not a skill quality score and not an observed evidence state.
108
109- contract_id: `support-operations`; enforcement_level: `guidance_only`; consumer_id: `none`
110
111Safety rules:
112
113- Keep customer-safe facts, unknowns, and escalation recommendations distinct.
114- Do not claim ticket mutation, message send, refund, account action, or case outcome.
115
116## Runtime Evidence
117
118Preferred harness for this skill: `ops-review`.
119
120```sh
121omh runtime record --skill support-operations --harness ops-review --status started
122```
123
124Record observed delegation results; otherwise return `not_available` or `not_observed`.
125Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.
126- Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes.
127Preserve workflow intent and stop conditions; verify before claiming completion.
128
129Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.
130
131Shared product, compatibility, topology, memory, harness, and execution rules: `omh-routing/references/skill-common-rail.md`. Load it when applicable; otherwise name an unavailable capability.