--- name: remote-com-time-off-planning description: Plan an upcoming absence by combining leave balances, the time-off policy summary, existing requests and the work and holiday calendar, then prepare a time-off request draft for approval. Use when the user asks whether they can take time off, how much leave they have left, when to schedule a holiday, or wants a time-off request drafted for an upcoming absence. --- # Plan a time-off absence The goal is a **request that will be approved and will not collide with anything**. A balance that looks big enough can still fail once you count public holidays, pending requests, paid-day rules and the policy's notice period. Build the picture first, then draft. This skill is about planning one absence. It is not about payroll, payslips or expenses; if the user asks about money, hand that to the payroll or expense work. ## 1. Confirm whose leave this is Before any lookup, confirm which signed-in account and role you are acting as. Leave data for an employee and for a manager reviewing a team are different views, and a manager's account may see teammates while an employee's sees only themselves. State the person whose balance you are reporting. If the user asks about someone else and the role cannot see them, say so instead of guessing. ## 2. Pull the balance and the rules together Start from the number the employee actually has, then check the rules that shrink it: - `get_employee_time_balance` for current balances by leave type. - `get_timeoff_leave_policies_summary` for the policy: notice periods, whether leave is accrued or granted up front, carry-over, and which leave types are paid. - `list_paid_timeoff_days` to see how many paid days have been used or are committed. Read the balance per leave type. A total across types hides the fact that sick leave cannot cover a holiday. Work out the **requested days against the matching type**, and note whether the policy requires a minimum notice period that the planned dates may breach. ## 3. Check for collisions A balance is only useful if the dates are free: - `list_employee_timeoffs` for existing requests, approved and pending. A pending request still reserves days in the user's mind even if it does not yet reduce the balance. - `list_employee_holidays` for public holidays in the window. A ten-working-day block that contains two public holidays uses eight leave days, not ten. Check whether the policy excludes public holidays from leave counts before you subtract them. - `get_work_calendar` for the team's and company's working days and any closures. Overlapping absences of colleagues are a planning risk, not a rule breach, so report them as context. Use `get_employee_timeoff` when a specific existing request needs its details (status, dates, type) before you decide how it affects the plan. ## 4. Test two or three date windows Do not stop at the first window the user mentions. Propose two or three options with different trade-offs: one that uses the least leave, one that avoids the busiest team period, and one that fits the notice period best. For each, show days used, days remaining after, and any collision found. This is where the planning value is. ## 5. Common patterns and traps - **Balance shown as zero but leave is accrued monthly.** Accrued leave grows with time; a current balance may understate what is available by the planned start date. Say what the balance will be on that date if the policy gives enough detail to compute it, and mark it as an estimate otherwise. - **Holidays counted as leave.** Many policies do not charge public holidays against leave. Check the policy summary before you subtract them and state which rule you applied. - **Pending request treated as approved.** A pending request may be declined. Plan around it, but say it is pending and offer to plan without it too. - **Notice period missed.** If the start date is inside the policy's minimum notice, flag it and suggest the earliest compliant date rather than presenting the window as ready to submit. - **Mixed leave types in one window.** A trip that is part holiday and part sick day cannot be submitted as one request. Split the draft by type. - **Half days and partial periods.** If the policy or the request form does not support half days, do not plan on them; say so. - **Team clash.** Two people from the same team away at once is a coverage question, not a rule breach. Mention it to the user as a consideration for their manager. ## 6. Prepare the request draft, then wait When the user picks a window, prepare the request as a **draft only**: leave type, start date, end date, days charged, any note, and the collision and balance result. Do not submit it. The submitting step is a write action, and it routes to the manager for approval. Wait for the user's explicit yes before creating the request, and confirm the exact dates and leave type they are saying yes to. If the user changes their mind about the window, redo steps 2 to 4 rather than editing the old draft in your head. ## Output ``` Person: Balance now: (source: time balance) Policy: Options: A. | uses days of | remaining | notice | clashes: B. ... C. ... Recommended: