diff --git a/plugins/gmail/skills/gmail/SKILL.md b/plugins/gmail/skills/gmail/SKILL.md index 6c4049a1..b04b138f 100644 --- a/plugins/gmail/skills/gmail/SKILL.md +++ b/plugins/gmail/skills/gmail/SKILL.md @@ -46,7 +46,6 @@ For mailbox analysis requests such as triage, follow-up detection, topic summari ## Write Safety - Preserve exact recipients, subject lines, quoted facts, dates, and links from the source thread unless the user asks to change them. -- When drafting or sending a reply, use the user's actual name for greetings, self-reference, and signatures. Prefer the connector's `get_profile` result as the source of truth for the user's name, fall back to other first-party profile/contact context only if `get_profile` is unavailable, and ask the user before guessing. - When drafting a reply, call out any assumptions, missing context, or information that still needs confirmation. - Treat send, archive, trash, label, and move operations as explicit actions that require clear user intent. - If a thread has multiple possible recipients or parallel conversations, identify the intended thread before drafting or acting. @@ -60,7 +59,6 @@ For mailbox analysis requests such as triage, follow-up detection, topic summari - Avoid absolute claims like "the only urgent email" unless the mailbox scan was comprehensive enough to support that conclusion. - When the result comes from a narrowed search or shortlist, report that confidence and mention what was excluded. - Draft replies should be concise and ready to paste or send, with greeting, body, and closing when appropriate. -- When a draft includes the user's name or signature, use the real name from `get_profile` rather than inferring from the email address or making one up. - If a reply depends on missing facts, present a short draft plus a list of unresolved details. - When multiple emails are involved, reference the sender and timestamp of the message that matters most. diff --git a/plugins/gmail/skills/gmail/references/reply-workflow.md b/plugins/gmail/skills/gmail/references/reply-workflow.md index e1cb4e5e..97213677 100644 --- a/plugins/gmail/skills/gmail/references/reply-workflow.md +++ b/plugins/gmail/skills/gmail/references/reply-workflow.md @@ -6,7 +6,6 @@ Read this file when the user wants to reply to an email, draft a response, decid - Read the most recent thread items before drafting. At a minimum, inspect the latest message and enough recent context to understand who is asking for what, whether the thread already moved forward, and what tone the participants are using. - Match the thread's tone unless the user asks for a deliberate change. Pay attention to formality, brevity, warmth, directness, and how participants greet or sign off. -- Before writing a greeting, self-reference, or signature that uses the user's name, call `get_profile` and treat that as the primary source of truth. If the profile is unavailable, prefer other first-party profile/contact context and ask the user before guessing. - If the user asks to reply but not explicitly to send, default to a draft. - Gmail compose is not plain-text only. The body input is treated as Markdown/plain text and the send path includes both plain text and generated HTML. Do not claim that the connector only supports plain-text emails, but also do not assume it supports arbitrary custom HTML authoring. @@ -24,7 +23,6 @@ Read this file when the user wants to reply to an email, draft a response, decid 2. Read at least enough recent context to understand the latest ask, current status, open questions, and participants. 3. Escalate to `read_email_thread` when earlier back-and-forth changes the answer, recipient choice, or tone. 4. Preserve concrete facts from the thread such as dates, commitments, links, and names unless the user asks to change them. -5. Do not infer the user's name from their email address or make up a likely first name when signing the draft. ## Drafting Pattern diff --git a/plugins/outlook-calendar/.codex-plugin/plugin.json b/plugins/outlook-calendar/.codex-plugin/plugin.json index 14992087..7ac1ebdc 100644 --- a/plugins/outlook-calendar/.codex-plugin/plugin.json +++ b/plugins/outlook-calendar/.codex-plugin/plugin.json @@ -1,7 +1,7 @@ { "name": "outlook-calendar", "version": "0.1.0", - "description": "Work with Outlook Calendar using the configured Microsoft Outlook app connector.", + "description": "Connect Outlook Calendar for scheduling, daily briefs, event prep, and safe meeting changes.", "author": { "name": "OpenAI", "email": "support@openai.com", @@ -13,14 +13,18 @@ "keywords": [ "outlook-calendar", "calendar", - "microsoft" + "microsoft", + "scheduling", + "teams", + "daily-brief", + "meeting-prep" ], "skills": "./skills/", "apps": "./.app.json", "interface": { "displayName": "Outlook Calendar", - "shortDescription": "Compare availability and plan event changes", - "longDescription": "Use Outlook Calendar to compare availability, propose event diffs, and schedule, reschedule, or cancel events through the connected Microsoft Outlook app.", + "shortDescription": "Manage Outlook schedules and meeting changes", + "longDescription": "Use Outlook Calendar to summarize a day, compare availability, prepare for meetings, explain Outlook status semantics, and schedule, reschedule, or cancel events through the connected Microsoft Outlook app.", "developerName": "OpenAI", "category": "Productivity", "capabilities": [ @@ -30,9 +34,7 @@ "websiteURL": "https://www.microsoft.com/en-us/microsoft-365/outlook/calendar-app", "privacyPolicyURL": "https://www.microsoft.com/en-us/privacy/privacystatement", "termsOfServiceURL": "https://www.microsoft.com/en-us/servicesagreement/", - "defaultPrompt": [ - "Compare availability, propose right event update" - ], + "defaultPrompt": "Use Outlook Calendar to summarize my day, compare availability, explain Outlook meeting status, and draft the right event update, including Teams details when needed.", "brandColor": "#0078D4", "composerIcon": "./assets/outlook-calendar-small.svg", "logo": "./assets/outlook-calendar.svg", diff --git a/plugins/outlook-calendar/skills/outlook-calendar-daily-brief/SKILL.md b/plugins/outlook-calendar/skills/outlook-calendar-daily-brief/SKILL.md index 6fe92a61..d376a45f 100644 --- a/plugins/outlook-calendar/skills/outlook-calendar-daily-brief/SKILL.md +++ b/plugins/outlook-calendar/skills/outlook-calendar-daily-brief/SKILL.md @@ -16,14 +16,59 @@ Use this skill to turn one day of Outlook Calendar events into a readable brief ## Workflow 1. Resolve the day window explicitly in the user's mailbox timezone if it is known, otherwise in the user's stated timezone. -2. Read the day's events from the intended calendar. Default to the primary calendar unless the user names a shared calendar. -3. Separate real meetings from lightweight holds, travel buffers, or transparent blocks before writing the brief. -4. Call out overlaps, compressed transitions, overloaded stretches, and any meaningful remaining free windows. -5. Return a brief that reads like a schedule understanding aid, not a raw connector dump. +2. Use the Outlook Calendar connector's `list_events` action for the day window and relevant calendar. Default to the primary personal calendar unless the user names a different one. +3. Build the brief around the actual workday shape, not just a chronological list. +4. Separate real meetings from lightweight holds, travel buffers, or transparent blocks before writing the brief. +5. Distinguish true busy time from `Tentative`, `Free`, `Out of Office`, or `Working Elsewhere` blocks when the source data exposes those statuses. +6. If the day has meaningful work-location or out-of-office context, mention it near the top because Outlook users often use that information to interpret the schedule. +7. Call out overlaps, compressed transitions, overloaded stretches, and any meaningful remaining free windows. +8. When shared-calendar visibility is partial, say that clearly instead of implying the agenda is complete. +9. Return a brief that reads like a schedule understanding aid, not a raw connector dump. -## Output Conventions +## Data Source Rules -- Lead with a compact readout of how heavy or fragmented the day looks. -- Include `Agenda` and a short `What Needs Attention` section when conflicts or thin buffers exist. -- Use exact weekday, date, time, and timezone for every event block. -- Keep the brief compact and practical. Do not expose raw Outlook IDs or raw connector payload fields. +- Use the Outlook Calendar connector from this plugin, not web search and not a manually reconstructed schedule. +- Query with explicit day boundaries such as `[local_midnight, next_local_midnight)` in the user's timezone. +- Preserve titles exactly as returned by Outlook Calendar. +- If the connector only exposes busy windows for a calendar, build the brief around availability patterns and say that event-level detail was not available. + +## Output Contract + +Render the brief in this order: + +1. `**Weekday, Month Day**` +2. Up to four short summary lines with restrained markers: + - `๐Ÿ“` day marker such as office / travel / PTO when the source data supports it + - `โš ` conflict-zone count + - `๐Ÿฝ` lunch-window note when useful + - `๐ŸŸข` best free windows +3. `**Day Shape**` paragraph +4. `**Agenda**` Markdown table with columns `Time | Meeting` +5. `**What Needs Attention**` only when there are conflicts, dense handoffs, or unusual Outlook-status ambiguity +6. `**Useful Readout**` with 2-4 short bullets +7. `**Remaining Today**` only when the requested day is today and there are future events left + +Keep the tone compact and practical. Do not use a fenced code block for the agenda. + +## Formatting Rules + +- Keep markers restrained. Use only the markers in the output contract unless the user explicitly asks for more decoration. +- Keep the agenda table to two columns only: `Time` and `Meeting`. +- Use compact agenda times and include the timezone in the section header or summary, not on every row. +- Treat all-day status markers such as PTO or OOF as context even when they are not meetings. +- When the source data includes Outlook status, mention it only when it changes the user's real availability. +- Mention work-location or building context only when it affects meeting logistics or how the day should be interpreted. +- Keep overlap explanations in `What Needs Attention`, not inline in every agenda row. +- If the day contains only tentative holds or shared-calendar busy markers, say that plainly. +- If the user is asking about `today`, emphasize what is still upcoming and what may require prep. +- If the user is asking about a future day, emphasize density, conflict zones, large open blocks, and unusual holds. + +## Outlook-Specific Notes + +- `Working Elsewhere` and `Free` should not be treated as the same thing as a hard busy meeting. +- `Tentative` often means the slot may still be usable, but only if the user accepts that ambiguity. +- Shared calendars may expose only free/busy signals, not full titles or notes. + +## Fallback + +If the Outlook Calendar connector is unavailable or returns no events unexpectedly, say that Microsoft Outlook access may be unavailable or scoped to the wrong calendar and ask the user to reconnect or clarify the intended calendar. diff --git a/plugins/outlook-calendar/skills/outlook-calendar-free-up-time/SKILL.md b/plugins/outlook-calendar/skills/outlook-calendar-free-up-time/SKILL.md index 573d3437..9aba3d5e 100644 --- a/plugins/outlook-calendar/skills/outlook-calendar-free-up-time/SKILL.md +++ b/plugins/outlook-calendar/skills/outlook-calendar-free-up-time/SKILL.md @@ -17,12 +17,24 @@ Use this skill when the goal is to create time, not just inspect time. ## Workflow -1. Start with the target block: today, tomorrow, this afternoon, a specific date, or a broader window. +1. Start by identifying the target: today, tomorrow, this afternoon, a specific day, or a broader window. 2. Optimize for contiguous free blocks, not raw free-minute totals. -3. Identify what is fixed versus movable before proposing edits. -4. Prefer the smallest edit set that creates a meaningful uninterrupted block. -5. For shared meetings, do not treat a gap on the user's calendar as sufficient proof that a move works. Verify attendee availability or mark the suggestion as best-effort. -6. If no clean block exists, return the best partial win and the tradeoff it requires. +3. Identify which meetings are likely fixed and which are more movable before proposing changes. +4. Look for the smallest edit set that creates a meaningful uninterrupted block. +5. Prefer solutions that reduce fragmentation across the rest of the day, not just one local gap. +6. Treat `Tentative`, `Free`, self-created placeholders, and lightly attended internal holds as lower-cost candidates than hard external meetings, accepted commitments, or `Out of Office` blocks. +7. When work hours or work location are relevant, prefer openings that produce a useful block inside the user's actual workday. +8. If no clean block exists, show the best partial win and what tradeoff it requires. + +## Prioritization Heuristics + +- Protect hard anchors such as external meetings, major reviews, commute buffers, and stable lunch windows. +- Move lower-cost meetings first, such as tentative holds, lightweight internal syncs, or self-created placeholders. +- When two meetings are similarly movable, prefer moving a 1:1 over a larger group meeting because it creates less attendee thrash. +- Favor one or two coherent shifts over a chain of many tiny moves. +- Prefer creating one useful block over scattering a few small openings. +- Preserve existing Teams links and attendee lists unless the user wants to change them. +- If a meeting has weak attendee commitment, interpret that in context rather than as a blanket signal. Far-future weak commitment is normal; imminent weak commitment is a much stronger sign that the meeting may be movable or unstable. ## Output Conventions diff --git a/plugins/outlook-calendar/skills/outlook-calendar-group-scheduler/SKILL.md b/plugins/outlook-calendar/skills/outlook-calendar-group-scheduler/SKILL.md index c9c88941..5ccd1fea 100644 --- a/plugins/outlook-calendar/skills/outlook-calendar-group-scheduler/SKILL.md +++ b/plugins/outlook-calendar/skills/outlook-calendar-group-scheduler/SKILL.md @@ -14,14 +14,32 @@ Use this skill when the scheduling problem is the task. - Use `search_events` or `list_events` when you need conflict context before ranking options. - Use `create_event` only after the winning slot and attendee set are settled. +## Outlook Product Framing + +- Treat free/busy visibility, work hours, and work location as first-class scheduling evidence when full event detail is unavailable. +- Treat attendee response state and organizer logistics as part of scheduling, not just the final event body. +- When rooms or resources are visible, treat them as Outlook-style scheduling constraints rather than a separate "room finder" workflow. + ## Workflow -1. Ground the request first: date window, duration, timezone, required attendees, optional attendees, and hard constraints. -2. Normalize the request into explicit candidate windows before ranking anything. -3. Rank slots, do not enumerate everything. -4. Prefer slots that minimize conflict cost, are fair across timezones, and avoid splitting up the constrained attendees' only large free blocks. -5. If no perfect slot exists, return the best compromise and state exactly who is impacted. -6. If the meeting also needs a room or resource, shortlist attendee-compatible times first, then check the resource schedule against those times. +1. Ground the scheduling problem first: date window, duration, timezone, required attendees, optional attendees, and any hard constraints such as "this week", "afternoons only", or "avoid lunch". +2. If the scheduling window is ambiguous, assess the meeting stakes before choosing a default search window. For relatively high-stakes meetings, go back to the user and suggest tightening the timeline, for example to the next week. For lower-stakes or more casual group scheduling, default to a near-term search such as the next 1 to 3 weeks. +3. Normalize the request into explicit candidate windows before ranking anything. +4. Rank slots, do not enumerate everything. Optimize for a short list of strong options. +5. Treat `Busy` and `Out of Office` as harder constraints than `Tentative` or `Working Elsewhere` unless the user says otherwise. +6. Prefer slots that minimize conflict cost, fit within work hours, and avoid avoidable hybrid-work friction such as forcing an in-office room meeting onto remote-heavy attendees. +7. When rooms, resources, or building context are available, prefer slots that keep the meeting logistically coherent instead of treating time as the only variable. +8. If shared-calendar visibility is partial, say when a recommendation is based on free/busy signals rather than full event detail. + +## Ranking Heuristics + +- Favor required-attendee fit over optional-attendee fit. +- Favor slots that avoid very early or very late local times for distributed attendees. +- Favor slots that stay inside work hours and avoid consuming the only large free block in someone's day unless the meeting is clearly important. +- Favor a small number of high-confidence options over a long weak list. +- When two slots are similar, prefer the one that causes less calendar fragmentation. +- When one attendee is only `Tentative` or `Working Elsewhere`, describe that as a softer constraint instead of silently treating it as unavailable. +- When one option aligns better with attendees' work locations or room logistics, explain that advantage explicitly. ## Output Conventions diff --git a/plugins/outlook-calendar/skills/outlook-calendar-meeting-prep/SKILL.md b/plugins/outlook-calendar/skills/outlook-calendar-meeting-prep/SKILL.md index 07a1d2d4..03110319 100644 --- a/plugins/outlook-calendar/skills/outlook-calendar-meeting-prep/SKILL.md +++ b/plugins/outlook-calendar/skills/outlook-calendar-meeting-prep/SKILL.md @@ -15,11 +15,15 @@ Use this skill when the user wants a prep brief, not just the event details. ## Workflow -1. Start from the event itself: title, body, attendees, recurrence context, location, and any obvious linked materials. -2. If the event points to related emails, docs, decks, or notes and they are cheap to follow, inspect them before writing the brief. -3. Build the brief around what the meeting appears to be for, what decisions or inputs seem likely, and what context is attached versus missing. +1. Start from the event itself: title, description, attendees, response state, recurrence context, Teams details, and any obvious linked materials. +2. If the event points to connected docs, decks, threads, or notes and they are cheap to follow, inspect them before writing the brief. +3. Build the prep brief around what the meeting appears to be for, what decisions or inputs seem likely, and what context is attached versus missing. 4. Highlight what the user should read or prepare first rather than dumping every detail. -5. Stay close to the event and its linked Microsoft context. Do broader research only if the user explicitly asks for it. +5. Stay close to the event and its linked context. Do broader research only if the user explicitly asks for it. +6. If the event comes from a shared calendar with limited detail, say what is confirmed versus what remains opaque. +7. If context gathering, note lookup, or related-event retrieval takes more than 5 minutes, recheck that the target meeting is still upcoming before updating the invite or presenting it as the next meeting. +8. If you write back into the Outlook event description, keep it short: usually one concise agenda block and, at most, one short prep block rather than a long meeting brief. +9. Preserve the event's existing body format when editing. If the event already uses plain text, keep the update plain text unless richer structure is necessary. If you are creating new formatted content with bullets or links, use HTML deliberately rather than mixing rich structure into plain text. ## Output Conventions @@ -27,3 +31,19 @@ Use this skill when the user wants a prep brief, not just the event details. - Call out the most relevant notes, emails, or linked docs. - Separate confirmed context from missing context or open questions. - End with a short `What To Do Before This Meeting` list when the evidence supports it. + +## Outlook-Specific Focus + +- Call out whether attendees have accepted, tentatively accepted, declined, or not responded when that changes the prep picture. +- Mention the presence of a Teams meeting link, room resource, or organizer note when those shape logistics. +- Treat organizer notes, response tracking, and last-minute RSVP drift as part of the meeting story, because Outlook users often rely on the invitation itself as the operational source of truth. +- Separate confirmed context from inferred context, especially when the event description is sparse. + +## Output Conventions + +- Lead with what this meeting appears to be about. +- Call out the most relevant notes, attachments, links, or Teams details. +- Separate confirmed context from missing context or open questions. +- End with a short "what to do before this meeting" list when there is enough evidence to support it. +- If updating the invite body, compress the brief aggressively so the description stays readable inside Outlook without scrolling through a long memo. +- If the original invite body already has formatting conventions, match them rather than switching formats midstream. diff --git a/plugins/outlook-calendar/skills/outlook-calendar/SKILL.md b/plugins/outlook-calendar/skills/outlook-calendar/SKILL.md index d4d8ed7b..c74014c4 100644 --- a/plugins/outlook-calendar/skills/outlook-calendar/SKILL.md +++ b/plugins/outlook-calendar/skills/outlook-calendar/SKILL.md @@ -7,7 +7,20 @@ description: Handle Outlook Calendar workflows. Use when the user asks for sched ## Overview -Use this skill to turn Outlook Calendar data into clear scheduling decisions and safe event updates. Favor exact dates, times, attendees, and timezone-aware details over vague time language. +Use this skill to turn raw Outlook Calendar data into clear scheduling decisions and safe event updates. Favor exact dates, times, attendee details, and calendar evidence over ambiguous natural-language plans. + +If recurrence scope or cadence matters, consult `resources/recurring-meetings.md` before proposing a recurring change. +If a request depends on flights, commute blocks, airport timing, or in-person travel logistics, consult `resources/travel-coordination.md` before proposing a change. +If a request depends on prep alerts, meeting reminder timing, or deciding which meetings deserve reminders, consult `resources/reminder-planning.md` before proposing a change. +If a request depends on proposing candidate times, checking when the user is free, or placing a temporary hold, consult `resources/availability-response.md` before proposing a change. + +## Specialized Skills + +- For one-day schedule understanding and agenda readouts, prefer [outlook-calendar-daily-brief](../outlook-calendar-daily-brief/SKILL.md). +- For creating a meaningful focus block through intelligent moves, prefer [outlook-calendar-free-up-time](../outlook-calendar-free-up-time/SKILL.md). +- For ranking the best group meeting options, prefer [outlook-calendar-group-scheduler](../outlook-calendar-group-scheduler/SKILL.md). +- For meeting prep briefs grounded in the event and nearby Microsoft context, prefer [outlook-calendar-meeting-prep](../outlook-calendar-meeting-prep/SKILL.md). +- Keep reminder planning, RSVP replies, recurring-series maintenance, travel-aware scheduling, and deadline planning in this base Outlook skill. Use this base skill when the request spans multiple Outlook calendar workflows or when no more focused Outlook calendar skill is a better fit. @@ -21,88 +34,112 @@ Use this base skill when the request spans multiple Outlook calendar workflows o ## Preferred Deliverables -- Availability summaries with exact candidate slots, timezone, and relevant conflicts. -- Event change proposals that show the current event details and the intended update. -- Reschedule proposals that show the current event, one to three exact replacement slots, and whether attendee availability was verified or remains unverified. +- Availability summaries with exact candidate slots, timezone, and conflicts. +- Event change proposals that show the current event and the intended update. +- Shared-calendar summaries that explain when Outlook is showing free/busy only versus full event detail. +- Meeting-status explanations that decode Outlook concepts such as `Busy`, `Tentative`, `Free`, `Out of Office`, and `Working Elsewhere`. +- Meeting-readiness summaries that incorporate attendee response state, organizer intent, and whether a Teams link, room, or work-location detail already exists. - Final event details that are ready to create, reschedule, or cancel after confirmation. - Meeting-note drafts that are phrased as shared, meeting-ready agenda or prep bullets rather than assistant-facing analysis. - Reminder or deadline plans that make clear whether the outcome is an Outlook event reminder, a calendar hold, an invite response, or a separate automation. ## Workflow -1. Read current calendar state first. Gather the relevant calendars, time window, attendees, timezone, and any existing event details before proposing changes. -2. Normalize relative time language into explicit dates, times, and timezone-aware ranges. -3. Normalize timezone representation before proposing or applying changes. Determine the user's effective mailbox timezone and the event-local timezone that the Outlook connector expects, and do not assume IANA timezone names can be passed through unchanged. -4. For cross-timezone requests such as travel, flights, trains, or events tied to a different city, interpret each stated local time in the timezone of the city where that timestamp occurs before converting it into the Outlook event payload. -5. Surface conflicts before edits. Call out overlapping events, missing attendee details, or other constraints before proposing a create or update. -6. When the request is ambiguous, summarize the best options before drafting an event change. -7. Treat missing title, attendees, location, meeting link, or timezone as confirmation points rather than assumptions. -8. When the request asks for "relevant docs", "background docs", "past notes", or similar meeting context, treat document retrieval as part of the required read path before drafting invite content. -9. For document retrieval across Microsoft surfaces, use the actual connector/tool surfaces directly: - - Outlook mail context: use the Outlook Email app tools. - - SharePoint or OneDrive docs: use the Microsoft SharePoint app tools such as `search`, `list_recent_documents`, and `fetch`. - - Do not use generic MCP resource discovery such as `list_mcp_resources` to discover SharePoint content for this workflow. -10. If a SharePoint search is relevant but no specific site or path is known, search by short participant/project keywords first, then fetch the best candidate documents before summarizing. -11. For reschedules where the user did not specify the destination time, propose one to three exact replacement slots and get confirmation on the chosen slot before moving the event. -12. Check attendee availability before rescheduling when the connector can do so. If recipient availability cannot be verified, say that explicitly and treat any move as best-effort rather than silently assuming the slot works. -13. Only create, update, move, or cancel events when the user has clearly asked for that action or confirmed the exact event details. -14. When changing multiple Outlook events in one turn, prefer direct sequential Outlook tool calls unless the batch or parallel wrapper has already been validated in-session for that exact tool surface. -15. Treat invite-note edits as content edits, not just calendar edits. Before writing synthesized notes, derive the exact text to be inserted and check that it reads like content intended for invite attendees rather than a summary back to the user. -16. When the user asks to "look up context and add a summary" to an invite, first collect the source material and then decide whether the write can be safely applied without confirmation: - - Safe to apply directly only when the inserted text is short, source-grounded, and phrased as a neutral agenda, decisions, open questions, or next steps section. - - If the inserted text requires substantive synthesis, interpretation, prioritization, or tone choices, show the exact proposed note to the user before applying it. -17. For meeting-prep writes, prefer updating the body with a concise agenda or discussion focus section over a generic "summary" unless the existing invite already uses a summary style. -18. If multiple information surfaces are available, prefer this retrieval order for meeting prep unless the user names a specific source: current event body, prior related event bodies, Outlook Email, SharePoint/OneDrive docs, then lower-signal notes sources. -19. Before any create or reschedule write, restate the final interpreted weekday, date, local clock time, and timezone for the event. If the task spans multiple cities or time zones, restate each relevant timestamp separately. +### Grounding + +1. Read mailbox profile context first when available so the request is grounded in the signed-in identity, locale, timezone, and default calendar assumptions. +2. Resolve calendar scope before reasoning. If multiple calendars are available, identify the intended one explicitly and prefer the default personal calendar unless the user names a shared, delegated, team, or resource calendar. +3. Read current calendar state first. Gather the relevant events, time window, attendee responses, and any existing event IDs before proposing changes. +4. Normalize all time language. Convert phrases like `tomorrow morning` or `next Tuesday` into explicit dates, times, and timezone-aware ranges. + +### Scheduling Reasoning + +5. Surface conflicts before edits. Call out overlapping events, travel gaps, double bookings, overload, and missing meeting details before suggesting a create or update. +6. Start from Outlook scheduling surfaces, not generic calendar abstractions. Account for attendee response state, organizer vs attendee role, shared-calendar visibility, work hours, work location, and room or resource context when available. +7. When the request depends on workday norms, prefer Outlook-native cues such as work hours, location plans, and partial free/busy visibility over generic assumptions about what counts as open work time. +8. Treat recurring meetings carefully. Determine whether the user means one occurrence, future instances, or the whole series, and if the scope is not explicit or not verifiable from the tool output, stop and confirm before editing. +9. Treat prompts about past meetings as retrospective by default. Analyze what happened and propose future scheduling changes unless the user explicitly asks to edit or annotate past events. + +### Confirmation and Writes + +12. When the request is ambiguous, summarize the scheduling options or the exact event diff before writing anything. +13. Treat missing title, attendees, location, Teams link, or timezone as confirmation points rather than assumptions. +14. For reschedules where the user did not specify the destination time, propose one to three exact replacement slots and get confirmation on the chosen slot before moving the event. +15. Check attendee availability before rescheduling when the connector can do so. If recipient availability cannot be verified, say that explicitly and treat any move as best-effort rather than silently assuming the slot works. +16. When notes, Teams links, rooms, or missing details matter, inspect the event payload before proposing a change and say when the source data appears partial. +17. For meeting-prep or invite-note requests, collect the relevant source material first, then decide whether the write is short and grounded enough to apply directly or should be shown for confirmation first. +18. Before any create or reschedule write, restate the final interpreted weekday, date, local clock time, and timezone for the event. If the task spans multiple cities or time zones, restate each relevant timestamp separately. +19. Only create, update, move, or cancel events when the user has clearly asked for that action or confirmed the exact details. + +## Read Path + +- Use `list_events` as the default tool for bounded calendar reads when the user is asking about a specific day, week, or date window. +- Prefer an explicit time window with both `start_datetime` and `end_datetime` instead of an unbounded fetch whenever the user intent is tied to a concrete range such as today, tomorrow, next week, or the next 3 days. +- Normalize relative ranges into exact ISO-8601 timestamps with an explicit UTC offset before calling `list_events`. +- Use the default event shape for ordinary schedule review. Only narrow fields if the task truly needs a smaller payload and the connector contract for that field set is known to be safe. +- Use `search_events` when the user is trying to find a meeting by phrase, attendee, or event title rather than asking for a simple time-window read. +- Use `fetch_event` after discovery when one concrete event needs deeper inspection before editing. +- If multiple information surfaces are available for meeting prep, prefer this retrieval order unless the user names a specific source: current event body, prior related event bodies, Outlook Email, SharePoint or OneDrive docs, then lower-signal notes sources. +- For document retrieval across Microsoft surfaces, use the actual connector or tool surfaces directly: + - Outlook mail context: use the Outlook Email app tools. + - SharePoint or OneDrive docs: use the Microsoft SharePoint app tools such as `search`, `list_recent_documents`, and `fetch`. + - Do not use generic MCP resource discovery such as `list_mcp_resources` to discover SharePoint content for this workflow. + +## Outlook-Specific Checks + +- Distinguish true busy time from softer constraints such as `Tentative`, `Free`, `Out of Office`, or `Working Elsewhere`. +- If the source data includes attendee response state, organizer role, Teams details, room booking, or work-location context, preserve those details unless the user asked to change them. +- Shared calendars may expose only free/busy signals rather than full event details. Say that directly instead of implying the view is complete. +- If a slot is free only because another item is marked `Free` or `Working Elsewhere`, describe that nuance. +- If a meeting is online, preserve the existing Teams or online-meeting setup unless the user asks to change it. ## Write Safety -- Preserve event titles, attendees, start and end times, locations, meeting links, and notes from the source data unless the user requests a change. -- Confirm the final timezone before creating or rescheduling an event. Do not rely on a default timezone when the request mentions a city, airport, travel leg, local departure time, local arrival time, or another timezone-sensitive context. -- Treat deletes, cancellations, and broad schedule changes as high-impact actions. Restate the affected event before applying them. -- For reschedules, do not treat an open slot on the user's calendar as sufficient proof that the meeting can be moved there. Either verify attendee availability or obtain user confirmation that a best-effort move is acceptable. -- When a user asks to "move," "reschedule," or "push" a meeting without naming the new time, do not pick a replacement slot unilaterally. Present exact options first unless the user explicitly delegated slot selection. -- If a batch or parallel wrapper returns tool-dispatch errors such as `unsupported call`, do not keep retrying the wrapper blindly. Fall back to the direct Outlook calendar tool surface, apply edits sequentially, and note the limitation in the response. +- Preserve exact event titles, attendees, start and end times, locations, Teams or online-meeting details, reminders, and notes from the source data unless the user requests a change. +- Preserve the original invite body format when editing. If the existing event body is plain text, keep the update plain text unless the user explicitly wants richer formatting. If the existing body is HTML, preserve HTML structure instead of flattening it into text. +- Keep Outlook event descriptions brief by default. Unless the user explicitly asks for a detailed write-up, limit description updates to at most one or two short blocks or paragraphs of operationally useful content. +- When creating invite content from scratch, prefer plain text for short linear notes and use HTML only when the content needs real structure such as bullets, links, or clearly separated sections. +- Do not write attendee-facing invite notes that include assistant provenance or meta commentary. +- When source material is incomplete or unverified, omit the uncertain item, label it as a question for the meeting, or present a draft for confirmation. +- Treat deletes and broad availability changes as high-impact actions. Restate the affected event or calendar before applying them. - If multiple calendars or similarly named events are in play, identify the intended one explicitly before editing. -- If the request references relative dates like "tomorrow afternoon," restate the exact interpreted date, time, and timezone before drafting the change. -- Preserve the original timezone semantics of the source event unless the user asked to change them. When moving an event, distinguish between "same local clock time in a different timezone" and "same absolute instant converted into another timezone." +- For cross-timezone requests such as travel, flights, or events tied to a different city, interpret each stated local time in the timezone of the city where that timestamp occurs before converting it into the Outlook event payload. - Treat Outlook timezone names as a required formatting step. Convert from user-facing timezone references such as cities, offsets, abbreviations, or IANA names into the Outlook-compatible timezone expected by the connector before writing. -- For travel and cross-timezone tasks, never compute departure and arrival times in a single timezone. Departure timestamps must stay anchored to the departure city's local timezone, and arrival timestamps must stay anchored to the arrival city's local timezone until after interpretation. - If a cross-timezone request leaves any timestamp interpretation ambiguous, stop and ask rather than silently choosing one timezone basis. -- Do not write attendee-facing invite notes that include assistant provenance or meta commentary such as "source quality," "context found in Outlook," "I found," or similar narration about the research process. -- Do not write invite notes in a user-briefing voice. Avoid language that reads like a report to the requester instead of shared meeting content. -- Avoid third-person framing that makes one attendee sound like the subject of analysis when a neutral, shared meeting framing is available. Prefer "Discussion topics," "Open items," "Agenda," or direct issue statements over sentences centered on "Ari said..." unless quoting or attribution is materially necessary. -- When source material is incomplete or unverified, omit the uncertain item, label it as a question for the meeting, or present a draft for confirmation. Do not silently convert uncertain context into asserted meeting notes. -- If prior notes or documents are missing, do not mention that absence inside the invite body unless the user explicitly wants an audit trail in the invite itself. -- If SharePoint retrieval is requested or strongly implied by "relevant docs," do not stop after a failed discovery attempt on a non-SharePoint surface. Re-route to the Microsoft SharePoint connector path or state clearly that the SharePoint connector itself is unavailable. -- Treat tool-surface selection errors separately from content absence. A failed connector-discovery step does not justify concluding that no relevant SharePoint docs exist. + +## Product Terminology + +- Translate Outlook-native terms into plain language when they matter to the task, and briefly note when a term may be ambiguous across products. +- In Outlook Calendar, `reminder` normally means the built-in pre-meeting or pre-event alert on the calendar event itself, not a separate task or Apple Reminders item. +- If the user says `reminder` while clearly working inside Outlook Calendar, default to the Outlook event alert meaning, but say so briefly when the distinction could matter. +- If the phrasing could reasonably mean either an Outlook event alert or a separate task-style reminder, acknowledge the ambiguity and clarify which meaning you are using before writing. +- Treat `event body`, `description`, `invite notes`, and `meeting notes in the event` as closely related Outlook concepts, but preserve the actual event body rather than inventing a separate notes surface. +- Treat `Teams link`, `online meeting`, and `join info` as logistics attached to the event, and preserve them unless the user explicitly wants them changed. +- Treat `tentative`, `busy`, `free`, `out of office`, and `working elsewhere` as Outlook availability states, not casual prose, and explain them in user language when they affect the recommendation. ## Output Conventions - Present scheduling summaries with exact weekday, date, time, and timezone. - When a task spans multiple time zones, label every timestamp with its local timezone rather than collapsing them into a single timezone summary. - When sharing availability, explain why a slot works or conflicts instead of listing raw times without context. -- When proposing a new or updated event, format the response as title, attendees, start, end, timezone, location or meeting link, and purpose. +- When Outlook status matters, translate it into user language, such as tentative hold, true busy, out of office, working elsewhere, or visible only as shared-calendar busy time. +- When attendee responses matter, name them directly instead of flattening everything into available or unavailable. +- When proposing a new or updated event, format the response as title, attendees, start, end, timezone, location or Teams link, status if relevant, and purpose. - Keep option lists short and explain the tradeoff for each candidate slot. - When reporting conflicts, name the overlapping events and how much time is affected. - When a workflow turns into a reminder, RSVP, recurring-series, or travel-buffer task, say explicitly which Outlook action or follow-up path is being used rather than presenting it as a generic edit. +- When comparing options, keep the list short and explain the tradeoff for each slot. +- When the source data is incomplete, say whether the limitation seems to come from shared-calendar permissions or missing meeting metadata. +- For retrospective schedule prompts, separate `What happened` from `What to change next time` so the user gets analysis even when no safe write should occur. - For invite-note drafts, prefer a compact structure such as `Agenda`, `Open items`, `Decisions needed`, or `Next steps`. -- Meeting-note text should be concrete and low-drama. Avoid headings like `Prep summary` unless the user asked for that exact label. -- If the note is synthesized from multiple artifacts, collapse the synthesis into meeting-ready bullets rather than exposing the retrieval path or evidentiary narrative. -- When summarizing retrieved prep context back to the user before a write, separate findings by source, for example `Calendar`, `Email`, and `SharePoint docs`, so it is clear which Microsoft surfaces were actually checked. - -## Access Notes - -- In this environment, SharePoint access for document retrieval comes from the Microsoft SharePoint app tools, not from MCP resource listing. -- If app-tool discovery is needed, use the app/tool discovery path that exposes `mcp__codex_apps__microsoft-sharepoint` tools. Do not assume a server named `sharepoint` exists for `list_mcp_resources`. -- If a wrapper cannot dispatch discovery correctly, fall back to direct SharePoint app-tool calls once the tool surface is available rather than abandoning SharePoint retrieval. -- Outlook connector writes may expect mailbox/Windows timezone names rather than IANA timezone names. Treat timezone conversion as part of write preparation, not as an optional display concern. +- Prefer short Outlook-style descriptions over memo-like notes. The default target is one concise agenda block plus, at most, one short prep block. ## Example Requests - "Check my Outlook Calendar availability this Thursday afternoon and suggest the best two meeting slots." - "Move the project review to next week and keep the same attendees and Teams link." -- "Summarize my calendar for tomorrow and flag anything that overlaps." +- "Summarize my calendar for tomorrow, including which holds are only tentative." +- "Go through yesterday's meetings and tell me how I should schedule similar meetings next time to reduce context switching." - "Draft the exact event details for a 30 minute sync with the vendor at 2 PM Pacific on Friday." - "Help me decide whether to accept this invite, decline it, or propose a better time." - "Clean up this recurring staff meeting without breaking the whole series." @@ -110,4 +147,4 @@ Use this base skill when the request spans multiple Outlook calendar workflows o ## Light Fallback -If Outlook Calendar data is missing or incomplete, say that Microsoft Outlook access may be unavailable or pointed at the wrong calendar, then ask the user to reconnect or clarify the intended calendar or event. +If Outlook Calendar data is missing or the connector does not return the expected events, say that Microsoft Outlook access may be unavailable or pointed at the wrong calendar and ask the user to reconnect or clarify which calendar should be used. diff --git a/plugins/outlook-calendar/skills/outlook-calendar/agents/openai.yaml b/plugins/outlook-calendar/skills/outlook-calendar/agents/openai.yaml index cc4faa1e..41829618 100644 --- a/plugins/outlook-calendar/skills/outlook-calendar/agents/openai.yaml +++ b/plugins/outlook-calendar/skills/outlook-calendar/agents/openai.yaml @@ -1,7 +1,7 @@ interface: display_name: "Outlook Calendar" - short_description: "Compare availability and plan event changes" + short_description: "Find availability and safe Outlook event changes" icon_small: "./assets/outlook-calendar-small.svg" icon_large: "./assets/outlook-calendar.svg" brand_color: "#0078D4" - default_prompt: "Use $outlook-calendar to compare availability, propose the right event update, or help me schedule, reschedule, or cancel a meeting safely." + default_prompt: "Use $outlook-calendar to compare availability, explain Outlook meeting status, or draft the exact event change, including Teams details when relevant." diff --git a/plugins/outlook-calendar/skills/outlook-calendar/resources/availability-response.md b/plugins/outlook-calendar/skills/outlook-calendar/resources/availability-response.md new file mode 100644 index 00000000..38589a71 --- /dev/null +++ b/plugins/outlook-calendar/skills/outlook-calendar/resources/availability-response.md @@ -0,0 +1,28 @@ +# Availability Response + +Use this resource when the user wants Outlook Calendar to propose meeting options, check when they are free, draft a response with candidate times, or place a temporary hold. + +## Defaults + +- For broad availability requests without a stated window, default to a near-term business window. Prefer the current workweek when it still has useful time left, otherwise use the next 7 days. +- For broad availability requests without a stated time of day, prefer business hours from Outlook working-hours data. If Outlook does not expose working hours, use standard weekday business hours that fit the user's locale and work culture rather than early mornings, evenings, or weekends. +- Prefer a short list of strong options over an exhaustive dump of open time. + +## Outlook-Specific Focus + +- Distinguish firm conflicts from softer constraints such as `Tentative`, `Free`, or `Working Elsewhere`. +- If a slot is available only because another item is marked `Free` or `Working Elsewhere`, explain that nuance rather than presenting it as a fully clean opening. +- If the answer depends on partial shared-calendar visibility, say that directly. + +## Temporary Holds and Replies + +- If the user asks for a temporary hold and does not provide a title, use a simple Outlook-style placeholder such as `Temporary hold`. +- If the user asks for a hold and does not provide a narrower search window, choose a reasonable near-term slot using the defaults above rather than stopping for avoidable clarification. +- If drafting a response to send elsewhere, make it directly sendable and keep the wording polished and practical. +- If applying a temporary hold, say whether it is tentative, private, or expected to be removed later. + +## Output Conventions + +- Return 2-3 options by default unless the user asked for more. +- Label each option with exact weekday, date, time, and timezone. +- Say why each slot is good, not just that it is open. diff --git a/plugins/outlook-calendar/skills/outlook-calendar/resources/recurring-meetings.md b/plugins/outlook-calendar/skills/outlook-calendar/resources/recurring-meetings.md new file mode 100644 index 00000000..5cbe6184 --- /dev/null +++ b/plugins/outlook-calendar/skills/outlook-calendar/resources/recurring-meetings.md @@ -0,0 +1,47 @@ +# Recurring Meetings Behavior + +Use this resource when a request depends on recurring-meeting scope, cadence, or workplace norms rather than only the event title and time. + +## Outlook and Graph Semantics + +- Outlook and Microsoft Graph distinguish between a single occurrence, future instances, and the full recurring series. +- Graph event objects can represent `singleInstance`, `occurrence`, `exception`, or `seriesMaster`. +- A recurring meeting may also carry recurrence metadata such as `seriesMasterId`, `recurrence`, and original-start information, but not every connector surface exposes that metadata clearly. +- If the tool output only shows an occurrence-like event and does not expose reliable series-master metadata, treat the read as an instance view rather than a fully trustworthy series view. +- If the user asks to `adjust future instances`, `modify the series`, `skip next week's meeting`, or similar, treat that as a recurrence-scope request rather than a simple one-off event edit. +- If the tool surface cannot prove whether a write is targeting one occurrence, future instances, or the whole series, say so clearly before editing. + +## Outlook Product Expectations + +- Outlook users expect recurring edits to preserve logistics such as the attendee list, Teams meeting details, room booking, organizer intent, and invite-note format unless the user asks to change them. +- Recurring edits are higher risk than one-off edits because they can silently change attendee expectations across many dates. +- `This event`, `the whole series`, and `future meetings` are real Outlook concepts. Use that language directly when clarifying scope. +- If a request sounds series-wide but the connector behaves instance-by-instance, explain that limitation instead of claiming a true series-level update. + +## Workplace Norms + +- Use the person's configured work days and work hours as the default frame for recurring work meetings when Outlook exposes them. +- If work hours are unavailable, default work recurrences to weekdays rather than nights or weekends unless the existing pattern or the user's wording says otherwise. +- Prefer stable recurring slots for standing meetings. Avoid proposing frequent time-of-day drift unless the user is intentionally redesigning the pattern. +- Avoid silently moving work recurrences into Friday late afternoon or outside work hours unless the existing series already uses that pattern or the user asked for it. + +## Cadence Heuristics + +- Prefer weekly for true standing coordination such as team syncs, active project check-ins, or regular 1:1s. +- Prefer biweekly as the lighter default for operational syncs when the user is creating a new recurring work meeting without a clearly stated need for weekly cadence. +- Prefer monthly for reviews, steering meetings, and broader status or planning rituals. +- Avoid suggesting daily recurrence unless the meeting is clearly a standup, incident cadence, or another operational rhythm that truly benefits from daily repetition. +- Treat 1:1s as a special case: longer and more frequent can be reasonable, and consistency usually matters more than aggressive compression. + +## Series Length and Buffers + +- For project-bound recurring meetings, prefer a bounded series when the work has an obvious horizon rather than an indefinite recurrence. +- If the user is optimizing calendars, consider Outlook-native meeting hygiene such as ending recurring meetings a bit early or preserving transition time between them. +- When extending recurring meetings, check whether the longer duration creates repeated conflicts before recommending a series-wide change. + +## Skill Guidance + +- Restate the interpreted recurrence scope before any write: one occurrence, future instances, or whole series. +- If the connector output is missing series-master evidence, explicitly say that recurrence scope is being inferred from the visible occurrence pattern. +- When proposing a recurring change, describe both the current pattern and the intended future pattern. +- If the user's request is under-specified, ask the smallest useful recurrence question instead of a generic scheduling question. diff --git a/plugins/outlook-calendar/skills/outlook-calendar/resources/reminder-planning.md b/plugins/outlook-calendar/skills/outlook-calendar/resources/reminder-planning.md new file mode 100644 index 00000000..6947802d --- /dev/null +++ b/plugins/outlook-calendar/skills/outlook-calendar/resources/reminder-planning.md @@ -0,0 +1,29 @@ +# Reminder Planning + +Use this resource when the user wants Outlook reminders added, adjusted, or recommended for meetings that need prep, deliverables, or presentation readiness. + +## Reminder Read Path + +- Identify which meetings actually warrant reminders: prep-heavy meetings, meetings with deliverables, presentations, external meetings, or anything with required follow-through. +- Read the relevant events before proposing reminders so the reminder plan matches the real meeting timing, attendee context, and the user's role. +- Distinguish routine reminders from elevated reminders. A normal internal sync usually does not need the same lead time as an external presentation or a meeting with deliverables due beforehand. + +## Outlook-Specific Focus + +- In Outlook Calendar, `reminder` normally means the built-in pre-event alert on the event itself rather than a separate to-do item. +- External participants, presenter role, and organizer responsibility are stronger signals than generic meeting-importance labels. +- Reminder timing should reflect Outlook-style operational needs such as joining a Teams call, getting to a room, or finishing prep before the event starts. +- If the event already has useful reminder settings, preserve them unless the user asks to change them. + +## Coordination Rules + +- If the user wants reminders added, restate the event, reminder timing, and whether the reminder should apply to one event or several. +- Group reminder recommendations by why they matter, not just by chronology. +- Use exact lead times such as 15 minutes, 30 minutes, 1 hour, or end of previous workday rather than vague language. +- If several events qualify, keep the list short and prioritize the strongest candidates first. + +## Output Conventions + +- Explain which meetings deserve reminders and why. +- If applying reminders, restate the write scope clearly. +- If the wording could mean either an Outlook event alert or a separate task-style reminder, briefly clarify which meaning is being used before writing. diff --git a/plugins/outlook-calendar/skills/outlook-calendar/resources/travel-coordination.md b/plugins/outlook-calendar/skills/outlook-calendar/resources/travel-coordination.md new file mode 100644 index 00000000..5e6cf042 --- /dev/null +++ b/plugins/outlook-calendar/skills/outlook-calendar/resources/travel-coordination.md @@ -0,0 +1,31 @@ +# Travel Coordination + +Use this resource when Outlook Calendar work depends on physical movement, airport timing, or in-person logistics rather than only meeting duration. + +## Travel Read Path + +- Resolve the travel context first: meeting locations, departure and arrival times, cities, timezone boundaries, and whether the travel block should be public or private. +- Interpret each stated travel time in the local timezone where that timestamp occurs before comparing it to calendar events. +- Read the affected calendar window before proposing any travel buffer or reschedule. +- If the travel request spans multiple cities or airports, keep each local timestamp anchored to the city where it occurs until after interpretation. + +## Outlook-Specific Focus + +- Work location and in-person versus online context matter more here than raw availability. +- Travel buffers should usually protect the user's real day rather than appear as optional notes buried inside another event. +- Hybrid-office days often need explicit before and after commute blocks to keep Outlook availability realistic. +- If the user asks to shift meetings because of travel, restate the travel anchor and the affected meetings before writing. + +## Coordination Rules + +- Add buffer time around in-person meetings, office commutes, and airport travel in a way that reflects how the day is actually used. +- When travel overlaps existing meetings, identify which meetings are fixed versus movable before suggesting changes. +- Preserve privacy expectations for travel events such as flights when the user asks for them to be private. +- If a commute or travel block would create obvious overlap, prefer the minimum set of meeting changes needed rather than broadly reworking the day. + +## Output Conventions + +- Label every travel-related timestamp with its local timezone. +- Show which meetings are affected by the travel constraint. +- If proposing reschedules, explain the minimum set of moves needed. +- If creating new travel events, specify whether they should be private, public, or tentative. diff --git a/plugins/outlook-email/skills/outlook-email-reply-drafting/SKILL.md b/plugins/outlook-email/skills/outlook-email-reply-drafting/SKILL.md index 3e2cb399..98eff78f 100644 --- a/plugins/outlook-email/skills/outlook-email-reply-drafting/SKILL.md +++ b/plugins/outlook-email/skills/outlook-email-reply-drafting/SKILL.md @@ -22,15 +22,13 @@ Use this skill when the reply itself is the task. Read enough mailbox context to 1. Identify the exact source message or thread before drafting. 2. Read the most recent message first, then enough nearby context to understand participants, status, commitments, and tone. 3. Decide whether reply-all is necessary based on shared context, not just recipient count. -4. Fetch the user's profile with `get_profile` before writing any greeting, self-reference, or signature that uses their name. Treat that as the primary source of truth, prefer other first-party profile/contact context only if needed, and ask the user before guessing. -5. Draft the reply in the thread's tone unless the user asks for a deliberate change. -6. If the draft depends on missing facts, produce the best draft you can and list the unresolved details separately. -7. If the user later approves sending, reuse the thread-grounded draft instead of recreating the reply from scratch. +4. Draft the reply in the thread's tone unless the user asks for a deliberate change. +5. If the draft depends on missing facts, produce the best draft you can and list the unresolved details separately. +6. If the user later approves sending, reuse the thread-grounded draft instead of recreating the reply from scratch. ## Safety - Preserve dates, commitments, names, links, and quoted facts unless the user asks to change them. -- Do not infer the user's name from their email address or invent a likely first name. Use `get_profile` first when the reply includes the user's name or signature. - Do not invent availability, approvals, ownership, or promises that are not already established in mailbox context. - Treat reply-all as a deliberate choice. If the audience is ambiguous, explain the safest default. - If the user says "send" but the content still depends on unstated choices, stop and ask the narrowest necessary confirmation question. @@ -38,6 +36,5 @@ Use this skill when the reply itself is the task. Read enough mailbox context to ## Output - Provide a ready-to-send draft with greeting, body, and closing when appropriate. -- When the draft includes the user's name or sign-off, use the real name from `get_profile`. - If important assumptions remain, list them immediately after the draft. - If you are recommending a reply-all decision, say why in one short line. diff --git a/plugins/outlook-email/skills/outlook-email/SKILL.md b/plugins/outlook-email/skills/outlook-email/SKILL.md index 4623d0df..f4c76962 100644 --- a/plugins/outlook-email/skills/outlook-email/SKILL.md +++ b/plugins/outlook-email/skills/outlook-email/SKILL.md @@ -40,19 +40,18 @@ Use this skill to turn Outlook inbox and thread context into clear summaries, ac 1. Read the mailbox or thread before drafting. Capture the subject, participants, latest message, action items, deadlines, and any attachments or links that matter. 2. Summarize first when the thread is long or when the user needs help deciding how to respond. 3. Draft replies with thread continuity. Acknowledge the latest message, preserve the userโ€™s objective, and keep the response grounded in the actual thread. -4. When the reply uses the user's name in a greeting, self-reference, or signature, fetch it from `get_profile` first. Treat that as the primary source of truth, fall back to other first-party profile/contact context only if needed, and ask the user before guessing. -5. If the user asks for a reply but does not explicitly ask to send it, default to a draft. -6. If the user asks you to send, first check whether the reply depends on any unstated facts, preferences, scheduling choices, or bundling decisions. If it does, stop and ask a concise confirmation question or present a draft plus the exact facts that still need confirmation before sending. -7. Do not invent meeting acceptance, availability, commitments, status updates, ownership, or cross-thread summaries unless the user explicitly provided them or the thread itself establishes them. -8. If you create a draft and the user later approves sending that draft, prefer sending or updating the existing draft artifact instead of recreating the same reply from scratch. -9. Avoid orphaned drafts. If you must change send paths after drafting, reuse the draft when possible or explicitly tell the user that a stale draft remains and what you did about it. -10. Separate mailbox analysis from action. Be explicit about whether you are summarizing, drafting, proposing a send, or suggesting triage. -11. Only send, move, archive, delete, or otherwise change Outlook mailbox state when the user has clearly asked for that action. -12. For category-based triage or verification, prefer `list_messages` or mailbox-wide search/list results over `fetch_message`. Treat `fetch_message` category readback as unreliable if it returns `categories: null` after a successful category write. -13. When forwarding via the Outlook connector, pass recipients as structured email-address objects rather than raw strings. If a forward call fails schema validation, inspect the expected recipient shape before retrying. -14. Before forwarding, confirm that the source message match is unique enough for the requested description. If the user refers to "that email" or describes a message indirectly, verify there is exactly one plausible mailbox match or stop and ask. -15. Before forwarding to a named person, confirm that the recipient identity is unique enough in mailbox context. If multiple plausible addresses exist for that person, stop and ask which one to use. -16. If the forward target and source message were inferred from search rather than directly specified by message ID or exact address, say what you matched before sending. +4. If the user asks for a reply but does not explicitly ask to send it, default to a draft. +5. If the user asks you to send, first check whether the reply depends on any unstated facts, preferences, scheduling choices, or bundling decisions. If it does, stop and ask a concise confirmation question or present a draft plus the exact facts that still need confirmation before sending. +6. Do not invent meeting acceptance, availability, commitments, status updates, ownership, or cross-thread summaries unless the user explicitly provided them or the thread itself establishes them. +7. If you create a draft and the user later approves sending that draft, prefer sending or updating the existing draft artifact instead of recreating the same reply from scratch. +8. Avoid orphaned drafts. If you must change send paths after drafting, reuse the draft when possible or explicitly tell the user that a stale draft remains and what you did about it. +9. Separate mailbox analysis from action. Be explicit about whether you are summarizing, drafting, proposing a send, or suggesting triage. +10. Only send, move, archive, delete, or otherwise change Outlook mailbox state when the user has clearly asked for that action. +11. For category-based triage or verification, prefer `list_messages` or mailbox-wide search/list results over `fetch_message`. Treat `fetch_message` category readback as unreliable if it returns `categories: null` after a successful category write. +12. When forwarding via the Outlook connector, pass recipients as structured email-address objects rather than raw strings. If a forward call fails schema validation, inspect the expected recipient shape before retrying. +13. Before forwarding, confirm that the source message match is unique enough for the requested description. If the user refers to "that email" or describes a message indirectly, verify there is exactly one plausible mailbox match or stop and ask. +14. Before forwarding to a named person, confirm that the recipient identity is unique enough in mailbox context. If multiple plausible addresses exist for that person, stop and ask which one to use. +15. If the forward target and source message were inferred from search rather than directly specified by message ID or exact address, say what you matched before sending. ## What Stays In The Base Skill @@ -68,7 +67,6 @@ Keep these workflows in the base Outlook Email skill instead of splitting them f ## Write Safety - Preserve recipients, subject lines, dates, links, and quoted facts from the source thread unless the user asks to change them. -- When drafting or sending a reply, use the user's real name for greetings, self-reference, and signatures. Prefer `get_profile` as the source of truth, fall back to other first-party profile/contact context only if `get_profile` is unavailable, and ask the user before guessing. - Treat send, delete, move, and broad mailbox cleanup actions as explicit operations that require clear user intent. - If multiple threads or similarly named mailboxes are in scope, identify the intended thread before drafting or acting. - If a reply depends on missing facts, provide the draft plus a short list of what still needs confirmation instead of sending. @@ -83,7 +81,6 @@ Keep these workflows in the base Outlook Email skill instead of splitting them f - Lead summaries with the latest status, then list decisions, open questions, and action items. - Keep triage buckets explicit, such as urgent, waiting, needs reply, and FYI, when that helps the user scan faster. - Draft replies should be concise, ready to paste or send, and clearly separated from private notes. -- When a draft includes the user's name or signature, use the real name from `get_profile` rather than inferring from the email address or inventing a likely first name. - When multiple messages matter, reference the sender and timestamp of the message that drives the next action. - If a draft requires follow-up details, list them immediately after the draft. - Before sending, explicitly note any assumptions you checked and any missing facts you asked the user to confirm.