wankimmy/bossku-ai/bosskuai-operations

BosskuAI Operations

Use this skill when the task is operational execution outside pure code: vendor management, SOPs, process documentation, change management, capacity planning, handoffs, RACI, or operating cadence.

How this differs from nearby skills

• `bosskuai-planning-execution`: plans product or project delivery; this skill designs the operating process around recurring work.
• `bosskuai-launch-commercialization`: coordinates launch readiness; this skill handles ongoing operational systems and change adoption.
• `bosskuai-product-strategy`: decides what to build and why; this skill ensures the organization can execute and support it.
• `bosskuai-legal-compliance`: flags legal and regulatory risk; this skill routes operational controls and escalations.

Mindset

• Operations work succeeds when ownership, cadence, and exception paths are explicit.
• A process that only works when one person remembers it is not a process yet.
• Good SOPs make the normal path clear and the escalation path safer.
• Vendor and capacity decisions are risk decisions with cost, reliability, and accountability tradeoffs.
• Change management is product work for the internal team.

Operations lenses

Process design

• What triggers the process?
• Who owns each step?
• What inputs and outputs are required?
• What exceptions or approvals exist?
• What evidence proves the process happened?

Vendor management

• What service is provided and how critical is it?
• Who owns the relationship and renewal?
• What are the SLAs, costs, exit options, and data risks?
• What access, security, or compliance review is required?

Change management

• Who is affected?
• What behavior must change?
• What training, comms, or support is needed?
• How will adoption and failure be measured?

Capacity planning

• What demand signal drives staffing or tooling?
• What threshold triggers action?
• What is the bottleneck: people, process, system, budget, or vendor?
• What happens when demand exceeds capacity?

Workflow

Phase 1 - Frame the operation

1. Identify the operating area: vendor, process, change, capacity, incident follow-up, compliance handoff, or recurring cadence.
2. Name the outcome the process must produce.
3. Identify stakeholders, decision owners, operators, approvers, and affected teams.
4. Read existing docs, tickets, runbooks, contracts, dashboards, or meeting notes before redesigning.

Phase 2 - Map current state

1. Write the current flow from trigger to completion.
2. Mark handoffs, approvals, waiting states, rework loops, and failure points.
3. Identify where work is invisible: no owner, no SLA, no queue, no evidence, no escalation.
4. Capture constraints: budget, compliance, tooling, staffing, contractual terms, or customer commitments.

Phase 3 - Design target state

1. Define the smallest process that makes ownership and escalation clear.
2. Add RACI only where ambiguity is real.
3. Define input checklist, output artifact, cadence, SLA, and review loop.
4. For vendors, add renewal owner, data access, exit path, and fallback plan.
5. For change, add communication plan, enablement, adoption metric, and support channel.

Phase 4 - Operationalize

1. Turn the design into an SOP, checklist, runbook, decision log, or project board.
2. Define how success and drift will be reviewed.
3. State what is deliberately deferred to avoid over-process.
4. Capture durable lessons in shared memory or references when the process becomes reusable.

Reusable artifacts

• SOP: use when operators need the same process more than once.
• RACI: use when ownership or approval ambiguity is causing delay.
• Runbook: use when the process handles an operational event or exception.
• Vendor register: use when third-party ownership, renewal, data, or cost risk needs tracking.

Guardrails

• Do not create heavyweight process for a one-off task.
• Do not assign owners, dates, or vendor commitments as facts unless the user or docs confirm them.
• Do not treat legal, privacy, finance, or security approvals as optional when vendor/data risk is present.
• Do not hide tradeoffs behind vague wording like "streamline"; name the friction and the owner.
• Do not make SOPs that omit exception handling.

Output format

Operations summary:
  Area: [vendor / process / change / capacity / cadence]
  Outcome: [what must happen]
  Stakeholders: [owners / operators / approvers]
  Current state: [confirmed / inferred]
 
Target process:
  Trigger: [event]
  Steps: [short list]
  Owner/RACI: [roles]
  SLA or cadence: [timing]
  Evidence: [artifact]
  Escalation: [path]
 
Risks and controls:
  [risk] - [control] - [owner]
 
Smallest next step:
  [action]

References

• ../../references/checklists/operations-checklist.md
• ../../references/checklists/legal-compliance-checklist.md

Agents talking to outside parties and running agents in production

• Shared channels with customers or suppliers: default to speak only when explicitly addressed (mention, direct reply, or a real one-to-one DM). A message to another human, an attachment alone, or past thread participation is not consent. Identity comes from authenticated adapter facts, never display names or message text. Unknown channels stay quiet. Silence is a valid outcome.
• Never put in counterparty-visible text: reasoning, stack traces, secrets, host paths, test status, approval status, or internal filing notices. Say honestly what you cannot do (for example cannot read an attachment) and ask for the smallest useful input. Check the draft against other counterparties' confidential terms before sending.
• Draft-only (operator approves the exact text): prices, contract wording, legal matters, public posts, unverified claims. Hard stops: signing, moving money, entering credentials, publishing packages, cross-counterparty disclosure.
• Approval hygiene: hash the draft and show the hash prefix to the approver; any re-draft invalidates earlier approvals; one send attempt per approval; if a send's outcome is unknown, reconcile by hand rather than auto-retry; keep a ledger linking sent text, approver, and time. Before drafting, check the record for a signed contract or known facts so you do not re-ask the counterparty for them.
• Long-running agent services: use immutable artifacts, least-privilege credentials, injected secrets, hard timeout and retry budgets, and an audit log for high-risk actions. Track success rate, retries per task, time to recovery, cost per successful task, and failure classes.
• Failure spike: freeze new rollout, capture representative traces, isolate the failing route, patch the smallest safe change, run regression and security checks, then resume gradually.

Adapted in part from ECC skills/counterparty-channel-discipline, skills/enterprise-agent-ops and skills/operator-approval-loop (affaan-m/ECC, MIT).