Weekly Calendar Grid

VerifiedSafe

Display an agent's weekly plan as a calendar grid with day columns and hour rows. Tasks are numbered for easy reference.

Sby Skills Guide Bot
ProductivityIntermediate
7/24/2026
Claude Code
#calendar#weekly-planning#agent-scheduling#schedule-visualization#iso-week

Recommended for

Automated summary

Renders an agent's weekly plan as a calendar grid with day columns and hour rows, numbering tasks so users can ask about any of them by number.

Strengths

  • Explicit step-by-step workflow: pick the agent, resolve the week, then render the grid
  • Flexible week resolution accepting ISO keys (2026-W17), plain dates, bare week numbers, and aliases such as next or last
  • Markdown-table output that reflows to the terminal width, plus a box format for hosts that cannot render pipe tables
  • Numbered task index that lets the user request details for a specific task by its number

Limitations

  • Fully dependent on the aweek exec calendar CLI and on an agent already existing, otherwise the skill stops early
  • Without a stated week, it silently falls back to the latest approved plan rather than asking
  • The grid is display-only: the skill neither creates nor edits any plan
When to use it

When you want a quick visual overview of an agent's planned week and to reference tasks by number.

When not to use it

When you need to create an agent, schedule new tasks, or edit an existing plan, which this skill does not handle.

Security analysis

Safe
Quality score88/100

The skill is a read-only presentation helper: it invokes a domain-specific CLI (`aweek exec calendar <subcommand>`) with JSON piped over stdin, never shell-interpolating user input into a command line. There are no destructive operations, no network exfiltration of secrets/tokens, no obfuscated payloads, and no attempts to bypass safety controls. Bash use is narrowly scoped to listing agents, resolving a week key, and rendering a grid — all display operations.

No concerns found

How this analysis is made

Examples

Show this week's plan
Show me the calendar for my planning agent for this week
Pick a specific ISO week
Display the weekly calendar of the agent named Atlas for 2026-W17
Shift to next week
aweek calendar: show next week's plan and list the numbered tasks

name: calendar description: Display an agent's weekly plan as a calendar grid with day columns and hour rows trigger: aweek calendar, weekly calendar, plan calendar, show calendar, agent calendar

aweek:calendar

Display an agent's weekly plan as a calendar grid with day columns and hour rows. Tasks are numbered so users can ask about any task by number.

Instructions

You MUST follow this exact workflow when this skill is invoked.

Step 1: Select an Agent

List all available agents:

aweek exec calendar listAgentsForCalendar

The call returns a JSON array of { id, name, role } records. Treat an empty array as the no-agents case.

  • If no agents exist, inform the user: "No agents found. Use /aweek:hire to create one first." and stop.
  • If only one agent exists, auto-select it.
  • If multiple agents exist, ask the user to pick one using AskUserQuestion.

Step 2: Resolve the Week (optional)

If the user didn't mention a specific week, skip this step and go to Step 3 — the renderer defaults to the agent's latest approved plan.

If the user mentioned a week (e.g. "week 17", "the week of April 20", "next week", "2026-W14"), pass that string verbatim to loadAndRenderGrid as a week field — it accepts every shape below — or pre-resolve it to the canonical YYYY-Www so you can confirm the choice in your reply:

echo '{ "input": "next" }' | aweek exec calendar resolveWeekKey --input-json -

Accepted shapes:

| Input | Meaning | |-------|---------| | 2026-W17 | Canonical ISO week (case-insensitive W) | | 2026-04-20 | Any ISO date — derives the ISO week containing it | | 17 or W17 | Bare week number — uses the current ISO year (in the project time zone) | | current, this, now | Current week | | next | Next ISO week | | prev, previous, last | Previous ISO week |

Invalid input throws — the skill should surface the error message and re-ask.

Step 3: Render the Calendar Grid

The default output is a GitHub-flavored markdown table (format: "markdown"). Claude Code's terminal UI re-flows pipe tables to the available width, so the calendar expands / contracts with the window instead of sitting in a fixed 120-column box. Pass format: "box" only when the host cannot render markdown tables (e.g. raw log tails) — the Unicode box-drawing grid still works but its columns are fixed.

Run the grid renderer to get the calendar text and task index. Add a week field when targeting a specific week (omit for the latest approved plan):

echo '{
  "agentId": "<AGENT_ID>",
  "week": "<WEEK_OR_DATE_OR_ALIAS>",
  "opts": {
    "format": "markdown",
    "startHour": 9,
    "endHour": 18,
    "showWeekend": false,
    "spread": "spread"
  }
}' | aweek exec calendar loadAndRenderGrid --input-json -

The response JSON contains success, output (the rendered grid text), taskIndex (the numbered task list), and errors when success === false. When the requested week has no plan on disk, errors lists every available week so you can prompt the user to pick one of them.

IMPORTANT — Not collapsed display: After running the command, you MUST output the calendar text as direct text in your response — for format: "markdown", paste the markdown table itself (no surrounding code block, so the UI renders it as a table); for format: "box", wrap result.output in a fenced code block so the Unicode borders don't reflow. Do NOT just reference the bash output — copy result.output and display it yourself so it appears expanded, not collapsed inside a bash result.

Step 4: Stop (no follow-up question)

The rendered grid already ends with Select a task number (1-N) to see details. — that is the only prompt the user needs. Do not emit an AskUserQuestion, a "What would you like to do?" menu, an adjust-view picker, or any other interactive step after displaying the calendar. Just end your turn.

Keep result.taskIndex in mind for the follow-up turn: if the user later types a task number (or asks about a specific task), look it up there and respond with its details. Do not volunteer that lookup until asked.

Render Options

| Option | Default | Description | |--------|---------|-------------| | format | markdown | markdown (responsive pipe table — default) or box (fixed-width Unicode grid) | | startHour | 9 | First hour row (0-23) | | endHour | 18 | Last hour row exclusive (1-24) | | terminalWidth | — | Box format only. Available terminal columns; auto-fits cellWidth when set | | cellWidth | auto | Box format only. Explicit per-day column width. Overrides terminalWidth | | showWeekend | false | Include Saturday and Sunday columns | | spread | pack | Distribution: pack (fill days) or spread (round-robin) |

How It Works

  • Tasks are numbered in column-major order (top-to-bottom per day, then the next day) for selection
  • Review slots (daily-review and weekly-review) receive selection numbers identical to regular work tasks — you can select them by number and apply status transitions (pending, in-progress, completed, failed, skipped) exactly the same way
  • Each hour row is as tall as its fullest cell. Every task gets its own block of wrapped lines inside the cell; empty cells pad with blanks to line up.
  • Each task displays up to 30 visible characters (<icon> <num>. <description>). Anything beyond collapses with a trailing …. Those 30 chars wrap across cell lines based on column width — narrow columns just use more rows.
  • Half-hour tasks (e.g. runAt at HH:30) bucket into the same HH:00 cell as HH:00 tasks, so they don't disappear from the view.
  • Status icons show progress: ○ pending, ► in-progress, ✓ completed, ✗ failed; ◆ marks review slots (also selectable by number)
  • The calendar is displayed as direct text (not bash output) so it's always visible
  • Time zone: day columns and hour rows reflect the user's configured time zone in .aweek/config.json (timeZone). runAt is stored as an absolute UTC ISO string, projected into that zone for display. Update the config file to switch zones; no per-agent override yet.

Related Skills

  • /aweek:plan — Edit weekly plans (add/remove tasks, adjust goals, approve/reject)
  • /aweek:summary — Dashboard view across all agents
  • /aweek:hire — Create a new agent with identity, goals, and initial plan

Data Directory

Agents are stored in .aweek/agents/<agent-id>.json relative to the project root.

From the file to a first result

The download contains exactly the content displayed on this page. This copy may differ from the latest version in the source repository.

View the source and supporting files

This download contains SKILL.md only. Any scripts, references, templates and dependencies are not included. Get the required files from the source, preserving their directory structure, before continuing.

1. Download the file

Download SKILL.md

From the root of a test project, save the file as .skill-downloads/weekly-calendar-grid-mryiqhux/SKILL.md, or use the command below. This folder is for inspecting the skill before installation.

Command for macOS/Linux or WSL: requires a POSIX shell and curl. On Windows without WSL, use the download button and create the folder manually.

mkdir -p '.skill-downloads/weekly-calendar-grid-mryiqhux' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/weekly-calendar-grid-mryiqhux/download' --output '.skill-downloads/weekly-calendar-grid-mryiqhux/SKILL.md.part' && mv '.skill-downloads/weekly-calendar-grid-mryiqhux/SKILL.md.part' '.skill-downloads/weekly-calendar-grid-mryiqhux/SKILL.md'

2. Check prerequisites

Read SKILL.md before using it. If it references scripts or external services, inspect them and prepare the required access in your test environment.

No recognized prerequisites section in this file. This does not mean it is self-contained: libraries, tools and access requirements may be mentioned elsewhere in the content or source repository.

The platforms on this page are catalog indications. The paths below follow tool documentation; they do not prove this skill has been run in those tools. No minimum tool version is confirmed for this listing.

3. Load the skill

After inspection, copy the complete folder into your project using one of the commands below, then open a new tool session. The command stops if a folder with the same name already exists: compare the files before replacing it.

Claude Code
test -f '.skill-downloads/weekly-calendar-grid-mryiqhux/SKILL.md' && test -s '.skill-downloads/weekly-calendar-grid-mryiqhux/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/calendar' && cp -R '.skill-downloads/weekly-calendar-grid-mryiqhux' '.claude/skills/calendar'

OpenSkills

OpenSkills must already be installed. The local install/read procedure is checked with OpenSkills 1.5.0, which requires Node.js ≥ 20.6.0. Catalog slugs are not resolved automatically.

Official OpenSkills installation
openskills install './.skill-downloads/weekly-calendar-grid-mryiqhux'

openskills read 'weekly-calendar-grid-mryiqhux'

Reading should display the installed file content and its base directory. It does not run the skill or install its dependencies.

For an agent that reads AGENTS.md, then sync the index. This command changes AGENTS.md: review the diff before using it.

openskills sync

Manual method or another tool: attach SKILL.md to a conversation, or open it in an agent that can read files. Include any required supporting resources. No universal folder is recognized by every tool.

4. Try a first task

Use a short, synthetic input: an API endpoint, a small document or an interface brief. In a new conversation, attach the file or give the agent its path, then adapt this request:

Read .skill-downloads/weekly-calendar-grid-mryiqhux/SKILL.md and apply its instructions to this example: [describe a test input]. Identify any missing files, dependencies or access. Produce the result requested by the skill without inventing data or running unreviewed scripts.

Expected result: output matching the skill instructions, or a precise list of missing prerequisites. A read confirmation alone does not validate a first use. If an external resource is unavailable, that path remains untested.

Related skills