Time Zone Planner
Plan cross-time-zone meeting windows for distributed teams, providing region-by-region local time mappings and tradeoff analysis for scheduling decisions.
SKILL.md
Time Zone Planner
Structured cross-time-zone meeting planning for distributed teams.
Quick Check
python -m py_compile scripts/main.py
python scripts/main.py
When to Use
- Use this skill when planning meeting windows across multiple regions or time zones.
- Use this skill when comparing candidate windows and tradeoffs for distributed team scheduling.
- Do not use this skill for calendar booking, live availability checking, or travel/legal decisions.
Workflow
- Confirm the participant regions, meeting duration, preferred local-hour ranges, and any hard constraints.
- Check whether the request is for a quick overlap recommendation or a full tradeoff analysis.
- Use the packaged script for baseline scheduling output; for complex requests, provide a manual comparison table with stated assumptions.
- Return suggested meeting windows, region-by-region local times, and the tradeoffs behind the recommendation.
- If timezone details or availability constraints are missing, stop and request the minimum missing fields.
Usage
python scripts/main.py
# Input: {"regions": ["US", "EU", "Asia"], "duration": 60}
Parameters
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
regions | list[string] | Yes | — | Region set, e.g. ["US/Eastern", "Europe/London", "Asia/Shanghai"] |
duration | integer | Yes | — | Meeting duration in minutes |
preferred_hours | object | No | — | Per-region preferred local hour ranges, e.g. {"US/Eastern": [9, 17]} |
Region format: Use IANA timezone names (e.g., US/Eastern, Europe/London, Asia/Shanghai) for precise mapping. Short aliases like "US" or "EU" are accepted but will be mapped to a representative timezone with a note.
Region Alias Mapping
| Alias | Mapped To | Note |
|---|---|---|
US | US/Eastern | Representative only; specify sub-region for accuracy |
EU | Europe/London | Representative only; specify country for accuracy |
Asia | Asia/Shanghai | Representative only; specify city for accuracy |
Output
- Suggested meeting windows by region
- Local-time mapping for each included region
- DST assumption notes when applicable
- Tradeoff summary for each candidate window
Scope Boundaries
- This skill supports scheduling recommendations, not calendar booking.
- This skill does not validate current DST status from live internet sources.
- This skill does not decide business priority between teams without user-supplied rules.
- Manual confirmation is required before sending invites.
Stress-Case Rules
For multi-constraint requests, always include these explicit blocks:
- Assumptions
- Hard Constraints
- Recommended Window
- Tradeoffs
- Risks and Manual Checks
Error Handling
- If required inputs are missing, state exactly which fields are missing and request only the minimum additional information.
- If the task goes outside the documented scope, stop instead of guessing or silently widening the assignment.
- If
scripts/main.pyfails, report the failure point, summarize what still can be completed safely, and provide a manual fallback. - Do not fabricate live calendar availability or confirmed participant agreement.
Input Validation
This skill accepts: a list of participant regions and a meeting duration for cross-timezone scheduling recommendations.
If the request does not involve cross-timezone meeting planning — for example, asking to book calendar events, check live availability, make travel arrangements, or provide legal scheduling advice — do not proceed with the workflow. Instead respond:
"time-zone-planner is designed to recommend meeting windows across time zones for distributed teams. Your request appears to be outside this scope. Please provide a region list and meeting duration, or use a more appropriate tool."
References
- references/guidelines.md — General time-zone planning notes
- references/audit-reference.md — Supported scope, audit commands, and fallback boundaries
Response Template
Use the following fixed structure for non-trivial requests:
- Objective
- Inputs Received
- Assumptions
- Workflow
- Deliverable
- Risks and Limits
- Next Checks
If the request is simple, you may compress the structure, but still keep assumptions and limits explicit when they affect correctness.