Absence Coordination

Version 1.0.0 (2026-08-12)

An absence is a handoff, not an announcement

Most "out of office" tooling answers one question: is this person away? That is the least useful question anyone has.

The questions people actually have are: who decides in their place, what can wait, and can I reach them if it truly cannot. An absence notice that omits those does not remove a blocker — it relocates it, from your calendar into someone else's inbox, where it sits until you get back and discover a week of stalled decisions.

This skill treats an absence as a handoff with a scheduled reversal. Every protocol below follows from that.

It also treats an absence as a relationship event. Who hears first, who hears what, and who never hears at all are not implementation details. They are the whole thing.

Configuration contract

All specifics — names, addresses, tiers, channels, lead times, group IDs — live in a private config the skill reads at load time:

~/.synthesis/absence-coordination/config.yaml

The skill is generic and publishable; the config is neither. Full schema: [references/config-schema.md](references/config-schema.md). Starting point: [example-config.yaml](example-config.yaml). Per-tier draft skeletons: [references/message-templates.md](references/message-templates.md). Fifteen-minute adoption path: [references/quickstart.md](references/quickstart.md). Validate with:

python3 validate_config.py ~/.synthesis/absence-coordination/config.yaml

If the config is missing, STOP and say so. Announcing an absence without knowing the tier order is not a partial success; it is the specific failure this skill exists to prevent. Never hardcode a name, address, or channel that belongs in config.

Shared config. Where synthesis-chief-of-staff is installed, this skill reads its preferences file for calendar accounts, assistant relationships, and travel-disclosure rules rather than duplicating them. One fact, one home. If both files define the same fact, the chief-of-staff config wins and this skill's copy is a bug.

The five failures this skill prevents

Everything below is machinery for these. When adapting the skill, keep the failures in view; the machinery is negotiable, the failures are not.

1. The relocated blocker — an absence announced with no delegate.
2. The secondhand notice — someone's manager learns of their absence from a group

channel, or from their own assistant, instead of from them.

1. The silent conflict — dates announced that collide with a commitment on a calendar

nobody checked.

1. The abandoned commitment — recurring meetings left un-declined, a trainer left

guessing, an auto-responder still firing a week after return.

1. The default to disclosure — a system that can only broadcast, so it goes unused

exactly when discretion matters most.

Notification order — the part that protects relationships

Order is the single highest-risk element of an absence, and the risk is invisible until you get it wrong. Two failure modes pull in opposite directions:

• Tell the assistants first and your manager may hear about your absence from their

own assistant. A small indignity, and entirely avoidable.

• Tell the principals first and only, then their assistants days later, and you have

starved the people whose job is protecting those calendars of the lead time that makes them useful.

The resolution is not a timing rule. It is one message.

Write to the principals; cc their assistants.

One email. The principals hear it from you directly. The assistants receive identical lead time in the same instant. There is no ordering to enforce because there is no gap. A whole class of sequencing bug is deleted rather than guarded against.

Configure this as cc: tier:exec_assistants on the principals tier. Because cc'd assistants read the same text, the draft must work for both audiences at once: personal enough to be from you, complete enough that an assistant can act without a follow-up.

The hard gates

Enforced, not advisory. A gate that fails blocks the step — it does not warn and continue.

Required content: coverage and reachability

Every notice to a work tier carries both. A notice missing either is incomplete and the skill should refuse to send it.

Coverage

Per audience, in plain terms:

• Who decides what. Name a person per decision class, not one catch-all deputy.

"Ana for anything on the knowledge base, Jason for CSA delivery, everything else waits" beats "Ana is covering."

• What simply waits. Explicitly. Permission to defer is the most useful thing you can

give someone, and the thing they will not assume.

• What must not wait, and what to do with it.

Coverage is sourced, not invented. Set coverage.source: external and the skill requires a coverage statement supplied by whoever owns the org context — for many people that is a work-operations project or the manager themselves. This skill will not improvise who covers your decisions. Getting that wrong is worse than saying nothing.

Reachability

"Out of office" spans everything from "I read email once each morning" to "genuinely unreachable, satellite phone only." Colleagues cannot calibrate without being told, so they either over-escalate or sit on something urgent for a week. State:

• Channel — which one actually reaches you, and which are dead.
• Frequency — once a day, twice a week, not at all.
• The escalation path — what rises to "contact me anyway," and through whom.

Recipient tiers

Tiers are defined in config; the skill supplies the ordering, the gates, and the content rules. A tier is not just a mailing list — it is an audience with a content policy.

Disclosure is per tier, and it is mechanical

Business travel commonly warrants dates and city; purpose only where broadly shareable. Personal absence commonly warrants dates only. Encode this as content: on the tier so it is enforced rather than re-decided under time pressure — the moment it becomes a judgment call made while rushing, it will eventually be made wrong. When in doubt, the narrower content wins.

Never use a distribution alias for a tier

Use explicit recipients in config. An alias seems tidier and is worse in four ways:

• Opaque. You cannot audit who was actually told.
• Silently breakable. Aliases die in provider migrations without a bounce; the first

symptom is a family member who did not know you left the country.

• Single-content. One alias cannot serve two content policies, and family and

co-parenting audiences need different facts.

• Redundant. The alias existed so a human had one address to remember. An agent

reading a config does not need the shortcut.

The personal-continuity tier

The tier most absence systems do not have, and the reason this one is worth installing.

Work coordination is the well-trodden half of an absence. The neglected half is that travel disrupts standing personal commitments — a daily trainer, a weekly therapist, a tutor, a music teacher, a caregiver, a standing call with a parent. These people need more than "away." They need what they cannot look up.

