Weekly Plan Skill

Pull your ClickUp tasks for the current week and lay them out into an hour-by-hour, day-by-day schedule, written to a markdown file.

Gather context first

This skill ships standalone, so it can't assume your project's conventions, house style, or preferences the way it could for its author. Before doing the main work:

1. Auto-detect what you safely can from the repo — language/stack, base branch, build/test commands, existing config and docs. Never ask for something you can read for yourself.
2. Ask, don't assume, for the rest. Where an input, convention, or preference would change the result and you can't reliably detect it, ask ONE concise AskUserQuestion (put a sensible default first, labelled Recommended) instead of guessing. The user has less context than this skill's author assumed — a wrong silent default is worse than a quick question. Don't ask about things you can detect, and don't ask more than you need.

For this skill, confirm up front (only the items you can't already detect):

• Which week to plan — default the current week containing today; offer next week as the alternative. (The timezone itself is auto-detected via date +%z — don't ask for it.)
• Working hours & week shape — default Mon–Fri, 10:00–20:00 with a 12:00–13:00 lunch (8h work + 1h buffer per day, 40h/week). Confirm if your week runs differently (different days, hours, or daily capacity).
• Your ClickUp status names — which statuses in your workspace mean "in progress" and "still open / not started" (workspaces rename these freely). Detect from the workspace where you can; confirm if ambiguous.
• Where to write the plan — default the current working directory as weekly-plan-YYYY-MM-DD.md; honor a different path if the user prefers one.

Configuration

A few parameters drive the schedule. The defaults below work out of the box; the user can override any of them when they ask.

• Timezone: all date math runs in the user's local timezone. Read the system offset with date +%z (e.g. +0700), or honor an explicit timezone if the user names one. Every example below uses OFFSET to stand in for that local UTC offset.
• Working hours: 10:00–20:00 (9 hours: 8h of work plus a 1h buffer).
• Lunch: 12:00–13:00.
• Week shape: Monday through Friday, 8h/day, 40h/week.

Step 1: Identify the User

Call clickup_resolve_assignees with ["me"] to resolve the current user's ID.

Step 2: Set the Week Window

Read today's date (date). Find the Monday and Friday of the week that contains today (or whichever week the user confirmed in Gather context first — e.g. next week). Do all of this in the local timezone from the Configuration section.

Step 3: Pull Tasks

Issue these three queries in parallel, all keyed on the user ID from Step 1. These are parallel tool calls in this same context — cheap, no subagents needed.

1. Due this week — clickup_filter_tasks:
   • assignees: [userId]
   • due_date_from: <Monday>
   • due_date_to: <Sunday> (catch weekend due dates too)
   • order_by: "due_date"
   • subtasks: true
2. Currently in progress — clickup_filter_tasks:
   • assignees: [userId]
   • statuses: [<your in-progress status>]
   • order_by: "due_date"
3. Overdue and still open — clickup_filter_tasks:
   • assignees: [userId]
   • statuses: [<your open / not-started status>]
   • due_date_from: <6 months ago>
   • due_date_to: <day before Monday>
   • order_by: "due_date"

"in progress" and "to do" are ClickUp's stock status names, but most workspaces rename them (e.g. "doing", "active", "backlog", "open"). Don't assume the literals — use the status names confirmed in Gather context first, or detect them from the workspace (the statuses seen on the user's own tasks, or clickup_get_workspace_hierarchy) and confirm if ambiguous before filtering.

Merge the three result sets and drop duplicates by task ID.

Step 4: Enrich Each Task

For every unique task, call clickup_get_task with detail_level: "summary" and collect:

• id, name, description (fall back to text_content)
• start_date, due_date (unix ms)
• time_estimate (unix ms)
• priority
• status
• assignees
• parent (useful context when the description is blank)
• list.name, folder.name (project context)

Fire these in parallel, batching up to 10 calls at a time.

When a task's description is empty, fall back to the parent task name plus the list/folder name for context.

Step 5: Normalize Timestamps

ClickUp returns every timestamp as milliseconds since the Unix epoch in UTC.

Convert each timestamp into local time before reasoning about which day it belongs to. Take the ms value, interpret it as UTC, then apply the local OFFSET.

Watch for this gotcha: ClickUp frequently stores a due date as a near-end-of-day UTC timestamp, which lands in the small hours of the next calendar day once you apply a positive offset. After converting, read the resulting calendar day as the real due date.

Worked example (with OFFSET = +7h):

• 1774904400000 → Mar 30, 21:00 UTC → Mar 31, 04:00 local → due Mar 31
• 1774990800000 → Mar 31, 21:00 UTC → Apr 1, 04:00 local → due Apr 1

Turn time_estimate from ms into hours with ms / 3600000.

Step 6: Lay Out the Days

Capacity

• 8h of work per day, plus a 1h buffer (the final hour of each day) held back for incidents and overflow.
• 40h of work across the Mon–Fri week.

Ordering Rules

1. Anything that depends on other people (meetings, onboarding, handoffs, collaboration) goes first thing, at 10:00, so nobody is left waiting on you.
2. Anything that ships to production (releases, migrations, deploys) goes after 20:00 to keep blast radius low.
3. Overdue work lands first on Monday — right after any people-dependent items.
4. Same-day tasks (start date equals due date) are pinned to that day.
5. Ranged tasks (a start-to-due window spanning several days) can be spread across that window.
6. Never schedule a task before its start date.
7. Never let a task slip past its due date.

Deployment Spillover

When deploy work pushes past 20:00, delay the next day's start by the same amount.

• Example: deploys run 20:00–21:00 → the next day begins at 11:00 instead of 10:00.
• That shifted day loses an hour of capacity. Bump the lowest-priority flexible task to absorb it.
• Protect the buffer — trim work hours, not the buffer.

Over Capacity

When the estimated total exceeds the hours you actually have:

1. Raise a capacity warning that states the shortfall.
2. Pick which tasks spill into next week — prefer flexible ones with Mon–Fri ranges.
3. Show a spill table breaking down estimated vs. scheduled vs. spilled per task.

Step 7: Write the Markdown File

Save as weekly-plan-YYYY-MM-DD.md, where the date is the Monday of the planned week. Default to the current working directory; write to a different path if the user named one in Gather context first.

Layout:

# Weekly Task Plan: <Month Day> - <Month Day>, <Year>

**Total tasks:** N
**Total estimated:** Xh / 40h available (5h buffer reserved, 9h/day)
**Capacity:** OK | WARNING: Xh over capacity

---

## Task List

### OVERDUE

| # | Task ID | Task Name | Description | Start | Due | Est. | Priority | Status |
|---|---------|-----------|-------------|-------|-----|------|----------|--------|
| 1 | [ID](url) | Name | Context | Date | Date | Xh | P | status |

### This Week

| # | Task ID | Task Name | Description | Start | Due | Est. | Priority | Status |
|---|---------|-----------|-------------|-------|-----|------|----------|--------|
| 2 | [ID](url) | Name | Context | Date | Date | Xh | P | status |

---

## Daily Plan (8h work + 1h buffer per day = 9h)

### Monday, <Date> (8h work + 1h buffer)

| Time | Task | Hours |
|------|------|-------|
| 10:00 - 11:00 | [People task first if any] | 1h |
| 11:00 - 12:00 | Task name | 1h |
| 13:00 - 19:00 | Task name | 6h |
| 19:00 - 20:00 | **BUFFER** — incidents / overflow | 1h |
| **Total** | | **8h + 1h buffer** |

### Thursday, <Date> (8h work + 1h buffer + deployments after hours)

| Time | Task | Hours |
|------|------|-------|
| 10:00 - 19:00 | Regular tasks | 8h |
| 19:00 - 20:00 | **BUFFER** — incidents / overflow | 1h |
| 20:00 - 20:30 | Deployment task 1 | 30min |
| 20:30 - 21:00 | Deployment task 2 | 30min |
| **Total** | | **8h + 1h buffer + 1h deployment** |

### Friday, <Date> (Xh work + 1h buffer)
> Start shifted to 11:00 due to Thursday deployments ending at 21:00

| Time | Task | Hours |
|------|------|-------|
| 11:00 - 12:00 | [People task first] | 1h |
| 13:00 - 19:00 | Tasks | 6h |
| 19:00 - 20:00 | **BUFFER** — incidents / overflow | 1h |
| **Total** | | **7h + 1h buffer** |

---

## Spill to Next Week

| Task | Estimated | Scheduled | Spill |
|------|-----------|-----------|-------|
| Task name | 4h | 3h | **1h** |
| **Total spill** | | | **Xh** |

---

## Key Actions

- Summary of schedule decisions
- Critical deadlines to watch
- Tasks requiring coordination with others

Description column:

• When a description exists, use it (trim to ~100 chars).
• When it's empty, use **[List Name]** Parent: <parent task name> as the stand-in.
• For bug tasks, surface the severity if a custom field carries it.
• For deployment tasks, name the target product/client from a custom field or the list name.

Priority column:

• Use ClickUp's labels: Urgent, High, Normal, Low.
• When priority is null, show —.

Error Handling

• If a clickup_get_task call errors out (502, timeout), retry it once. If it still fails, fall back to the summary fields already returned by clickup_filter_tasks.
• If nothing comes back, write a file that says "No tasks found for this week" and suggest verifying in ClickUp directly.
• If the ClickUp MCP isn't connected, ask the user to connect it before continuing.