schedule-visualizer

name	schedule-visualizer
description	Generate a polished, single-file HTML project schedule — either a daily Excel-like calendar grid or a Gantt timeline (or both) — from a set of work items, dates, and milestones. Use this whenever the user wants to visualize, lay out, or "예쁘게 뽑아줘" a project plan, merge/release schedule, roadmap, sprint, or 일정표 as HTML; whenever they ask for a Gantt chart, timeline, calendar view, or day-by-day plan; or whenever a planning/estimation discussion produces issues + durations + a target date that would be clearer as a visual. Trigger even if the user doesn't say "HTML" — if they're organizing a schedule to send to a manager or team, offer this. Especially fits CUBRID merge/milestone planning (e.g., feat branch → develop) with JIRA issue numbers, holidays, and review-gated timelines.
argument-hint	[gantt|calendar|both] [optional: project/branch or path to a plan doc]

Schedule Visualizer

Turn a project plan into a polished, self-contained HTML artifact a manager can open offline, forward by email, or print. Two formats, one design system:

• Daily calendar — Excel-like Mon–Fri grid, one chip per task per day. Best for concrete day-by-day plans, holidays, "엑셀처럼 칸 나눠서".
• Gantt timeline — week-column bars across overlapping workstreams, with the critical path called out. Best for a one-glance overview.

The look is deliberately not generic-AI: a tuned palette, semantic color buckets, an issue dictionary, holiday/milestone/buffer cells. The proven CSS and structure live in the templates — your job is to gather the data and fill them faithfully, not to redesign from scratch.

When to use

• "일정표 HTML로 뽑아줘", "간트 차트 만들어줘", "스케줄 시각화", "달력처럼 보여줘", "이 계획 예쁘게 정리해서 팀장한테 보낼 수 있게"
• A planning/estimation thread just settled on issues + durations + a target date.
• CUBRID milestone/merge planning with CBRD-XXXXX issues, holidays, CI gates.

If it's a one-line "when's the deadline" question, just answer — don't build an artifact. Reach for this when there's enough structure (several items, dates, a milestone) that a picture genuinely beats prose.

Workflow

1. Read the design system first

Read references/design-system.md. It defines the data model, the buckets and palette, chip/bar anatomy, special cells, and the verification step. Don't skip it — the templates assume you know the bucket semantics.

2. Gather the inputs

Collect the project frame (start date + weekday, working week, holidays, target/ milestone, buffer) and the work items (exact id, summary, bucket, status, day(s), excluded?). Pull as much as you can from the current conversation and the repo (git log, JIRA via the cubrid-jira skill, PRs via gh) before asking the user.

The schedule logic — what's the critical path, velocity, what gates "done" — swings the dates more than anything. If it's not already established in the conversation, ask. A common and important finding: when most work is already in draft PRs, the critical path is human review throughput, not coding — model the timeline around that, not around keyboard time.

Never invent or approximate an issue id. If you're unsure of an exact JIRA summary or status, look it up.

3. Pick the format

• User asked for one → do that one.
• "both" → produce two files.
• Unsure → produce the calendar (it carries more concrete information), and offer the Gantt as a follow-up.

4. Fill the template

Copy the chosen template from assets/ to the working directory (name it for the project, e.g. oos-m2-merge-calendar.html). Then:

• Replace header/cards/meta with project facts.
• Build the week rows / workstream bars from the work items.
• Mark holidays, the milestone day, and buffer days with their cell classes.
• Fill the issue dictionary; put out-of-scope items in greyed excl rows.
• Trim the legend to only the buckets you used.
• Add a footer line recording the assumptions baked in ("공휴일 6/3 반영 · 매뉴얼 2h · 26383 제외") so the file is self-documenting out of context.

Reuse the CSS variables/classes — never hand-write new inline hex colors (that's the corrupted-hex bug waiting to happen). If a project needs a new category, add a --var + .c-x/.a-x (calendar) or .b-x (Gantt) pair, not a one-off color.

5. Verify before delivering — required

Run the bundled check:

bash <skill-dir>/scripts/verify_html.sh <output.html>

It catches corrupted hex colors (e.g. #5b6personally), unbalanced div/td/tr tags, and accidental external resource references. Fix anything it flags. These failures are invisible on a casual glance but break the render — don't rely on eyeballing.

6. Deliver

Hand over the file path. If running in a UI that surfaces files, surface it. Give a 2–3 line summary of what's in it, then offer the obvious next moves:

• the other format (Gantt ↔ calendar) for consistency,
• adjusting assumptions (velocity, holidays, scope) and regenerating,
• a manager-ready one-paragraph summary to paste into a reply.

Keeping it in sync

When the user changes an assumption — removes an issue, compresses a phase, shifts a date — regenerate the affected file fully. A schedule the reader has to mentally patch is worse than none. If you produced both formats, update both so they don't contradict each other.

Notes

• These are static artifacts, not apps. No build step, no dependencies.
• The templates are Korean-first (font stack + example copy) but work in any language — swap the text, keep the structure.
• If the frontend-design skill is available and the user wants a bolder or rebranded look, you can layer it on top — but preserve the single-file, offline-safe, print-friendly constraints above.