---
name: pto-time-off-coordinator
description: "Use when someone asks to take, log, change, or cancel time off (vacation, sick day, leave, OOO), including on behalf of a teammate, or when a scheduled time-off job runs. Handles intake, business-day counting, the manager go-ahead, and logging to the team's calendar, tracker, and announcement channel, using the workspace's saved time-off setup."
---

# Time-Off Coordinator

Run a team's time-off requests end to end: collect the request, get the manager's go-ahead when the leave type needs one, log it everywhere the team tracks time off, and handle changes and cancellations.

Everything specific to this team (who approves whom, holidays, where things get logged, who to escalate to) lives in the workspace's **time-off setup**. Read it before handling a request. If there is no setup yet, run the setup in `references/setup.md` with a workspace admin first, and don't log anything until it exists.

## When to use

- Someone asks to take time off, says they're sick or out, or asks you to log PTO.
- Someone logs time off **for another person**. The time off belongs to the named person, not the requester.
- A change of dates or a cancellation of existing time off.
- A scheduled time-off job runs (see Scheduled jobs).

## Eligibility

- Every human teammate is eligible, whatever their employment type.
- AI agents and bots are not. If a request is from or for one, decline in one friendly line and log nothing.
- Only full days are tracked unless the setup says otherwise. For a half day, tell them to let their manager know directly, and don't log it.

## Leave types

Ask which applies if the message doesn't make it clear, as a short numbered choice:

1. **Vacation**: planned time off. Needs the manager's go-ahead before anything is logged.
2. **Sick**: illness or medical appointments. Log it right away with no gate, then give the manager a heads-up.
3. **Other**: parental leave, bereavement, jury duty, conferences, and similar. Needs the manager's go-ahead.

The setup may change which types need a go-ahead. Follow it.

## Intake

Collect, asking only for what the message didn't already give:

1. **Who** the time off is for (default: the requester).
2. **Start and end dates.** If they're ambiguous, ask before doing anything else.
3. **Leave type.**
4. **Coverage**: who people should go to while they're out. Ask for Vacation and Other; skip it for Sick.

Before confirming, count the business days and check the tracker for an overlapping request. If one overlaps, tell them instead of creating a second record.

## Counting business days

Count weekdays in the range, minus the company holidays in the setup. The calendar entry still spans the whole range, weekends included; only the count excludes them. State the count and the dates it covers, so a wrong count is easy to spot.

## Manager go-ahead

1. Find the approver from the setup's routing: overrides first, then the person's manager. If the manager seat is empty, go to the next person up. If the person isn't in the routing at all, ask the requester who their manager is and tell the setup owner the routing needs updating.
2. Message the approver with the person, dates, type, business-day count, and coverage. Ask them to reply to approve or to say they'd like to talk first.
3. On approval, log everything (below) and confirm to the requester.
4. If they want to talk first, tell the requester, log nothing, and keep the request pending.
5. Before any nudge, re-read the approver's thread for a reply you missed, like "approved", "looks good", or a thumbs-up. If they clearly approved, treat it as approval.
6. No reply after a day: nudge in the same thread. No reply after two days: escalate to the setup's escalation contact.

For Sick leave, skip the gate: log it, then message the manager a heads-up with a nudge to check in on the person. For longer sick leave, follow the setup's escalation tiers if it has them.

## Logging

When a request is approved (or immediately, for Sick or for anyone the setup exempts from the gate), do everything the setup lists. Typically:

- **Team calendar**: an all-day event titled "[First name] OOO" across the whole range, shown as free, with no description. Remember that all-day end dates are exclusive, so add one day. Keep the event id.
- **Tracker** (a database or sheet): person, dates, business days, type, status, approver, requested-on date, notes. Keep the row id.
- **Announcement channel**: one short post, for example "Time off logged: [Name] is out [start] to [end] ([N] days, [type]). Coverage: [Name]." Post only in the setup's channel, and never announce someone's time off anywhere they didn't ask for. Before posting, check the tracker so a request is never announced twice.

Statuses are **pending**, **logged**, and **cancelled**.

## Changes and cancellations

1. Find the request in the tracker and confirm the change with the person.
2. Update the tracker: new dates and a recounted business-day total, or status cancelled. If the tracker can't delete rows, set the status instead.
3. Update or remove the calendar event using the saved id.
4. Post a short update in the announcement channel.
5. Confirm back to the person.

If an approver withdraws an approval, run the same cancellation steps and tell the requester.

## Rules

- One ping per person per message: don't tag someone in the body and again in a cc.
- A same-day request is fine. It still needs the go-ahead, but flag the urgency.
- If the approver is out themselves, still route to them; the nudge timing still applies.
- Never log, post, or change anything before the dates and type are clear.

## Scheduled jobs

Offer these when setup finishes, and create them only if the team wants them:

- **Day-before check-in**: the afternoon before someone's vacation starts, remind them and offer to post a heads-up in their team channel.
- **Go-ahead nudges**: twice each weekday, work through pending requests using the nudge and escalation rules above.
- **Quarterly summary**: days per person by type, year-to-date totals, and pending requests, posted to the announcement channel.

## Connections

This skill works best with a calendar connection that can write to the team calendar and a tracker connection (for example Notion or Google Sheets). If one is missing when a request comes in, say which one is needed and offer to log the rest. Never pretend something was logged.
