calendar-view

Skill: Calendar View

Generate an interactive, scrollable HTML calendar view from a markdown schedule file. The calendar uses the Canvas skill to display as a borderless app window. Any schedule with named categories (phases, milestones, events) and dates or date ranges can be visualized. Examples: iteration plans, project timelines, release schedules, marketing calendars, sprint plans, academic term schedules.

---

When to Use

Use this skill when someone provides a markdown file (or describes a schedule) with named events and dates, and asks for a calendar view, visual timeline, or schedule visualization.

---

Getting Started: Single Month or Multi-Month

The user may provide a full multi-month markdown schedule, OR they may provide just a single month (or even just describe their process verbally). Handle both cases.

If the user provides a complete multi-month markdown file

Skip to the Input Format section and generate the calendar directly. Still ask for the calendar title before generating.

If the user provides only one month (or describes their process)

Use the single month as a template to learn their recurring pattern, then ask questions using the ask_user tool to fill in the gaps before generating additional months. Ask one question at a time.

Step 1: Identify their categories

Look at the categories in their first month. Classify each as a band (date range) or tag (single date) based on whether it has an end date. Note the category names -- do not rename them.

Step 2: Ask about their recurring patterns

Based on what you see in month 1, ask targeted questions to confirm the pattern. Adapt these to whatever categories they have:

• "It looks like [event X] always lands on [day of week] -- is that always the case?"
• "[Phase Y] ran about [N] days/weeks. Is that typical, or does it vary?"
• "[Event A] and [Event B] happen on the same day. Is that always the case?"
• "I see [N] occurrences of [recurring event] during [phase]. Is that the pattern?"
• "Does [phase] always start the day after [other phase] ends?"

Only ask about things you cannot confidently infer. If the pattern is obvious, confirm it in one question rather than asking separately for each detail.

Example for an iteration plan: "Your releases land on Wednesdays, Dev runs ~3 weeks, and Endgame goes Thursday through the following Friday. Is that the standard pattern?"

Step 3: Ask how many months to generate

"How many months ahead should I generate? And what month should I start from?"

Step 4: Generate the markdown schedule

Using the confirmed pattern, generate the full multi-month markdown schedule file and show it to the user for approval before building the calendar. This becomes their source-of-truth file.

Step 5: Build the calendar

Once approved, generate the HTML calendar and open it via Canvas.

---

Input Format

The source markdown must follow this structure. Each month is an H2 heading with a table of categories, start dates, and optional end dates:

# Schedule Title

## April 2026

| Phase | Start Date | End Date |
|------|------------|----------|
| **CATEGORY NAME** | 03-30 | 04-01 |
| **SINGLE-DAY EVENT** | 04-01 | |
| **ANOTHER RANGE** | 04-02 | 04-21 |

The column headers can be "Phase", "Event", "Category", or similar -- adapt to whatever the user provides. The key requirement is: a name, a start date (MM-DD), and an optional end date (MM-DD).

Example: Iteration plan

## April 2026

| Phase | Start Date | End Date |
|------|------------|----------|
| **PLANNING** | 03-30 | 04-01 |
| **MAR STABLE RELEASE** | 04-01 | |
| **APR PRE-RELEASE 1** | 04-01 | |
| **DEV** | 04-02 | 04-21 |
| **CODE FREEZE** | 04-22 | |
| **ENDGAME** | 04-23 | 05-01 |
| **APR STABLE RELEASE** | 05-06 | |

Classifying categories

Do NOT use keyword matching. Instead, classify based on the data:

• Has an end date (date range) => Band (colored horizontal strip spanning the date range)
• No end date (single date) => Tag (small pill-shaped label within the cell)

This works for any domain -- "Sprint", "Review Period", "QA", "Launch Window" all become bands if they have a date range. "Deadline", "Release", "Milestone", "Checkpoint" all become tags if they are single dates.

---

Output

A single HTML file saved via the Canvas skill (YYYY-MM-DD-topic.html). The calendar is scrollable vertically with one month section per iteration.

Page structure

[Sticky top bar with title]
[Month 1 heading + calendar grid]
[Month 2 heading + calendar grid]
[Month N heading + calendar grid]

Before generating the calendar, ask the user what they want the title to be using the ask_user tool. The title appears in the sticky top bar and the HTML <title>. Do not assume a default -- every team/product will have a different name. For example: "C# in VS Code - Iteration Calendar".

Each month heading uses the format "Month YYYY" (e.g., "April 2026") -- normal case, no "Iteration" suffix.

