TimeTackle

View saved version →

---
name: client-hours-report
description: Build a client hours report from TimeTackle - total hours per client, and per person for each client, for a billing period, as a ready-to-share table. Use when the user asks for client hours, a billing summary, or hours spent per client or account.
---

# Client hours report

Produce a clean, shareable table of hours per client for a period. Explicit instructions from the user (period,
clients, people, rounding, format) take priority over these steps.

## Input

- The billing period. If none is given, ask for it, offering last month as the default. Use exact `YYYY-MM-DD` dates.
- Optionally specific clients, specific people, or a per-person breakdown.

## Steps

1. Call `get_account` and read `syncRange`. If the period reaches outside it, say that data only exists from
   `syncRange.start` to `syncRange.end`.
2. Find the client property: call `get_properties` with `search: "Client"`.
   - If there is no match, try "Account" and "Customer", then ask the user which property holds clients; do not guess.
   - Note its `key` and `state`. If the user asked about specific clients, check that those names appear among the
     property's options (`children`); if a property has more options than returned, page with `parentId` and
     `optionsOffset`.
3. Call `get_meeting_analytics` with:
   - `measures: ["hours"]`
   - `groupBy: "primary_tag"` or `"secondary_tag"` (from the property's `state`), and `tagKey` set to its key
   - `splitBy: "user"` when the user wants hours per person per client
   - `dateFrom`, `dateTo`, and `timezone` (the user's, otherwise the `timezone` of their own calendar from
     `get_imported_calendars`; say which one you used)
4. Page with `offset` while `summary.nextOffset` is not null, and combine the rows.
5. Keep only the clients (and people) the user asked for, if they named any.

## Output

- A table with one row per client, sorted by hours: client, hours (one decimal unless the user asks for another
  rounding), share of the total. With a per-person breakdown, list each client's people under it with their hours,
  or use a client × person table if it stays readable.
- A total row, the exact period, and the timezone.
- A note that time not tagged with a client is not included.
- If the result has a `syncRangeWarning`, include it.

## Do not

- Do not calculate amounts, rates or invoices unless the user gives the rates; then show the calculation.
- Do not invent clients or hours. If a requested client has no hours, show it with 0 and say so.
- People are limited to those the user can access in TimeTackle.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: get-started
description: Set up TimeTackle after installing it - confirm the connected workspace, what data is available, and suggest first questions to ask.
---

# Get started with TimeTackle

Help the user confirm their TimeTackle connection and learn what they can ask. Keep it short and use their real data.

## Steps

1. Call `get_account`. Tell the user which workspace they are connected to and their role. Read `syncRange` and tell them the dates their workspace has calendar data for (for example "May 1 to Nov 30"). Questions about dates outside that range cannot be answered, because that data was never synced.
2. Call `get_imported_calendars`. Say how many calendars they can access and name a few. If the list is empty, explain that no calendars are imported (or shared with them) yet, and that calendars are added in the TimeTackle web app.
3. Call `get_properties` with a small `limit`. Mention a few of their tags and properties (such as Project or Client) so they know what time can be broken down by.
4. Suggest three questions tailored to what you found, for example:
   - "How many hours did I spend in meetings last week?"
   - "Break down this month's time by <one of their properties>."
   - "Log 1 hour today for <a task>, tagged <one of their tags>."

## Notes

- Results only cover calendars the user can access in TimeTackle; do not suggest that they can see other people's calendars unless the calendar list shows them.
- Manual time entries are always created for the connected user.
- Do not create, change or delete anything during setup.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: log-time
description: Log time in TimeTackle from a plain description - turn "I spent 2 hours on the Acme proposal this morning" into one or more manual time entries with the right tags, confirmed before saving, and fix or remove entries just created. Use when the user wants to log, record, add, correct or delete their time.
---

# Log time

Create manual time entries for the connected user from what they describe. Entries always belong to the connected
user. Explicit instructions from the user take priority over these steps.

## Input

- What they worked on, when (date and start time), and for how long (or an end time).
- Optionally tags or property values (for example Project: Acme, or Development).

## Steps

1. Work out each entry: title, `startDateTime` in `YYYY-MM-DD HH:mm:ss`, and either `durationMinutes` or
   `endDateTime`.
   - Resolve relative dates ("this morning", "yesterday at 3") against today in the user's timezone (theirs if stated,
     otherwise their own calendar's `timezone` from `get_imported_calendars`).
   - If the start time or the duration is missing, ask. Do not guess times.
2. Resolve tags: call `get_properties` with `search` for each tag or property the user mentioned.
   - Use `"key"` for a tag on its own, or `"key:value"` for a property value (for example `"Project:Acme"`).
   - If a name matches nothing, or several things, ask the user; do not invent tags.
3. Confirm before saving: list every entry (title, date, start–end, duration, tags) and ask the user to confirm.
   For a single, fully specified entry, a short confirmation is enough.
4. After confirmation, call `create_manual_entry` once per entry with `title`, `startDateTime`, `durationMinutes` or
   `endDateTime`, and `tagNames`.
5. Report each created entry with its time and tags, and keep its `eventId` for corrections.

## Corrections

- To change an entry, call `update_manual_entry` with its `eventId` and only the fields that change. `tagNames`
  replaces all of the entry's tags, so pass the full list. Start and end times must be given together.
- To remove an entry, confirm with the user first, then call `delete_manual_entry` with its `eventId`.
- Only manual entries can be changed or deleted, not calendar meetings from Google or Outlook.

## Do not

- Do not create entries for someone else; to log time for another person, they connect their own TimeTackle account.
- Do not create, change or delete anything without the user's confirmation.
- Do not split, round or merge the user's times unless they ask.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: meeting-load-review
description: Review meeting load in TimeTackle - meeting hours and counts over time, the mix of meeting lengths and sizes, recurring versus one-off meetings, and who organizes the most, with practical suggestions grounded in the numbers. Use when the user asks about meeting overload, how much time goes to meetings, or how to reduce meetings.
---

# Meeting load review

Give a short, data-backed picture of meeting load for a period, for the user or the calendars they choose. Explicit
instructions from the user take priority over these steps.

## Input

- A period. If none is given, use the last 4 full weeks and say so. Use exact `YYYY-MM-DD` dates.
- Whose meetings: the user's own calendars by default, specific calendars, or everything the user can access.

## Steps

1. Call `get_account` and read `syncRange`; if the period reaches outside it, say so.
2. Choose calendars: for "my meetings", call `get_imported_calendars` and use those whose `user.email` is the user's
   email; pass them as `calendarIds`. For a team or the workspace, omit `calendarIds`. Use the user's timezone, or
   their calendar's `timezone`, and say which one you used.
3. Call `get_meeting_analytics` (meetings only, the default) with the same `dateFrom`, `dateTo`, `timezone` and
   `calendarIds` each time:
   - Totals: `measures: ["hours", "count", "median_duration", "median_attendees"]`, `groupBy: "none"`.
   - Trend: `measures: ["hours"]`, `groupBy: "none"`, `granularity: "week"`.
   - Length mix: `measures: ["hours", "count"]`, `groupBy: "meeting_length"`.
   - Size mix: `measures: ["hours", "count"]`, `groupBy: "meeting_size"`.
   - Recurring vs one-off: `measures: ["hours", "count"]`, `groupBy: "recurring"`.
   - Top organizers: `measures: ["hours", "count"]`, `groupBy: "organizer"`, `limit: 10`.
4. If a result has a `syncRangeWarning`, keep it for the summary.

## Output

- Headline numbers: total meeting hours, number of meetings, average hours per week, median meeting length and
  attendees.
- The weekly trend (rising, falling or flat, with the numbers).
- Short tables for length mix, size mix, recurring vs one-off, and the top organizers.
- Two or three suggestions that follow from the numbers, for example reviewing a large block of recurring meetings or
  shortening default lengths if most meetings are 60 minutes. Tie each suggestion to a figure.
- The exact period, calendars covered and timezone.

## Do not

- Do not invent figures or benchmarks; compare only within the user's own data.
- Do not judge individuals; describe organizers by meeting time, and only show them if the user asked about the team.
- Calendars are limited to those the user can access in TimeTackle.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: time-breakdown
description: Break down where time went in TimeTackle - hours by tag, project, client, department or any other property for a period, optionally per person or per calendar, including untagged time. Use when the user asks how time was split, what took the most time, or hours per tag or property.
---

# Time breakdown

Answer "where did the time go?" with hours per tag or property value for a clear date range. Explicit instructions
from the user (period, people, property, format) take priority over these steps.

## Input

- A period. If none is given, use the last full week and say so. Convert relative periods ("last month",
  "this quarter") to exact `YYYY-MM-DD` dates.
- What to break down by: a property the user names (Project, Client, Department, ...) or, if none, the top-level tags.
- Optionally per person or per calendar, or limited to specific calendars.

## Steps

1. Call `get_account` and read `syncRange`. If the period falls partly or fully outside it, tell the user that data
   only exists from `syncRange.start` to `syncRange.end` before showing numbers.
2. Find the property. Call `get_properties` with `search` set to the name the user gave (for example "Client").
   - Note its `key` and `state` (PRIMARY or SECONDARY).
   - If several properties match, ask which one. If none match, list a few property keys and ask; do not guess.
   - If the user named no property, skip this step and break down by the top-level tags (step 3, no `tagKey`).
3. Call `get_meeting_analytics`:
   - `measures: ["hours"]` (add `"count"` if the user asks how many meetings or entries).
   - `groupBy: "primary_tag"` for a PRIMARY property, `"secondary_tag"` for a SECONDARY one.
   - `tagKey`: the property's key, to get hours per value. Omit it to get hours per tag; that view includes an
     "UNTAGGED" row for time with no tag.
   - `splitBy: "user"` for per person, or `"calendar"` for per calendar.
   - `dateFrom`, `dateTo`, and `timezone` (the user's stated timezone, otherwise the `timezone` of their own calendar
     from `get_imported_calendars`; say which one you used).
   - `calendarIds` only if the user limited the calendars.
4. If `summary.nextOffset` is not null, call again with `offset` set to it until it is null, and combine the rows.
5. If the result has a `syncRangeWarning`, repeat it to the user.

## Output

- A table sorted by hours, largest first: value, hours (one decimal), share of the total (%). With `splitBy`, one row
  per person (or calendar) and value, or a person × value table if it stays readable.
- The total hours and the exact date range.
- With `tagKey`, say that time without a value for that property is not included. Without `tagKey`, show UNTAGGED
  as its own row.
- Follow the result's `visualization` hint if the user wants a chart.

## Do not

- Do not invent values, people or hours that are not in the tool results, or fill gaps with estimates.
- Do not describe a person's performance; report hours only.
- People and calendars are limited to what the user can access in TimeTackle; do not suggest others exist.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: weekly-timesheet
description: Build a weekly timesheet from TimeTackle - a person's hours per day and per project or tag for a week, with untagged time and days with little tracked time called out. Use when the user asks for their timesheet, what they worked on this or last week, or a weekly summary of their time.
---

# Weekly timesheet

Summarize one person's week from their calendars. Explicit instructions from the user (which week, which person,
grouping, format) take priority over these steps.

