Idea: /sm — Support Manager skill built on fleet

[kumaakh]

What this is

A reference pattern showing how to build a product support application on top of fleet. This is not a feature being added to fleet — it is a worked example of the orchestration pattern, designed to be forked and adapted to a real support workflow.

Fleet's primitives (execute_prompt, execute_command, doer/reviewer, parallel dispatch) are domain-agnostic. The /sm skill makes that concrete for the support domain the same way /pm makes it concrete for software development.

The pattern

Assign fleet members specialized support roles instead of dev roles:

Role	Responsibility
Triage	Reads incoming ticket, categorizes it (bug / how-to / billing / escalation), extracts key signals, scores urgency
Log Investigator	SSHes into production servers via execute_command, pulls relevant logs, correlates errors with the ticket
Response Drafter	Writes the customer-facing reply based on triage + investigation findings
Escalation Manager	Decides whether a human needs to be looped in and routes accordingly

SM orchestrates these roles the same way PM orchestrates dev roles.

Reference workflows

Bulk ticket triage

50 open tickets. SM distributes them across 5 triage members in parallel. Each member categorizes, scores urgency, and extracts a one-line summary. SM aggregates into a prioritized queue. Total time: roughly the time to read 10 tickets, not 50.

On-call investigation pipeline

Alert fires. SM dispatches Log Investigator to production (execute_command → ssh → pull logs → grep for error patterns). Investigator returns structured findings. SM dispatches Response Drafter to write the incident summary. SM dispatches Escalation Manager to decide if an engineer needs to be paged.

First-response pipeline

Every inbound ticket triggers: Triage reads it → Log Investigator checks for a matching known error → Response Drafter writes a draft reply citing findings → SM reviews and either sends or flags for human review. Target: AI-drafted first response within 60 seconds of arrival.

Knowledge base mining

SM scatters 200 resolved tickets across 10 members. Each extracts a FAQ entry from its batch. SM aggregates and deduplicates into structured knowledge base articles.

What you need to adapt when you fork this

• Ticketing system integration — connect Triage to your queue (Zendesk, Linear, GitHub Issues, email). The fleet execute_command tool can call any CLI or API.
• Log access — register a Log Investigator member per environment (staging, prod) with SSH credentials provisioned via provision_vcs_auth or credential_store_set.
• Confidentiality boundaries — decide what goes into prompts (ticket text, log excerpts) vs what stays local (PII, credentials). Fleet's {{secure.NAME}} token pattern handles credentials; sensitive data should be summarized before being included in prompts.
• Escalation rules — the Escalation Manager role is a prompt; tune it to your severity thresholds and routing logic.
• Response approval flow — decide whether SM sends automatically or queues for human review based on confidence score.

Why fleet is the right substrate

A support workflow is fundamentally: receive → investigate → respond → escalate. Fleet's parallel dispatch handles the receive-at-scale problem; its execute_command SSH access handles the investigate-on-live-infrastructure problem; its doer/reviewer pattern handles the draft-then-approve problem. No new infrastructure needed — just a skill that wires these primitives together for the support domain.