Its content is unlike any other tier's:

• Time zone, not city. The operative fact for agreeing a daily slot is the offset. A

trainer does not need to know you are in Dubai; they need to know you are UTC+4 and that 07:00 your time is 23:00 theirs.

• Lodging and local facilities. Hotel name and address, so a trainer can plan around

the gym.

• Facilities research, done for them. With research.lodging_facilities: true, the

agent looks up the hotel's fitness facilities — equipment, hours, pool, photos — and includes that in the note. Do not offload a lookup you can perform.

• A per-day proposal, not a notice. For daily commitments, propose a workable slot for

each day of the trip against the destination time zone and the counterpart's own hours.

Sourcing rule. Facilities research must be attributed and dated — hotel gyms are renovated, close, and change hours. Say where the information came from and when it was retrieved. Never present a facility as confirmed on the strength of a marketing page; "listed on the hotel's site as of 12 Aug" is honest, "has a Peloton" is not.

Absence types

Config defines them; four cover most needs.

Two triggers, not one

Lead time is a deadline, not a schedule. A trip booked four months out should not sit unannounced for three of them.

• notifyoncommit — fires the moment the commitment is real, to a small cohort

that benefits from maximum warning: typically the assistants who protect the calendars, and family. This is the trigger that prevents conflicts, because it lands before the conflicting things get scheduled.

• leadtimedays — the full announcement, on schedule.

Booking a conference in March for October means the assistants and your family hear in March. Everyone else hears in September.

The quiet type

Medical appointments, family emergencies, interviews, bereavement, anything personal. visibility: minimal holds the calendar and notifies the smallest necessary set while suppressing group posts and wide announcements.

This is not a nice-to-have. A system that can only broadcast will be abandoned exactly when discretion matters most — and a tool you cannot use on your worst week is a tool you do not trust. Ship the quiet path or people will route around the whole system.

For quiet absences, coverage still applies. Discretion about why is not discretion about who decides in your absence.

Workflow

1. Pre-flight — before anyone is told

• Sweep every calendar. All accounts, and explicitly any calendar outside your

mirroring layer. If some tool blocks time across your calendars, know its coverage gaps: a calendar on a different provider commonly sits outside the mirror, blocks nothing elsewhere, and is invisible precisely when you are checking for conflicts.

• Enumerate recurring instances inside the window — standups, 1:1s, councils — and

produce a decline-or-delegate decision for each. They do not cancel themselves, and leaving yourself listed as an attendee means colleagues hold slots for someone who will not appear.

• Resolve coverage and reachability. Gate: no sends until both exist.
• Resolve the destination time zone if travelling. Needed by the continuity tier and

by anyone proposing meetings across the window.

2. Calendar

Personal event; work out-of-office; family-visible calendar; any shared team or leadership calendars in config. Work-calendar titles should be discreet by default — colleagues can see them, and the detail belongs on the personal side. OOO — personal is sufficient; a child's travel itinerary on a corporate calendar is not.

3. Notify

Tier order, gates enforced. Principals drafted for the human to send, assistants cc'd. Group channels last.

4. Logistics (travel types)

• Itinerary forwarding. Forward booking confirmations to your travel-management

service. Send from the address verified on that account — most services silently discard mail from unverified senders. There is no bounce, no trip, and no symptom until the trip is missing. Confirmations arrive wherever the booking was made, so a forward straight from a work account will vanish. Route through the verified address, then verify the trip was actually created.

• Family and co-parenting notes, per their content policies.
• Personal-continuity note, with time zone, lodging, and researched facilities.

5. Out of office

Set the auto-responder with the same coverage and reachability content. Schedule the clear. A responder still firing after return is a small recurring embarrassment that signals nobody owns the system.

6. Return

Hand off to synthesis-catchup-ledger for the window sweep: what moved, what was decided, what is now owed. An absence workflow that ends at departure is half a workflow. Clear the auto-responder, restore declined recurring meetings, and close the ledger rows.

The ledger

Every notification writes a row: tier, recipient, channel, content policy applied, drafted / sent / acknowledged, timestamp, and a stable absence_id.

The ledger is what makes the system idempotent and auditable. Re-running an amended trip updates rows rather than reposting. "I told them" becomes checkable rather than remembered. Where a drafts/_LEDGER.md convention already exists in the user's workspace, write there rather than inventing a parallel mechanism.

Rolling it out — pilot on the tiers that forgive mistakes

The tiers differ not only in content but in cost of error, and the rollout order should follow that gradient, not the org chart:

1. First cycle: personal_continuity and family only. A misworded note to your

trainer costs a shrug. These tiers also exercise the hardest machinery — time zones, facilities research, per-day proposals — so they are the better test, not just the safer one.

1. Second cycle: work tiers as drafts. Let the agent produce the principals and

direct-report drafts for a real absence, and send them yourself. You are editing the system's voice while the stakes are a paste-and-tweak.

1. Only then: promote tiers to agentsendafter_approval — and the principals tier

never promotes at all.

This ordering is doctrine, not caution for its own sake: trust in an EA — human or agent — is built at the periphery and spent at the center. Earn it in that order.

Adapting this skill

The tier names, gates, and types here reflect one shape of working life. The failure modes in "The five failures" are the durable part. If your organization is flatter, collapse principals and direct_reports. If you have no assistants, drop the cc rule — the underlying principle (the people most affected hear it first, and directly) survives the loss of the specific tier.

What should not be adapted away: coverage as required content, the group-post gate, the quiet type, and the return step. Those are the four that people are most tempted to skip and most regret skipping.