Support Setup

The four tables below are the record store. Create them once, rewrite /support/INTAKE.md with the ids they get, then activate Triage Officer. The support-setup skill executes this document.

Tables

Tickets

The queue. One row per ticket, created by intake — never by an agent.

• external_ref — single line text (the id in the helpdesk this came from)
• source — single line text (zendesk, intercom, email, form, manual)
• subject — single line text
• body — multiline text
• requester_email — email
• requester_org — single line text
• type — single select: bug, how_to, config, billing, feature_request, outage, unknown
• product_area — single line text
• severity — single select: sev1, sev2, sev3, sev4, unknown
• status — single select: new, triaged, investigating, awaiting_customer, escalated, resolved, closed
• known_issue — single line text (the key of a Known Issues row)
• assigned_to — single line text
• received_at — date time
• first_response_at — date time
• resolved_at — date time
• resolution — multiline text
• escalation_ref — single line text
• triage_notes — multiline text

Known Issues

The ledger. This is the table the workspace exists to fill.

• key — single line text (short, stable, human-quotable: EXPORT-TIMEOUT)
• title — single line text
• symptoms — multiline text (what the customer sees, in their words)
• product_area — single line text
• root_cause — multiline text
• workaround — multiline text
• customer_message — multiline text (the approved wording to send)
• status — single select: investigating, confirmed, fix_in_progress, fixed, wontfix
• fix_version — single line text
• ticket_count — number
• first_seen — date
• last_seen — date
• engineering_ref — single line text

Ticket Events

Append-only history. Every meaningful action against a ticket.

• ticket_ref — single line text
• type — single select: triage, note, reply_drafted, reply_sent, status_change, escalated
• body — multiline text
• author — single line text (who or what wrote this; see CONVENTIONS)
• occurred_at — date time

Escalations

Append-only log of everything handed to engineering.

• ticket_ref — single line text
• known_issue_ref — single line text
• summary — single line text
• repro_steps — multiline text
• severity — single select: sev1, sev2, sev3, sev4
• target — single line text (github, linear, jira, webhook)
• external_ref — single line text (the issue id, set on success)
• payload_hash — single line text
• status — single select: pending, sent, failed
• sent_at — date time
• response_summary — multiline text

Checklist

1. Confirm the schema with the user before creating anything. Say what each table is for in one line; do not paste the whole spec back at them.
2. Ask what the product is, what its product areas are, and who handles escalations. Three questions, not a field-by-field interview.
3. Create the four tables with create_data_table.
4. Rewrite /support/INTAKE.md with the real table id and column ids, and a request that actually works. This step is not optional — without it nobody can wire up a helpdesk, and the template does nothing.
5. Write the product context into /SUBTERRANEAN.md from what you learned.
6. Tell the user the activation step, verbatim: open a session with Triage Officer and say "activate".

Step 6 is a separate session on purpose. Triggers reference table ids that do not exist until step 3 finishes, and an agent may only configure its own automation unless it holds the team permission set — which this template deliberately does not grant to anyone.