# Maintenance Request Triage

Classify incoming tenant maintenance requests by urgency, open the appropriate work order, and immediately escalate anything that looks like an emergency to a human property manager.

## When to use

- A tenant submits a maintenance request through a portal, email, or SaaS (software as a service) ticketing system
- A request needs urgency classification (emergency, urgent, routine) before a work order is created
- A request describes conditions that could be an emergency (gas leak, flooding, no heat in freezing weather, fire hazard, lockout, security breach)
- A property manager wants a status update or summary of open maintenance work orders

## Tools

- `http-get`
- `http-post`
- `send-message`
- `create-task`
- `delegate-task`

## Playbook

1. Retrieve the new or updated maintenance request record with `http-get`, e.g. GET https://api.propertysoftware.example.com/v1/maintenance-requests/{id}. Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials.
2. Read the request description, unit, and any attached notes to classify urgency into one of three tiers: emergency (immediate danger to health, safety, or property — gas smell, active water leak, no heat/AC in extreme temperatures, fire/smoke, break-in, elevator entrapment), urgent (significant inconvenience but not dangerous — broken appliance, clogged toilet with no backup, pest sighting), or routine (cosmetic or non-critical — squeaky door, paint touch-up, minor leak drip).
3. If the request is an emergency, immediately notify a human via `send-message` with the unit, tenant contact, and description, flagged as EMERGENCY, and do not wait for further workflow steps before this notification goes out.
4. For urgent and routine requests, create a work order by calling `http-post` against the property management platform, e.g. POST https://api.propertysoftware.example.com/v1/work-orders with unit, category, priority tier, and description.
5. If the work order requires a formal notice to the tenant (for example a late-rent or lease-violation notice tied to the maintenance issue), draft the notice text but never send it autonomously — route it via `delegate-task` to a human manager for review and approval.
6. Assign the work order to the correct vendor or maintenance technician queue using `http-post` or, if the platform only exposes a partial-update endpoint, use `http-request` (not covered by this skill's declared tools — escalate via `create-task` if assignment fails).
7. Log a `create-task` entry on the board summarizing the request, urgency tier, and work order ID so the team has a shared trail of open items.
8. If the SaaS integration returns 401/403 or no Integration row exists for the host, stop and use `send-message` to alert a human, naming the service and the scopes required.
9. Confirm receipt to the tenant with `send-message` (or the platform's own notification channel via `http-post`), stating the urgency tier and expected response window.

## Failure modes

- Misclassifying an emergency as routine delays a dangerous situation — when any doubt exists about danger to people or property, default to the emergency tier and escalate immediately.
- Sending a formal legal notice (late rent, eviction warning) without manager approval — always draft and hand off via `delegate-task`, never post or send such notices autonomously.
- Creating duplicate work orders for the same request — check existing open work orders with `http-get` before creating a new one.
- Silently failing when the property management API is unreachable — always surface API errors to a human via `send-message` rather than dropping the request.

## Done when

- The request has an urgency classification, a work order is open (or an emergency escalation has been sent to a human), and the tenant has received acknowledgment.
- Any legal or formal notice tied to the request is sitting in manager review, not sent.
- The board task reflects the current status and links to the work order ID for follow-up.