---

Calendar Grid

Each month is a standard Sun-Sat calendar grid. The grid must include enough weeks to contain ALL events for that iteration, from Planning through Stable Release (which often falls in the following calendar month).

Grid sizing

Count the weeks needed from the Sunday before the first event to the Saturday after the last event. Typically 5-6 weeks per iteration.

Cell types

Class	Meaning
.cal-day	Standard weekday cell
.cal-day.weekend	Saturday or Sunday (slightly tinted background)
.cal-day.outside	Date from a different calendar month than the section heading
.cal-day.today	Current date (blue outline highlight)

"Outside" means the date belongs to a different calendar month than the one labeled. For example, in the "April 2026" grid, any May dates are .outside. In the "May 2026" grid, any June dates are .outside. Dates that ARE in the labeled month are never .outside, even if they are in the first or last week row.

---

Band System (Connected Phase Strips)

Bands are the core visual element. They create colored strips that flow continuously across cell boundaries, bridging week breaks.

Band classes

Every band element gets the base .band class plus a position class:

Class	Purpose	CSS positioning
.band-start	First day of a phase (or first weekday of a new week for a continuing phase)	left: 6px; right: -1px; border-radius: 6px 0 0 6px;
.band-mid	Middle day of a phase	left: -1px; right: -1px; (overlaps cell borders for seamless connection)
.band-end	Last day of a phase (or Friday when the phase continues next week)	left: -1px; right: 6px; border-radius: 0 6px 6px 0;
.band-start.band-end	Single-day band	left: 6px; right: 6px; border-radius: 6px;

Week continuation rule (IMPORTANT)

When a band phase spans multiple weeks, each new week starts a fresh band element:

• Friday of the ending week gets .band-end
• Monday of the new week gets .band-start with the phase label text (e.g., "Dev", "Endgame")
• This ensures every week row has a visible text label for any active phase

Weekend days (Sat/Sun) never get band elements -- bands break at Friday and resume Monday.

Band text labels

• .band-start elements contain the phase label text: "Planning", "Dev", "Endgame"
• .band-mid and .band-end elements have no text content
• All band text is uppercase via CSS text-transform: uppercase

---

Tag System (Single-Day Events)

Tags are pill-shaped labels for single-date events (milestones, releases, deadlines, checkpoints, etc.).

Tag placement

Tags go inside a .tags container within the calendar cell:

<div class="tags">
  <div class="tag tag-release">Apr Stable Release</div>
  <div class="tag tag-prerelease">May Pre-release 1</div>
</div>

Interaction with bands

• If a cell has BOTH a band AND tags (e.g., Planning ends on the same day as a Stable Release), the .tags container uses margin-top: 32px (default) to sit below the band.
• If a cell has tags but NO band (e.g., Code Freeze day), use style="margin-top:0" on the .tags container.

Tag text

Use the full phase name from the markdown, preserving the month prefix. All tag text is uppercase via CSS.

Examples: "Apr Stable Release", "May Pre-release 2", "Code Freeze", "Jun Pre-release 4 (RC)"

---

Color Scheme

Colors are assigned dynamically based on the categories found in the schedule. Do NOT hardcode colors to specific phase names.

Color palette

Use this palette, assigning colors in order as new categories are encountered. Bands and tags draw from separate pools:

Band palette (for date-range phases):

Slot	Background	Text	Good for
1	#DBEAFE	#1E40AF	Blue - first phase
2	#D1FAE5	#065F46	Green - longest/main phase
3	#FEE2E2	#991B1B	Red/pink - urgent/final phase
4	#FEF9C3	#854D0E	Yellow - caution phase
5	#E0E7FF	#3730A3	Indigo - extra phase
6	#FFEDD5	#9A3412	Orange - extra phase

Tag palette (for single-day events):

Slot	Background	Text	Good for
1	#7C3AED	#F5F3FF	Dark purple - major milestones
2	#F3E8FF	#6B21A8	Light purple - recurring events
3	#FEF3C7	#92400E	Amber - warnings/freezes
4	#DBEAFE	#1E40AF	Blue - informational
5	#D1FAE5	#065F46	Green - approvals/completions
6	#FEE2E2	#991B1B	Red - critical deadlines

Assignment strategy

1. Group categories by type (band or tag)
2. Identify distinct category "families" (e.g., all "Pre-release" variants share one color, all "Sprint Review" variants share one color)
3. Assign a color from the palette to each family
4. Gene

---

Content truncated.