Operations
Umbrella skill for business operations: vendor management, runbooks, process documentation, risk assessment, capacity planning, change management, compliance tracking, status reporting, and process optimization. Each mode loads its own reference files on demand.
Scope: Operational workflows that keep the business running. Use csuite for strategic decisions, finance for budgeting/forecasting, and hr for people operations.
Mode Detection
Classify the request into exactly one mode. If it spans multiple, choose the primary and note the secondary.
| Mode |
Signal Phrases |
Reference |
| RUNBOOK |
runbook, procedure, on-call, playbook, step-by-step, ops task |
references/runbook-authoring.md |
| RISK |
risk assessment, risk register, what could go wrong, risk matrix |
references/risk-assessment.md |
| VENDOR |
vendor review, vendor evaluation, contract review, procurement |
references/vendor-management.md |
| PROCESS |
process doc, SOP, RACI, workflow documentation, process map |
references/process-documentation.md |
| CHANGE |
change request, change management, CAB, rollout, deployment change |
references/change-management.md |
| CAPACITY |
capacity plan, resource allocation, utilization, headcount planning |
references/process-documentation.md |
| COMPLIANCE |
compliance, audit prep, SOC 2, ISO 27001, GDPR, regulatory |
references/risk-assessment.md |
| STATUS |
status report, weekly update, project health, KPIs |
(no deep reference needed) |
| OPTIMIZE |
process improvement, bottleneck, streamline, too many steps |
references/process-documentation.md |
Always load references/llm-ops-failure-modes.md regardless of mode. It contains the failure patterns that apply across all operations work.
Instructions
Mode: RUNBOOK
Framework: SCOPE -> AUTHOR -> VERIFY
Phase 1: SCOPE -- Define what the runbook covers.
- Name the task, its frequency, and who runs it
- List prerequisites: access, tools, credentials, prior state
- Identify the trigger: scheduled, event-driven, or manual invocation
- Ask: "If a new hire ran this at 3am during an incident, what would they need?"
Gate: Task named. Prerequisites listed. Trigger defined.
Phase 2: AUTHOR -- Write the procedure with painful specificity.
Load references/runbook-authoring.md.
Critical rules:
- Every step has: exact command/action, expected result, failure handling
- "Run the script" is NOT a step.
python sync.py --prod --dry-run from /opt/ops/ as deploy-user IS a step
- Include verification after every state-changing step
- Rollback procedure for the entire runbook AND per-step rollback where applicable
- Escalation paths with names, contact methods, and when-to-escalate triggers
| Step Component |
Required |
Example |
| Action |
Yes |
kubectl rollout restart deployment/api -n production |
| Expected result |
Yes |
"Pods restart within 60s. kubectl get pods shows 3/3 Running." |
| Failure handling |
Yes |
"If pods stay in CrashLoopBackOff >2min, proceed to Rollback." |
| Verification |
Yes |
`curl -s https://api.example.com/health |
| Rollback |
Per-step |
kubectl rollout undo deployment/api -n production |
Gate: Every step has all five components. Rollback procedure exists. Escalation path defined.
Phase 3: VERIFY -- Validate the runbook is actually usable.
- Walk through the runbook as if you have never seen the system
- Flag any step that requires unstated knowledge
- Confirm the troubleshooting table covers symptoms from each step's failure mode
- Check: could someone follow this at 3am with no prior context?
Gate: All steps self-contained. No implicit knowledge. Troubleshooting table complete.
Mode: RISK
Framework: IDENTIFY -> ASSESS -> MITIGATE
Phase 1: IDENTIFY -- Enumerate risks systematically by category.
Load references/risk-assessment.md.
| Category |
What to Look For |
| Operational |
Process failures, staffing gaps, system outages, single points of failure |
| Financial |
Budget overruns, vendor cost increases, revenue impact, currency exposure |
| Compliance |
Regulatory violations, audit findings, policy breaches, certification gaps |
| Strategic |
Market changes, competitive threats, technology shifts, dependency risks |
| Reputational |
Customer impact, public perception, partner relationships, data incidents |
| Security |
Data breaches, access control failures, third-party vulnerabilities |
- Extend risk identification beyond obvious items. Ask: "What kills us if it happens, even if it seems unlikely?"
- Separate risks from issues. A risk might happen. An issue already has.
Gate: Risks enumerated across all applicable categories. Each risk has a clear description.
Phase 2: ASSESS -- Score each risk on probability and impact.
Apply the probability x impact matrix:
|
Low Impact |
Medium Impact |
High Impact |
| High Probability |
Medium |
High |
Critical |
| Medium Probability |
Low |
Medium |
High |
| Low Probability |
Low |
Low |
Medium |
For each risk:
- Probability: base on evidence, not optimism. "It hasn't happened yet" is not "low probability"
- Impact: quantify in dollars, hours, or affected users where possible
- Risk level: derived from matrix, not gut feel
Gate: Every risk scored. No unquantified "High" without supporting rationale.
Phase 3: MITIGATE -- Plan mitigations and track residual risk.
For each High/Critical risk:
- Mitigation action (specific, not "monitor the situation")
- Owner (named person, not "the team")
- Timeline (date, not "soon")
- Residual risk after mitigation
- Acceptance criteria: what makes the residual risk acceptable?
Gate: All High/Critical risks have mitigations with owners and dates. Residual risk documented.
Mode: VENDOR
Framework: EVALUATE -> SCORE -> RECOMMEND
Phase 1: EVALUATE -- Gather structured information.
Load references/vendor-management.md.
Required inputs:
- Vendor name and what they provide
- Context: new evaluation, renewal, or comparison
- Available data: proposal, contract, performance history, pricing
Due diligence checklist (minimum):
- Financial stability signals
- Security posture (SOC 2, penetration testing, incident history)
- Customer references (ask for churned customers too)
- Contract terms: auto-renewal, termination notice, price escalation clauses
- Data portability: export format, migration support, data deletion
Gate: Due diligence complete. Contract terms reviewed. Red flags documented.
Phase 2: SCORE -- Apply the vendor scorecard.
| Dimension |
Weight |
Score (1-10) |
| Functional fit |
5x |
|
| Total cost of ownership |
4x |
|
| Integration complexity |
4x |
|
| Support quality |
3x |
|
| Security/compliance |
3x |
|
| Data portability |
3x |
|
| Company stability |
2x |
|
| Contract flexibility |
2x |
|
TCO must include: license, implementation, training, support, ongoing maintenance, exit costs. License price alone is not TCO.
Gate: All dimensions scored with rationale. TCO calculated for Year 1 and Year 3.
Phase 3: RECOMMEND -- Deliver verdict with negotiation points.
- Verdict: Proceed / Negotiate / Pass
- Key strengths and concerns
- Negotiation leverage points
- Contract review triggers (price escalation >X%, SLA misses, acquisition)
- Performance monitoring plan post-contract
Gate: Recommendation stated. Negotiation points listed. Monitoring plan defined.
Mode: PROCESS
Framework: MAP -> DOCUMENT -> OPTIMIZE
Phase 1: MAP -- Capture how the process actually works today.
Load references/process-documentation.md.
- Map the real process, not the idealized version. "We're supposed to do X but actually we do Y" is the most valuable input.
- Capture every step, decision point, handoff, and exception
- Identify: who does it (role, not name), what triggers it, what it produces, how long it takes
- Document exceptions and edge cases — these are where processes actually break
Gate: Current state mapped. All steps, handoffs, and exceptions documented.
Phase 2: DOCUMENT -- Produce the SOP.
Structure:
- Purpose and scope
- RACI matrix (Responsible, Accountable, Consulted, Informed for each step)
- Step-by-step procedure with inputs, actions, outputs, and exception handling
- Metrics: what to measure, target values, how to measure
RACI rules:
- Exactly one A (Accountable) per step. Multiple As = no one is accountable.
- R (Responsible) is who does the work. A is who owns the outcome.
- If a step has no R, it doesn't get done. If it has no A, no one notices when it doesn't.
Gate: SOP complete. RACI has exactly one A per step. Exceptions documented.
Phase 3: OPTIMIZE -- Identify improvement opportunities.
- Identify waste: waiting, rework, unnecessary handoffs, over-processing, manual work that could be automated
- Bottleneck analysis: which step constrains throughput?
- Recommendations: eliminate, automate, parallelize, simplify
- Before/after comparison with estimated impact
Gate: Bottlenecks identified. Recommendations specific and measurable.
Mode: CHANGE
Framework: ASSESS -> PLAN -> EXECUTE
Phase 1: ASSESS -- Define the change and its impact.
Load references/change-management.md.
- What is changing and why (business justification, not just "improvement")
- Who is affected: users, systems, processes, teams
- Impact assessment by area (users, systems, processes, cost) rated High/Medium/Low
- Risk assessment: what could go wrong, likelihood, mitigation
- Resistance forecast: who will resist and why
Gate: Change defined. Impact assessed by area. Risks identified.
Phase 2: PLAN -- Build the implementation and communication plan.
| Plan Component |
Required Elements |
| Implementation |
Steps, owners, timeline, dependencies |
| Communication |
Audience, message, channel, timing |
| Training |
What skills needed, delivery method, timeline |
| Rollback |
Trigger criteria, steps, verification |
| Approval |
Who approves, role, current status |
Communication rules:
- Explain WHY before WHAT
- Communicate early. Surprises create resistance; previews create buy-in.
- Acknowledge what is being lost, not just what is being gained
- "Everyone" is not a stakeholder. "200 users in the billing team" is.
Gate: All plan components complete. Rollback plan has trigger criteria. Approvals identified.
Phase 3: EXECUTE -- Monitor adoption and sustain.
- Track adoption metrics
- Address resistance (specific actions, not "manage change")
- Reinforce new behaviors
- Document lessons learned
- Define success criteria and measurement timeline
Gate: Adoption metrics defined. Lessons captured. Success criteria measurable.
Mode: CAPACITY
Framework: INVENTORY -> FORECAST -> DECIDE
Phase 1: INVENTORY -- Map current capacity.
- List team members, roles, and current allocation
- Calculate actual available hours (subtract meetings, PTO, on-call, admin)
- Map current work to people
| Role Type |
Target Utilization |
Rationale |
| IC / Specialist |
75-80% |
Buffer for reactive work and growth |
| Manager |
60-70% |
Management overhead, 1:1s, meetings |
| On-call / Support |
50-60% |
Interrupt-driven work is unpredictable |
Gate: Current capacity mapped. Utilization calculated. Overallocations identified.
Phase 2: FORECAST -- Model upcoming demand.
- List upcoming projects with resource requirements and timelines
- Identify skill bottlenecks (the constraint is usually a specific skill, not generic headcount)
- Model scenarios: do nothing, hire X, deprioritize Y, contract Z
Gate: Demand mapped. Bottlenecks identified. Scenarios modeled.
Phase 3: DECIDE -- Recommend action.
- Compare scenarios: outcome, cost, timeline, risk
- Recommend: hire, contract, reprioritize, delay, or split
- Preserve buffer capacity for unplanned work (target 75-80%). 100% means no buffer for surprises.
Gate: Recommendation stated. Trade-offs explicit. Buffer preserved.
Mode: COMPLIANCE
Framework: MAP -> GAP -> REMEDIATE
Phase 1: MAP -- Identify applicable frameworks and current state.
| Framework |
Focus |
Key Requirements |
| SOC 2 |
Service organizations |
Security, availability, processing integrity, confidentiality, privacy |
| ISO 27001 |
Information security |
Risk assessment, security controls, continuous improvement |
| GDPR |
Data privacy (EU) |
Consent, data rights, breach notification, DPO |
| HIPAA |
Healthcare (US) |
PHI protection, access controls, audit trails |
| PCI DSS |
Payment card data |
Encryption, access control, vulnerability management |
- Inventory controls mapped to framework requirements
- Document control owners and evidence locations
Gate: Frameworks identified. Controls inventoried.
Phase 2: GAP -- Find what is missing or deficient.
Load references/risk-assessment.md for risk-based prioritization of gaps.
- Requirements vs. current state for each control
- Evidence gaps: what evidence is needed but not collected
- Priority: compliance risk x remediation effort
Gate: Gaps identified and prioritized. Evidence gaps documented.
Phase 3: REMEDIATE -- Plan and track closure.
- Remediation plan with owner, timeline, and verification method
- Audit calendar with evidence collection deadlines
- Monitoring: control effectiveness tracking
Gate: Remediation plan complete. Audit calendar set. Owners assigned.
Mode: STATUS
Framework: GATHER -> SYNTHESIZE -> DELIVER
Produce a status report covering:
| Section |
Content |
| Executive Summary |
3-4 sentences. What is on track, what needs attention, key wins. |
| Overall Status |
On Track / At Risk / Off Track with justification |
| Key Metrics |
KPI, target, actual, trend, status |
| Accomplishments |
What got done this period |
| In Progress |
Item, owner, status, ETA |
| Risks and Issues |
Risk, impact, mitigation, owner |
| Decisions Needed |
Decision, context, deadline, recommendation |
| Next Priorities |
Top 3 for next period |
Rules:
- Lead with the headline. Leadership reads the first 3 lines.
- Be honest about risks. Surfacing issues early builds trust. Surprises erode it.
- For each decision needed, provide context AND a recommendation. Include a recommendation with every decision request.
Mode: OPTIMIZE
Framework: MAP -> ANALYZE -> REDESIGN
Phase 1: MAP -- Document current state with timing.
Load references/process-documentation.md.
- Every step, decision point, and handoff with time estimates
- Identify: who, what, how long, what triggers, what blocks
Phase 2: ANALYZE -- Identify waste.
| Waste Type |
What to Look For |
| Waiting |
Time in queues, waiting for approvals |
| Rework |
Steps that fail and repeat |
| Handoffs |
Each handoff = potential failure/delay point |
| Over-processing |
Steps that add no value |
| Manual work |
Tasks that could be automated |
Phase 3: REDESIGN -- Propose improvements.
- Eliminate unnecessary steps
- Automate where deterministic
- Reduce handoffs
- Parallelize independent steps
- Before/after comparison with: time saved, error rate reduction, cost savings
Error Handling
| Error |
Cause |
Solution |
| Vague runbook steps |
LLM defaults to abstract language |
Force each step through the 5-component template. Reject steps without exact commands. |
| Underestimated risk |
Optimism bias in probability scoring |
Challenge every "Low" probability. Ask: "What evidence supports Low, not Medium?" |
| Generic process docs |
Template fill without reality check |
Ask how the process actually works today, not how it should work. |
| Missing rollback |
Assumed success path only |
Require rollback before marking any change/runbook complete. |
| Scorecard inflation |
All vendors score 7+ |
Force relative scoring. At least one dimension per vendor must be below 5. |
| RACI with multiple As |
Accountability diffusion |
Enforce exactly one A per step. Multiple As = no one accountable. |
| Compliance checkbox theater |
Controls documented but not tested |
Require evidence of control effectiveness, not just existence. |
Reference Loading Table
| Mode |
Reference |
Content |
| RUNBOOK |
references/runbook-authoring.md |
Step structure, verification checklists, rollback procedures, escalation paths |
| RISK, COMPLIANCE |
references/risk-assessment.md |
Probability x impact matrix, risk categories, mitigation planning, residual risk tracking |
| VENDOR |
references/vendor-management.md |
Vendor scorecard, due diligence checklist, contract review triggers, performance monitoring |
| PROCESS, CAPACITY, OPTIMIZE |
references/process-documentation.md |
Process mapping, RACI matrices, bottleneck analysis, optimization methodology |
| CHANGE |
references/change-management.md |
Change request workflows, impact assessment, stakeholder communication, rollback criteria |
| ALL |
references/llm-ops-failure-modes.md |
LLM failure patterns in operations: vague procedures, underestimated risks, generic templates |
1---2name: operations-23description: Business operations workflows — vendor management, runbooks, process documentation, risk assessment, capacity planning, change management, compliance tracking. Use when reviewing vendors, writing runbooks, documenting processes, assessing risk, planning capacity, or managing change.4---5
6# Operations
7
8Umbrella skill for business operations: vendor management, runbooks, process documentation, risk assessment, capacity planning, change management, compliance tracking, status reporting, and process optimization. Each mode loads its own reference files on demand.
9
10**Scope**: Operational workflows that keep the business running. Use csuite for strategic decisions, finance for budgeting/forecasting, and hr for people operations.
11
12---
13
14## Mode Detection
15
16Classify the request into exactly one mode. If it spans multiple, choose the primary and note the secondary.
17
18| Mode | Signal Phrases | Reference |
19|------|---------------|-----------|
20| **RUNBOOK** | runbook, procedure, on-call, playbook, step-by-step, ops task | `references/runbook-authoring.md` |
21| **RISK** | risk assessment, risk register, what could go wrong, risk matrix | `references/risk-assessment.md` |
22| **VENDOR** | vendor review, vendor evaluation, contract review, procurement | `references/vendor-management.md` |
23| **PROCESS** | process doc, SOP, RACI, workflow documentation, process map | `references/process-documentation.md` |
24| **CHANGE** | change request, change management, CAB, rollout, deployment change | `references/change-management.md` |
25| **CAPACITY** | capacity plan, resource allocation, utilization, headcount planning | `references/process-documentation.md` |
26| **COMPLIANCE** | compliance, audit prep, SOC 2, ISO 27001, GDPR, regulatory | `references/risk-assessment.md` |
27| **STATUS** | status report, weekly update, project health, KPIs | (no deep reference needed) |
28| **OPTIMIZE** | process improvement, bottleneck, streamline, too many steps | `references/process-documentation.md` |
29
30Always load `references/llm-ops-failure-modes.md` regardless of mode. It contains the failure patterns that apply across all operations work.
31
32---
33
34## Instructions
35
36### Mode: RUNBOOK
37
38**Framework**: SCOPE -> AUTHOR -> VERIFY
39
40**Phase 1: SCOPE** -- Define what the runbook covers.
41
42- Name the task, its frequency, and who runs it
43- List prerequisites: access, tools, credentials, prior state
44- Identify the trigger: scheduled, event-driven, or manual invocation
45- Ask: "If a new hire ran this at 3am during an incident, what would they need?"
46
47**Gate**: Task named. Prerequisites listed. Trigger defined.
48
49**Phase 2: AUTHOR** -- Write the procedure with painful specificity.
50
51Load `references/runbook-authoring.md`.
52
53Critical rules:
54- Every step has: exact command/action, expected result, failure handling
55- "Run the script" is NOT a step. `python sync.py --prod --dry-run` from `/opt/ops/` as `deploy-user` IS a step
56- Include verification after every state-changing step
57- Rollback procedure for the entire runbook AND per-step rollback where applicable
58- Escalation paths with names, contact methods, and when-to-escalate triggers
59
60| Step Component | Required | Example |
61|---------------|----------|---------|
62| Action | Yes | `kubectl rollout restart deployment/api -n production` |
63| Expected result | Yes | "Pods restart within 60s. `kubectl get pods` shows 3/3 Running." |
64| Failure handling | Yes | "If pods stay in CrashLoopBackOff >2min, proceed to Rollback." |
65| Verification | Yes | `curl -s https://api.example.com/health | jq .status` returns `"ok"` |
66| Rollback | Per-step | `kubectl rollout undo deployment/api -n production` |
67
68**Gate**: Every step has all five components. Rollback procedure exists. Escalation path defined.
69
70**Phase 3: VERIFY** -- Validate the runbook is actually usable.
71
72- Walk through the runbook as if you have never seen the system
73- Flag any step that requires unstated knowledge
74- Confirm the troubleshooting table covers symptoms from each step's failure mode
75- Check: could someone follow this at 3am with no prior context?
76
77**Gate**: All steps self-contained. No implicit knowledge. Troubleshooting table complete.
78
79---
80
81### Mode: RISK
82
83**Framework**: IDENTIFY -> ASSESS -> MITIGATE
84
85**Phase 1: IDENTIFY** -- Enumerate risks systematically by category.
86
87Load `references/risk-assessment.md`.
88
89| Category | What to Look For |
90|----------|-----------------|
91| Operational | Process failures, staffing gaps, system outages, single points of failure |
92| Financial | Budget overruns, vendor cost increases, revenue impact, currency exposure |
93| Compliance | Regulatory violations, audit findings, policy breaches, certification gaps |
94| Strategic | Market changes, competitive threats, technology shifts, dependency risks |
95| Reputational | Customer impact, public perception, partner relationships, data incidents |
96| Security | Data breaches, access control failures, third-party vulnerabilities |
97
98- Extend risk identification beyond obvious items. Ask: "What kills us if it happens, even if it seems unlikely?"
99- Separate risks from issues. A risk might happen. An issue already has.
100
101**Gate**: Risks enumerated across all applicable categories. Each risk has a clear description.
102
103**Phase 2: ASSESS** -- Score each risk on probability and impact.
104
105Apply the probability x impact matrix:
106
107| | Low Impact | Medium Impact | High Impact |
108|---|-----------|---------------|-------------|
109| **High Probability** | Medium | High | Critical |
110| **Medium Probability** | Low | Medium | High |
111| **Low Probability** | Low | Low | Medium |
112
113For each risk:
114- Probability: base on evidence, not optimism. "It hasn't happened yet" is not "low probability"
115- Impact: quantify in dollars, hours, or affected users where possible
116- Risk level: derived from matrix, not gut feel
117
118**Gate**: Every risk scored. No unquantified "High" without supporting rationale.
119
120**Phase 3: MITIGATE** -- Plan mitigations and track residual risk.
121
122For each High/Critical risk:
123- Mitigation action (specific, not "monitor the situation")
124- Owner (named person, not "the team")
125- Timeline (date, not "soon")
126- Residual risk after mitigation
127- Acceptance criteria: what makes the residual risk acceptable?
128
129**Gate**: All High/Critical risks have mitigations with owners and dates. Residual risk documented.
130
131---
132
133### Mode: VENDOR
134
135**Framework**: EVALUATE -> SCORE -> RECOMMEND
136
137**Phase 1: EVALUATE** -- Gather structured information.
138
139Load `references/vendor-management.md`.
140
141Required inputs:
142- Vendor name and what they provide
143- Context: new evaluation, renewal, or comparison
144- Available data: proposal, contract, performance history, pricing
145
146Due diligence checklist (minimum):
147- Financial stability signals
148- Security posture (SOC 2, penetration testing, incident history)
149- Customer references (ask for churned customers too)
150- Contract terms: auto-renewal, termination notice, price escalation clauses
151- Data portability: export format, migration support, data deletion
152
153**Gate**: Due diligence complete. Contract terms reviewed. Red flags documented.
154
155**Phase 2: SCORE** -- Apply the vendor scorecard.
156
157| Dimension | Weight | Score (1-10) |
158|-----------|--------|-------------|
159| Functional fit | 5x | |
160| Total cost of ownership | 4x | |
161| Integration complexity | 4x | |
162| Support quality | 3x | |
163| Security/compliance | 3x | |
164| Data portability | 3x | |
165| Company stability | 2x | |
166| Contract flexibility | 2x | |
167
168TCO must include: license, implementation, training, support, ongoing maintenance, exit costs. License price alone is not TCO.
169
170**Gate**: All dimensions scored with rationale. TCO calculated for Year 1 and Year 3.
171
172**Phase 3: RECOMMEND** -- Deliver verdict with negotiation points.
173
174- Verdict: Proceed / Negotiate / Pass
175- Key strengths and concerns
176- Negotiation leverage points
177- Contract review triggers (price escalation >X%, SLA misses, acquisition)
178- Performance monitoring plan post-contract
179
180**Gate**: Recommendation stated. Negotiation points listed. Monitoring plan defined.
181
182---
183
184### Mode: PROCESS
185
186**Framework**: MAP -> DOCUMENT -> OPTIMIZE
187
188**Phase 1: MAP** -- Capture how the process actually works today.
189
190Load `references/process-documentation.md`.
191
192- Map the real process, not the idealized version. "We're supposed to do X but actually we do Y" is the most valuable input.
193- Capture every step, decision point, handoff, and exception
194- Identify: who does it (role, not name), what triggers it, what it produces, how long it takes
195- Document exceptions and edge cases — these are where processes actually break
196
197**Gate**: Current state mapped. All steps, handoffs, and exceptions documented.
198
199**Phase 2: DOCUMENT** -- Produce the SOP.
200
201Structure:
202- Purpose and scope
203- RACI matrix (Responsible, Accountable, Consulted, Informed for each step)
204- Step-by-step procedure with inputs, actions, outputs, and exception handling
205- Metrics: what to measure, target values, how to measure
206
207RACI rules:
208- Exactly one A (Accountable) per step. Multiple As = no one is accountable.
209- R (Responsible) is who does the work. A is who owns the outcome.
210- If a step has no R, it doesn't get done. If it has no A, no one notices when it doesn't.
211
212**Gate**: SOP complete. RACI has exactly one A per step. Exceptions documented.
213
214**Phase 3: OPTIMIZE** -- Identify improvement opportunities.
215
216- Identify waste: waiting, rework, unnecessary handoffs, over-processing, manual work that could be automated
217- Bottleneck analysis: which step constrains throughput?
218- Recommendations: eliminate, automate, parallelize, simplify
219- Before/after comparison with estimated impact
220
221**Gate**: Bottlenecks identified. Recommendations specific and measurable.
222
223---
224
225### Mode: CHANGE
226
227**Framework**: ASSESS -> PLAN -> EXECUTE
228
229**Phase 1: ASSESS** -- Define the change and its impact.
230
231Load `references/change-management.md`.
232
233- What is changing and why (business justification, not just "improvement")
234- Who is affected: users, systems, processes, teams
235- Impact assessment by area (users, systems, processes, cost) rated High/Medium/Low
236- Risk assessment: what could go wrong, likelihood, mitigation
237- Resistance forecast: who will resist and why
238
239**Gate**: Change defined. Impact assessed by area. Risks identified.
240
241**Phase 2: PLAN** -- Build the implementation and communication plan.
242
243| Plan Component | Required Elements |
244|---------------|-------------------|
245| Implementation | Steps, owners, timeline, dependencies |
246| Communication | Audience, message, channel, timing |
247| Training | What skills needed, delivery method, timeline |
248| Rollback | Trigger criteria, steps, verification |
249| Approval | Who approves, role, current status |
250
251Communication rules:
252- Explain WHY before WHAT
253- Communicate early. Surprises create resistance; previews create buy-in.
254- Acknowledge what is being lost, not just what is being gained
255- "Everyone" is not a stakeholder. "200 users in the billing team" is.
256
257**Gate**: All plan components complete. Rollback plan has trigger criteria. Approvals identified.
258
259**Phase 3: EXECUTE** -- Monitor adoption and sustain.
260
261- Track adoption metrics
262- Address resistance (specific actions, not "manage change")
263- Reinforce new behaviors
264- Document lessons learned
265- Define success criteria and measurement timeline
266
267**Gate**: Adoption metrics defined. Lessons captured. Success criteria measurable.
268
269---
270
271### Mode: CAPACITY
272
273**Framework**: INVENTORY -> FORECAST -> DECIDE
274
275**Phase 1: INVENTORY** -- Map current capacity.
276
277- List team members, roles, and current allocation
278- Calculate actual available hours (subtract meetings, PTO, on-call, admin)
279- Map current work to people
280
281| Role Type | Target Utilization | Rationale |
282|-----------|-------------------|-----------|
283| IC / Specialist | 75-80% | Buffer for reactive work and growth |
284| Manager | 60-70% | Management overhead, 1:1s, meetings |
285| On-call / Support | 50-60% | Interrupt-driven work is unpredictable |
286
287**Gate**: Current capacity mapped. Utilization calculated. Overallocations identified.
288
289**Phase 2: FORECAST** -- Model upcoming demand.
290
291- List upcoming projects with resource requirements and timelines
292- Identify skill bottlenecks (the constraint is usually a specific skill, not generic headcount)
293- Model scenarios: do nothing, hire X, deprioritize Y, contract Z
294
295**Gate**: Demand mapped. Bottlenecks identified. Scenarios modeled.
296
297**Phase 3: DECIDE** -- Recommend action.
298
299- Compare scenarios: outcome, cost, timeline, risk
300- Recommend: hire, contract, reprioritize, delay, or split
301- Preserve buffer capacity for unplanned work (target 75-80%). 100% means no buffer for surprises.
302
303**Gate**: Recommendation stated. Trade-offs explicit. Buffer preserved.
304
305---
306
307### Mode: COMPLIANCE
308
309**Framework**: MAP -> GAP -> REMEDIATE
310
311**Phase 1: MAP** -- Identify applicable frameworks and current state.
312
313| Framework | Focus | Key Requirements |
314|-----------|-------|-----------------|
315| SOC 2 | Service organizations | Security, availability, processing integrity, confidentiality, privacy |
316| ISO 27001 | Information security | Risk assessment, security controls, continuous improvement |
317| GDPR | Data privacy (EU) | Consent, data rights, breach notification, DPO |
318| HIPAA | Healthcare (US) | PHI protection, access controls, audit trails |
319| PCI DSS | Payment card data | Encryption, access control, vulnerability management |
320
321- Inventory controls mapped to framework requirements
322- Document control owners and evidence locations
323
324**Gate**: Frameworks identified. Controls inventoried.
325
326**Phase 2: GAP** -- Find what is missing or deficient.
327
328Load `references/risk-assessment.md` for risk-based prioritization of gaps.
329
330- Requirements vs. current state for each control
331- Evidence gaps: what evidence is needed but not collected
332- Priority: compliance risk x remediation effort
333
334**Gate**: Gaps identified and prioritized. Evidence gaps documented.
335
336**Phase 3: REMEDIATE** -- Plan and track closure.
337
338- Remediation plan with owner, timeline, and verification method
339- Audit calendar with evidence collection deadlines
340- Monitoring: control effectiveness tracking
341
342**Gate**: Remediation plan complete. Audit calendar set. Owners assigned.
343
344---
345
346### Mode: STATUS
347
348**Framework**: GATHER -> SYNTHESIZE -> DELIVER
349
350Produce a status report covering:
351
352| Section | Content |
353|---------|---------|
354| Executive Summary | 3-4 sentences. What is on track, what needs attention, key wins. |
355| Overall Status | On Track / At Risk / Off Track with justification |
356| Key Metrics | KPI, target, actual, trend, status |
357| Accomplishments | What got done this period |
358| In Progress | Item, owner, status, ETA |
359| Risks and Issues | Risk, impact, mitigation, owner |
360| Decisions Needed | Decision, context, deadline, recommendation |
361| Next Priorities | Top 3 for next period |
362
363Rules:
364- Lead with the headline. Leadership reads the first 3 lines.
365- Be honest about risks. Surfacing issues early builds trust. Surprises erode it.
366- For each decision needed, provide context AND a recommendation. Include a recommendation with every decision request.
367
368---
369
370### Mode: OPTIMIZE
371
372**Framework**: MAP -> ANALYZE -> REDESIGN
373
374**Phase 1: MAP** -- Document current state with timing.
375
376Load `references/process-documentation.md`.
377
378- Every step, decision point, and handoff with time estimates
379- Identify: who, what, how long, what triggers, what blocks
380
381**Phase 2: ANALYZE** -- Identify waste.
382
383| Waste Type | What to Look For |
384|-----------|-----------------|
385| Waiting | Time in queues, waiting for approvals |
386| Rework | Steps that fail and repeat |
387| Handoffs | Each handoff = potential failure/delay point |
388| Over-processing | Steps that add no value |
389| Manual work | Tasks that could be automated |
390
391**Phase 3: REDESIGN** -- Propose improvements.
392
393- Eliminate unnecessary steps
394- Automate where deterministic
395- Reduce handoffs
396- Parallelize independent steps
397- Before/after comparison with: time saved, error rate reduction, cost savings
398
399---
400
401## Error Handling
402
403| Error | Cause | Solution |
404|-------|-------|----------|
405| Vague runbook steps | LLM defaults to abstract language | Force each step through the 5-component template. Reject steps without exact commands. |
406| Underestimated risk | Optimism bias in probability scoring | Challenge every "Low" probability. Ask: "What evidence supports Low, not Medium?" |
407| Generic process docs | Template fill without reality check | Ask how the process actually works today, not how it should work. |
408| Missing rollback | Assumed success path only | Require rollback before marking any change/runbook complete. |
409| Scorecard inflation | All vendors score 7+ | Force relative scoring. At least one dimension per vendor must be below 5. |
410| RACI with multiple As | Accountability diffusion | Enforce exactly one A per step. Multiple As = no one accountable. |
411| Compliance checkbox theater | Controls documented but not tested | Require evidence of control effectiveness, not just existence. |
412
413---
414
415## Reference Loading Table
416
417| Mode | Reference | Content |
418|------|-----------|---------|
419| RUNBOOK | `references/runbook-authoring.md` | Step structure, verification checklists, rollback procedures, escalation paths |
420| RISK, COMPLIANCE | `references/risk-assessment.md` | Probability x impact matrix, risk categories, mitigation planning, residual risk tracking |
421| VENDOR | `references/vendor-management.md` | Vendor scorecard, due diligence checklist, contract review triggers, performance monitoring |
422| PROCESS, CAPACITY, OPTIMIZE | `references/process-documentation.md` | Process mapping, RACI matrices, bottleneck analysis, optimization methodology |
423| CHANGE | `references/change-management.md` | Change request workflows, impact assessment, stakeholder communication, rollback criteria |
424| ALL | `references/llm-ops-failure-modes.md` | LLM failure patterns in operations: vague procedures, underestimated risks, generic templates |