## Input

- The week. If none is given, use the current week (Monday to Sunday) and say so; "last week" is the previous one.
- The person: the connected user unless they name someone else.
- Optionally the property to group by (for example Project); otherwise the top-level tags.

## Steps

1. Call `get_account` for the user's email and `syncRange`. If the week reaches outside the sync range, say so.
2. Call `get_imported_calendars` and pick the person's calendars: those whose `user.email` is the person's email.
   - For someone else, they must appear in the list; if they don't, say you cannot see their calendars and stop.
   - Use the `timezone` of their calendar unless the user gave one, and say which one you used.
3. Daily totals: call `get_meeting_analytics` with `measures: ["hours"]`, `groupBy: "none"`, `granularity: "day"`,
   `meetingsOnly: false`, the week's `dateFrom` / `dateTo`, `timezone`, and `calendarIds` set to the person's calendars.
4. Time by project or tag: call `get_meeting_analytics` with `measures: ["hours"]`, the same dates, timezone and
   `calendarIds`, and either:
   - `groupBy: "primary_tag"` (no `tagKey`) for hours per tag, including an UNTAGGED row; or
   - the property the user named: find it with `get_properties` (`search`), then `groupBy` by its `state` and
     `tagKey` set to its key.
5. Optionally, for detail, call `get_events` with the person's `calendarIds`, the week's dates and `timezone` to list
   the week's events by day (page with `page` if there are more).

## Output

- A day-by-day table: date, hours.
- A table of hours per project or tag, with UNTAGGED as its own row when present.
- The week's total hours, the exact dates and the timezone.
- Call out days with no or very little tracked time, without assuming a standard working day unless the user gives
  one. If untagged time is large, suggest tagging it in TimeTackle.
- If a result has a `syncRangeWarning`, include it.

## Do not

- Do not invent events, projects or hours; report only what the tools return.
- Do not judge the person's productivity; describe the time.
- Do not create or change anything; to add missing time, the user can ask to log it.

Referenced files: 1 — file references are metadata, not package contents.