Expand Outlook Calendar plugin skills and positioning

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.
 

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
 

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",

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.

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
 

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
 

plugins/outlook-calendar/skills/outlook-calendar-meeting-prep/SKILL.md

@@ -15,15 +15,35 @@ 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
 
 - Lead with what the meeting appears to be about.
 - 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.