operations

name: operations description: "Business operations: vendor management, runbooks, process docs, risk assessment, capacity planning, change management, compliance tracking." routing: triggers: - "operations" - "vendor review" - "runbook" - "process documentation" - "risk assessment" - "capacity plan" - "change management" - "compliance tracking" category: business force_route: false pairs_with: - csuite - finance - hr

user-invocable: true

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.

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

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.

• 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:

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.

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.

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

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.

• 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:

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.

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

Reference Loading Table