business-ops

name	business-ops
description	Route one business signal through a replayable governed ops graph: classify, docs, release, work, outreach, spend, and proof, with consequential actions stopping at the right gate.
runx	{"category":"ops"}

Business Ops

Turn one business signal into a replayable operations graph.

business-ops is the generic public example for how runx makes agentic business work composable without giving the agent ambient authority. It is a deterministic graph skeleton: it classifies one signal, fans it into bounded lanes, records why each lane exists, names the real skill or provider lane that would replace the fixture, and stops before any live send, spend, publish, merge, deploy, or customer-visible action.

This is not a provider integration and not an operator dashboard. It is the small core shape that teams copy when they want one objective to fan out into a chain of skills, then replay that chain with receipts.

When the route itself should become durable, use route_and_append. That runner classifies the signal, appends the classification packet through data-store, and reads back the projection. The same graph can use local JSON, SQLite, Postgres, D1, Redis, or a product adapter by changing the data_source_ref binding.

What this skill does

• Classifies one business signal before doing work.
• Fans the signal through representative lanes: docs, release, issue/PR, outreach planning, spend quoting, and proof audit.
• Produces structured lane packets with authority, gate, handoff, evidence, and readback fields.
• Demonstrates the runx split between proposal work and consequential action: drafts and plans can be produced, but sends, spend, merges, publishes, and deploys require a separate approval and execution lane.
• Gives downstream agents a clear handoff target instead of vague prose.
• Optionally persists the classified route for replay through data-store.

What this skill deliberately does not do

• It does not call private providers, mutate a repo, post to GitHub, send email, schedule campaigns, move money, publish releases, or deploy services.
• It does not duplicate ops-desk, product operator skills, send-as, vendor-specific provider skills, release, issue-to-pr, spend, or receipt-audit skills.
• It does not turn "outbound marketing" into a hidden side effect. Outreach is a plan lane here; real delivery routes to send-as and then a provider adapter. Branded provider skills are concrete adapters, not branches in this core graph.
• It does not treat the graph receipt as proof that an external provider action happened. Provider actions need provider evidence and their own receipt.

When to use this skill

• To show how runx chains skills into replayable business operations.
• To prototype a team-specific ops graph before wiring private provider tools.
• To route a product signal without giving the agent blanket repo, email, wallet, or deployment access.
• To explain why a governed workflow is more useful than a one-shot prompt: the route, stops, handoffs, and readbacks are explicit and replayable.
• To smoke-test graph execution and child receipts with no external account.

When not to use this skill

• To run a production launch, incident, release, campaign, support reply, payout, or spend flow as-is. Replace fixture lanes with real skills first.
• To approve a live send, spend, merge, publish, deploy, or customer-visible action.
• To hide project policy, customer lists, credentials, wallet keys, provider dumps, or private review context in the signal.
• To claim external work completed when only this fixture graph ran.

Mental model

signal -> classify -> fanout lanes -> approval stops -> governed handoffs -> proof

The useful part is the chain. A single objective becomes several typed packets: some read-only, some draft-only, some blocked until approval, and one proof lane that states how success should be verified later. A human, agent, dashboard, or CI loop can replay the same route and see the same stops.

How this maps to real runx work

• Docs and public proof route to a docs skill such as sourcey or a product-owned documentation lane.
• Release preparation routes to release, with publish held behind a release approval.
• Code work routes to issue-to-pr or a project-owned implementation lane, with merge held behind review.
• Outreach and customer communication route first to send-as, then to a provider adapter that implements the send lane. Branded provider skills are the right place for vendor-specific compose, test, review, schedule, or send details. Broad outbound marketing should be its own skill or product broadcast skill, not extra logic hidden in this graph.
• Spend and payments route to quote or payout skills with caps, recipient, rail, and settlement proof separated from the planning lane.
• Proof routes to receipt/history/audit skills and provider readbacks.

The fixture ops-lane step simply returns these packets without performing the handoff. In a real project, replace each fixture lane with the named governed skill runner or provider tool.

Procedure

1. Receive one concise signal.
2. Optionally receive operator_context with project constraints, policy, or the concrete business situation.
3. Run classify first. It decides which lanes are relevant and what authority class each lane belongs to.
4. Fan out docs, release, issue, outreach, spend, and proof packets.
5. Mark each lane as read-only, draft-only, approval-required, or proof-only.
6. Name the exact downstream handoff that should replace the fixture in a real workflow.
7. Seal the graph so the route itself is replayable.
8. If using route_and_append, append the classification packet with an idempotency key and expected version, then read back the projection.

Edge cases and stop conditions

• Missing signal: return needs_input. There is no safe route.
• Vague objective: return a narrow classify packet and ask for the missing product, audience, repo, release, amount, or provider context.
• Live send without principal, audience, consent, digest, and approval: stop at the outreach lane and route to send-as.
• Spend without amount, cap, recipient, rail, and approval: stop at the spend lane and route to a quote or payment skill.
• Merge, publish, deploy, or destructive mutation without approval: stop at the relevant lane and name the missing gate.
• Provider success without provider evidence: do not mark complete. Route to proof audit.
• Secret or private data in the signal: refuse to echo it into outputs; require redacted context or a provider-side readback instead.

Output schema

The graph output contains child step receipts plus one lane_packet per lane:

lane_packet:
  schema: runx.business_ops_lane.v1
  lane: string
  signal: string
  status: ready | awaiting_approval | needs_input | refused
  decision: route | prepare | draft | quote | verify | stop
  kind: router | docs | release | work | outreach | spend | proof
  consequence: read_only | draft | live_mutation | public_send | money_movement | proof
  summary: string
  why: string
  authority:
    requested: [string]
    provided: fixture_only
  gate:
    approval_required: boolean
    approval_gate: string | null
    stop_reason: string | null
  handoff:
    interface: skill | graph | cli | hosted_api | workflow | provider_tool
    lane_ref: string
    runner_ref: string | null
    command_hint: string | null
  evidence:
    inputs_required: [string]
    readbacks: [string]
    receipt_refs: [string]
  risks: [string]
  next: [string]

Worked example

runx skill business-ops \
  -i signal="launch readiness for API v2: docs, release, customer comms, and spend checks" \
  --json

The graph classifies the launch signal, prepares docs/release/work packets, routes customer communication to an outreach plan, stops spend at a quote gate, and names receipt/history checks that would prove later execution. No external provider is called.

Inputs

• signal (required): concise business operations signal to classify and route.
• operator_context (optional): product policy, project topology, audience constraints, or known provider state. Context only, not authority.