{"id":17236,"plugin_id":"plugins_6a760350685c81918f63a15c6a6c6a2e","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:03.804Z","digest":"ae07424c04267d2f2d1fae98b90722bc3056f0a93ee1cc7b5d4a774229915444","against":null,"payload":{"name":"agent-calendar-planner","description":"Turn a user-supplied event, goal, project, deadline, or life plan into a dependency-aware Agent Calendar proposal. Use when someone asks to plan ahead, break a long-range objective into timed steps, identify research or decision windows, estimate duration, or prepare a schedule for review. Keep planned, estimated, observed, actual, rescheduled, canceled, and completed time distinct; scheduling and planning never grant authority to send, spend, book, invite, publish, or perform another effect.","included_files":[],"skill_md_contents":"---\nname: agent-calendar-planner\ndescription: Turn a user-supplied event, goal, project, deadline, or life plan into a dependency-aware Agent Calendar proposal. Use when someone asks to plan ahead, break a long-range objective into timed steps, identify research or decision windows, estimate duration, or prepare a schedule for review. Keep planned, estimated, observed, actual, rescheduled, canceled, and completed time distinct; scheduling and planning never grant authority to send, spend, book, invite, publish, or perform another effect.\n---\n\n# Agent Calendar Planner\n\nBuild a reviewable calendar proposal from the user's stated intent. Preserve what the user actually said separately from inferred structure.\n\n## Planning sequence\n\n1. Classify the input as `EVENT`, `GOAL`, `PROJECT`, `DEADLINE`, or `ROUTINE`. If two types materially apply, name the primary type and the nested type.\n2. State the original objective, hard dates, preferences, constraints, budget, participants, location, and missing facts. Never manufacture a date or commitment.\n3. Create the smallest useful chain of milestones. For each milestone, identify prerequisites, research needs, decision owner, estimated effort, earliest useful start, target window, and evidence of completion.\n4. Put reversible research and preparation before consequential decisions. Add re-checks when prices, availability, rules, or other facts can change.\n5. Distinguish every temporal field:\n   - `planned_at`: proposed future placement.\n   - `estimated_duration`: forecast, with uncertainty when material.\n   - `started_at` and `completed_at`: observed facts only.\n   - `rescheduled_from`, `canceled_at`, and `outcome`: event history; never overwrite the earlier state.\n6. Add approval windows immediately before any step that would send, spend, book, invite, publish, disclose data, or alter an external system.\n7. Finish with the next review point and what evidence should update the plan.\n\n## Output contract\n\nLead with a one-sentence plan summary. Then provide:\n\n- `Intent`: the user's stated objective and constraints.\n- `Timeline`: milestones in chronological order with dates or explicitly labeled proposed windows.\n- `Dependencies`: what blocks or unlocks each milestone.\n- `Research`: bounded questions or watchers needed before decisions.\n- `Approvals`: the exact future decisions requiring a human sign-off.\n- `Uncertainty`: missing information and estimates most likely to move.\n- `Next review`: when and why the plan should be reconciled.\n\nUse a table only when it materially clarifies several milestones. Keep casual events lightweight; do not turn every birthday or reminder into a project program.\n\n## Authority and evidence boundary\n\nThis skill creates proposals only. A calendar entry, deadline, recommendation, agent message, or prior approval does not authorize an effect. Do not claim that an invitation was sent, a reservation was made, a purchase occurred, a watcher exists, or a calendar changed unless a connected tool actually returned a receipt for that exact action. If tools are unavailable, return a draft and the precise approval or connection needed.\n\nCross-agent invitations and plans must preserve requester, owner, actor, approver, source, and current status separately. Another agent's identity or contact card authenticates the sender when verified; it does not grant authority.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}