Ops Desk

Operate a project, workspace, or account from an agent-controlled desk.

This skill is the generic operations desk layer. It turns a state snapshot, an operator objective, and receipt-backed evidence into one safe ops desk packet: what is happening, what needs attention, what can be checked read-only, what requires approval, which governed lane should execute, and how success will be verified.

It is not the authority and it is not a second CLI. It does not replace domain skills from the registry (release, payments, board and thread products, and the like), provider-specific adapter skills, hosted API routes, repository workflows, or deploy commands. It routes to the existing interface with the smallest sufficient context and stops before any consequential act that lacks the right gate.

Composes

• data-store#read_projection

What this skill does

The default operate_from_projection runner reads bounded durable state before producing an ops desk packet for a manager dashboard, agent session, or self-operation run. The explicit operate runner accepts an already-supplied snapshot. Both classify findings, rank the next action, select the governed lane, name blockers, write the approval prompt when a human decision is required, and states the receipt/effect/readback that will prove success.

It is useful before an action and after an action:

• before action, it turns state into proposals and approval requests;
• after action, it checks whether the expected receipt and projection appeared.

The model may diagnose and write the operator rationale. The mutation itself must be a deterministic handoff to an existing skill runner, CLI command, hosted API route, workflow, or provider tool.

When the desk should start from durable state, use operate_from_projection. That runner reads a projection through data-store first, then passes the projection as the dashboard snapshot. The storage provider is still selected by the logical data_source_ref; ops desk does not know whether state came from SQLite, Postgres, D1, Redis, or a product API.

When a standing case must be advanced one move at a time toward a mandate, use advance. It takes the mandate, the current case_state, and a fixed candidate_roster, and returns a single typed dispatch_decision: dispatch one roster member, escalate, or done. It applies the same ranking and the same gates as operate, but it is hard-constrained to the roster and emits one move instead of a multi-proposal plan. The caller (an agency loop) holds the case and the goal; ops desk supplies the judgment. The chosen member is named as data; ops desk never runs it.

When to use this skill

• An operator asks an agent to manage a project, workspace, product, account, or other bounded operating surface.
• A dashboard needs an agent-readable plan from the current projected state.
• A runbook needs to decide between read-only checks, proposals, approval-gated actions, and post-action verification.
• A product-specific operator skill needs a generic cockpit spine instead of inventing its own action model.
• A standing case (an agency) needs the single next governed move chosen from a fixed roster, one turn at a time.
• Runx needs to dogfood its own release, registry, hosted, receipt, or provider operations through the same governed lanes it exposes to users.

When not to use this skill

• To execute a live mutation directly. Route to the named governed lane.
• To duplicate a CLI command, release script, GitHub workflow, hosted endpoint, registry client, or provider SDK.
• To bypass a human gate because the agent or UI believes the action is obvious.
• To replace a domain skill from the registry, such as send-as or release, a payments lane, or a connector.
• To operate from stale, missing, or unverifiable state while claiming readiness.
• To put secrets, private keys, raw customer lists, or provider dumps into the ops desk packet.

Operating Model

Use one loop:

snapshot -> findings -> proposals -> approval -> governed lane -> receipt -> projection

The manager dashboard and the agent must read the same state and emit the same action families. A button click and an agent plan are different interfaces over the same governed lane, not separate backdoors.

Delegation Model

Ops desk packets name existing execution surfaces; they do not implement them.

• release owns release preparation, approval, publish handoff, and post-release verification.
• ledger, audit-receipt, and run-history own proof questions.
• send-as owns authority for live communications; branded provider skills and their connectors own provider-specific execution details.
• spend, charge, refund, and branded payment skills own money movement.
• Project skills own product vocabulary and product-specific actions.
• CLI commands, hosted API routes, and GitHub workflows remain deterministic execution interfaces. The operator skill may cite them as handoff targets but must not clone their behavior in prose.

If no existing lane can perform the action cleanly, return needs_input or a product gap. Do not invent a private workaround.

Procedure

1. Scope the objective.
   • Identify the workspace, project, account, surface, time window, and whether the ask is read-only, proposal-only, or execution-prep.
   • Read project_profile or operator_policy as context, not authority.
   • If the operating scope or objective is ambiguous, return needs_input.
2. Classify state from evidence.
   • Use dashboard_snapshot, receipt_summary, effect_summary, and provider_status when present.
   • Treat missing evidence as missing. Do not infer success from UI state alone.
   • Separate health, money, communications, provider mutations, access, deployment, and incident signals.
   • For review, catalog, publication, bounty, or marketplace work, classify whether the artifact is real, useful, complete, and valuable. A reachable artifact with no credible user, maintainer, operator, public proof, or marketing value is not ready.
   • If using operate_from_projection, treat the read projection as the dashboard snapshot. An empty projection is not an error, but it should usually produce needs_input rather than fake readiness.
3. Route to governed lanes.
   • Release questions route to release plus the project release profile and existing release workflow/commands.
   • Audit questions route to ledger, audit-receipt, run-history, or least-privilege.
   • Live communication routes through send-as and then the provider's connector.
   • Payment collection, payout, refund, chargeback, or target changes route to the matching payment lane.
   • Board, thread, and provider actions route to the product's own governed skill from the registry or a connector operation, such as issue-intake or issue-to-pr.
   • Deploy and config changes route to the product-owned deploy lane.
4. Decide gates.
   • Read-only checks: no human approval.
   • Drafts, dry-runs, previews, and reports: no live-action approval unless they expose private data or broaden authority.
   • Live sends, payouts, refunds, customer-visible posts, provider mutations, target changes, credential changes, deploys, destructive actions, and broad audience decisions: explicit approval required.
   • A review verdict, recommendation, or green dry-run is not payment approval. Money movement needs a separate approval prompt naming the amount, recipient, rail, target class, and verification receipt expected after settlement.
   • Missing approval means awaiting_approval, not "ready".
5. Produce the ops desk packet.
   • Lead with the few issues an operator should act on now.
   • Name the exact lane for each proposed action.
   • Include the existing execution interface as a handoff, not as a duplicated implementation.
   • Include approval copy only when the operator could approve it safely.
   • Include verification steps that will prove the action happened.
6. Stop cleanly.
   • Return needs_input for missing scope, objective, identity, authority, evidence, approval, or target.
   • Return refused for requests to bypass gates, hide material facts, leak secrets, spoof receipts, mark unsettled money as settled, or send without a principal/audience/content digest.

Edge cases and stop conditions

• No project/workspace/account or objective: return needs_input; there is no safe operating frame.
• No projection or receipt evidence: return needs_input or unknown status; do not convert silence into ok.
• Requested action has unknown consequence: stop at needs_input with the missing lane/consequence classification.
• Money, public send, deploy, credential, target, destructive, or provider mutation without approval: return awaiting_approval.
• Approval text is too broad to approve safely: return needs_input with the exact missing amount, audience, target, network, provider, or effect.
• User asks to skip a gate, hide a blocker, forge a receipt, or mark state settled without proof: return refused.

Reference Loading

Load only the reference needed for the objective:

• Payments, payouts, refunds, payment rail adapters, reconciliation: references/payments.md
• Email, campaigns, notifications, customer/public communication: references/communications.md
• Receipt verification, ledger, trust roots, after-action proof: references/receipts.md
• Provider health, deploys, webhooks, credentials, outages: references/providers.md
• Manager dashboard state, projections, and action catalog design: references/dashboard.md
• Delegation, project profiles, CLI/workflow handoff, and dogfooding rules: references/delegation.md

Output schema

Return one ops_desk_packet:

ops_desk_packet:
  decision: ready | awaiting_approval | needs_input | no_action | refused
  scope_ref: string
  objective: string
  mode: read_only | proposal | execution_prep | post_action_review
  dashboard:
    health: ok | degraded | blocked | unknown
    money: ok | needs_attention | blocked | unknown
    communications: ok | needs_attention | blocked | unknown
    providers: ok | needs_attention | blocked | unknown
    receipts: ok | needs_attention | blocked | unknown
  findings:
    - severity: info | warning | critical
      area: health | money | communications | providers | receipts | access | deploy
      summary: string
      evidence_refs: [string]
  proposals:
    - action_id: string
      lane: string
      reason: string
      inputs_summary: object
      consequence: read_only | draft | live_mutation | money_movement | public_send | deploy
      approval_required: boolean
      approval_prompt: string | null
      blockers: [string]
      verification:
        expected_receipt: string
        expected_effect: string | null
        readback: string
      execution:
        interface: skill | cli | hosted_api | workflow | provider_tool | manual
        lane_ref: string
        profile_ref: string | null
        command_ref: string | null
        workflow_ref: string | null
        approval_gate: string | null
        verifier_ref: string | null
  ordered_next_steps:
    - step: string
      lane: string
      requires_confirmation: boolean
  refused_reasons: [string]
  needs_input: [string]
  success_checkpoint:
    milestone: string
    description: string

The advance runner returns one dispatch_decision:

dispatch_decision:
  decision: dispatch | escalate | done
  reason: string
  dispatch:                 # present when decision == dispatch
    member: string          # a role from candidate_roster
    skill: string           # that role's roster skill, echoed
    task: string            # what the member should do
    needed_scope: [string]  # subset of the member's scope ceiling
    consequence: read_only | draft | live_mutation | money_movement | public_send | deploy
    verification:
      expected_receipt: string
      readback: string
  escalation:               # present when decision == escalate
    to: string              # a roster role or "human"
    trigger: string
    ask: string
    approval_prompt: string | null
  resolution:               # present when decision == done
    reason: string

Decision rules

• Prefer one clear next action over a dashboard dump.
• Never bury a required approval in prose; put it in approval_prompt.
• Never expose tokens, API keys, raw customer lists, private wallet keys, or provider response dumps.
• Never claim a state is settled, sent, deployed, paid, or refunded without a receipt/effect/readback reference.
• Never route a public artifact, skill, bounty result, or docs deployment as ready when it lacks a credible real-world audience or durable public evidence.
• Never widen authority because a dashboard widget would be convenient.
• Never duplicate an existing CLI command, workflow, hosted endpoint, or domain skill in operator prose. Route to it.
• Keep product-specific policy in product context. Keep this skill generic.

Inputs

• objective (required): operator request, e.g. "check payments and unblock funding", "prepare a campaign send", or "review stuck receipts".
• scope_ref (required): the project, workspace, account, product, or bounded surface being operated.
• dashboard_snapshot (optional): JSON summary of current projected state.
• receipt_summary (optional): JSON or prose receipt/effect summary.
• provider_status (optional): JSON or prose provider health/account state.
• approval_context (optional): existing operator approvals, denials, or policy gates.
• operator_policy (optional): project-specific constraints and lane names.
• project_profile (optional): project topology, existing interfaces, and verification expectations. It is context, not authority.
• requested_action (optional): preselected action lane or dashboard action id.

Worked example

Input: "Check payment readiness and tell me what to do next" with a dashboard snapshot showing healthy quote/readback state, three funded items, no unfunded approved items, and one rail adapter webhook status needs_review.

Output: decision: ready, money status ok, providers status needs_attention, one warning finding for rail webhook readiness, and one proposal routing to provider.webhook_check with no money movement. It does not propose marking anything funded, because no unfunded approved item is present and the latest funding receipt is already verified.

Agent task contracts

ops-desk

Produce one runx.ops_desk.packet.v1 for the requested project, workspace, account, or product objective. Treat dashboard_snapshot, receipt_summary, provider_status, approval_context, operator_policy, and project_profile as evidence, not as authority. Classify health, money, communications, providers, receipts, access, release, registry, and deploy state; rank the smallest useful next action; route every proposal to a named governed lane resolved from the registry: release, ledger, payments, provider send and health checks, deploy checks, or the product's own skill. For each consequential proposal include an execution handoff naming the existing skill, CLI command, hosted API, workflow, provider tool, or manual gate that should execute it; never duplicate that implementation in operator prose. Read-only checks do not need approval. Live sends, payouts, refunds, public/provider mutations, target changes, credential changes, deploys, release publishes, destructive actions, and broad audience decisions must stop at awaiting_approval unless approval_context proves approval. Never expose secrets, raw customer lists, wallet private keys, tokens, or provider dumps. Never claim settled, sent, paid, refunded, deployed, released, or fixed without a receipt, effect, or provider readback expectation. Return needs_input for missing scope/objective/evidence/authority/approval or missing execution lane; return refused for gate bypass, forged proof, secret leakage, or hidden private workarounds.

ops-desk-advance

Decide the single next move for a standing case advanced toward a mandate. Inputs are the mandate, the current case_state, and a fixed candidate_roster of dispatchable members, each a role with its skill and scope ceiling. Choose exactly one of: dispatch one roster member, escalate, or done. Hard-constrain every choice to candidate_roster; never name a member, skill, or lane that is not in the roster, and never widen a member's scope beyond its ceiling. Rank by the smallest useful next action toward the mandate, the same way the operate runner ranks, and apply the same gates: if the best move is consequential (money movement, public send, provider mutation, deploy, destructive, target or credential change) and approval_context does not prove approval, return decision=escalate with an approval prompt instead of dispatching. If case_state shows the mandate is satisfied, return decision=done with the reason. If no roster member can act and nothing is escalatable, return decision=escalate to the configured human or member and name the missing input. Never invent a member outside the roster; never claim work settled, sent, paid, deployed, or done without naming the receipt or readback that will prove it.

ops-desk-action-review

Review one proposed ops desk action. Classify its consequence, approval requirement, blockers, and verification evidence. If the proposal moves money, sends publicly, mutates a provider, changes targets or credentials, deploys, publishes a release, deletes, or broadens authority, require explicit approval. Require an execution handoff that names an existing skill, CLI command, hosted API, workflow, provider tool, or manual gate; do not accept bespoke operator-prose implementations. Return ready only when the action packet is sufficiently bounded and required approval/evidence is present. Return awaiting_approval when the action is well-bounded but approval is missing. Return needs_input for missing target, amount, audience, principal, receipt/effect, lane, or execution handoff. Return refused for gate bypass, forged state, secret leakage, or hidden private workarounds.