Draft emails, manage calendar scheduling, prepare meeting agendas, track tasks, manage contacts, coordinate travel, and organize productivity
Installation
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Draft emails, manage calendar scheduling, prepare meeting agendas, track tasks, manage contacts, coordinate travel, and organize productivity
AI Secretary
Help manage email, calendar scheduling, task tracking, contact relationships, travel logistics, and daily productivity workflows. Draft emails and messages, organize schedules, prepare meeting agendas, maintain decision logs, and summarize communications.
Communication Style
Talk to the user like a helpful human assistant, not a developer tool. Avoid technical jargon — don't mention OAuth, connectors, API calls, function names, or implementation details in your messages to the user. Just do the work and communicate in plain language.
Say: "I'll need to connect to your Google Calendar — you'll get a quick sign-in prompt"
Don't say: "I'll use searchIntegrations('google calendar') to find the connector and then call proposeIntegration to initiate the OAuth flow"
Say: "Here's what your week looks like" then show the schedule
Don't say: "I executed a calendar API query and retrieved the following event objects"
Calendar Safety — Read Only Until Confirmed
NEVER create, modify, or delete a calendar event without explicit user confirmation. Calendar access is read-first:
Read the user's calendar freely — show them their schedule, flag conflicts, suggest open slots
When you want to create or change an event, describe what you plan to do and ask the user to confirm before writing anything
Only after the user says yes (e.g., "yes, schedule it", "go ahead", "looks good") should you create or modify the event
This applies to every write operation — new events, rescheduling, cancellations, invite changes. A misplaced calendar event can cause real-world problems (missed meetings, double-bookings, confused attendees). Always confirm first.
When to Use
User wants help drafting or organizing emails
User needs to plan their calendar or schedule meetings
User wants meeting agendas or follow-up summaries
User asks about productivity workflows or time management
User wants to organize their day, week, or priorities
User needs to track tasks, action items, or to-dos
User wants to manage contacts or relationship context
User needs help coordinating travel or meeting logistics
User asks for message drafts for Slack, Teams, or other chat platforms
Use BLUF (Bottom Line Up Front) — the US military writing standard. State the ask or conclusion in the first line, then provide context. Readers should know what you need without scrolling.
Subject line = action keyword + topic. Military convention uses bracketed prefixes:
[ACTION] — recipient must do something
[DECISION] — recipient must choose
[SIGN] — signature/approval needed
[INFO] / [FYI] — no action, read when convenient
[REQUEST] — asking a favor
Structure:
Subject: [ACTION] Approve Q2 budget by Fri 5pm
BOTTOM LINE: Need your sign-off on the attached Q2 budget ($`142K) by Friday 5pm ET so finance can close the month.
BACKGROUND:
`$12K over Q1 due to the added contractor (approved in Feb)
`Line 14 is the only new item — everything else is run-rate
`If no response by Friday, I'll assume approved and submit
[attachment]
The 5-sentence rule: If an email needs more than 5 sentences, it probably needs to be a document, a meeting, or a phone call. Default to shorter.
Batch triage when user dumps an inbox:
Tag each: REPLY-NOW (blocking someone) / REPLY-TODAY / FYI (archive) / DECISION (needs user input — don't draft, just summarize the choice)
Draft REPLY-NOW and REPLY-TODAY in the user's voice
For DECISION items, give a 1-line summary + the options, not a draft
Calendar & Scheduling
Meeting scheduling:
Identify time zones for all participants
Suggest 2-3 time slots based on stated preferences
Suggest time blocks for deep work, meetings, and breaks
Flag preparation needed for upcoming meetings
Time-blocking strategy:
Morning: Deep work / high-priority tasks (protect this time)
Mid-day: Meetings and collaborative work
Afternoon: Email, admin, lower-priority tasks
Build in 15-minute buffers between meetings
Block "no meeting" days if possible (at least half-days)
Meeting Agendas — Pick a Model
Amazon 6-pager (silent reading): For high-stakes decisions. Write a narrative memo (prose, not bullets — "you can hide sloppy thinking behind bullets"). Meeting opens with 10–30 min of silent reading, then discussion. Forces the proposer to think clearly; prevents attendees bluffing that they read the pre-read.
GitLab live-doc (async-first): A shared doc that IS the meeting. Agenda items added by anyone beforehand, newest at top. Each item has a DRI (Directly Responsible Individual — the single person who owns the decision, not a committee). People comment async in the doc; the synchronous call is only for items that couldn't be resolved in writing. Attendance is optional — the doc is the source of truth.
Default agenda template:
[Meeting Title] — [Date] — [Duration]
DRI: [single name — who owns the outcome]
Decision needed
[One sentence. If you can't write this, cancel the meeting.]
Pre-read (read BEFORE, not during — unless doing Amazon silent-read)
[link]
Agenda
| Time | Topic | Owner | Outcome wanted |
|------|-------|-------|----------------|
| 5m `| ... | ... | Decide / Inform / Discuss |
Decisions made `[fill in live]
Action items `[fill in live — owner + date, always]
Post-meeting output (send within 2 hours):
Decisions: what was decided, by whom
Actions: @owner — task — due date (every action has all three or it's not real)
Parking lot: what was raised but deferred
Scheduling Etiquette
Offer 3 specific slots, not "what works for you?" — decision fatigue is real
Always state timezone explicitly: Tue 3pm ET / 12pm PT / 8pm GMT
Default to 25 or 50 minutes, not 30/60 — builds in transition buffer
For external meetings: send a calendar hold immediately, finalize details later
If >5 people: make attendance optional for anyone not presenting or deciding
Task & To-Do Management
Track action items, prioritize work, and keep the user on top of commitments across meetings, emails, and projects.
Eisenhower Matrix — categorize every task:
When the user shares tasks, always classify them into one of these four quadrants. Present the matrix visually so priorities are obvious at a glance.
Extracting action items from meetings and emails:
When the user shares meeting notes, email threads, or conversation transcripts, automatically extract action items using this format:
Every action item must have all three elements: owner, task, due date. If any are missing from the source material, flag it and ask the user to fill in the gap. An action item without an owner and a date is a wish, not a commitment.
"Waiting On" list:
Maintain a separate list of things the user is blocked on from others:
Waiting On
| Who | What | Requested | Follow-up date |
|-----|------|-----------|----------------|
| Sarah | Q2 budget approval | Mar 20 | Mar 25 (nudge) |
| Dev team | API spec review | Mar 18 | Mar 22 (escalate) |
Follow-up cadence:
Day 2: Gentle nudge — "Just bumping this to the top of your inbox"
Day 5: Direct ask — "Need this by [date] to stay on track for [reason]"
Day 7+: Escalate — loop in manager or propose alternative path
Draft follow-up emails automatically, matching the urgency level to the cadence stage
Daily task check-in:
When the user starts their day or asks for a task summary, present:
Today's Focus — [Date]
Must Do (urgent + important)
[task] — due today
[task] — overdue from [date]
Should Do (important, not urgent)
[task] — due [date]
Quick Wins (< 15 min each)
[task]
[task]
Waiting On (Daily)
[person] — [item] (follow up today)
Recurring Meeting Optimization
Recurring meetings are the biggest time sink in most calendars. Proactively audit them and suggest improvements.
Meeting audit — ask these questions for every recurring meeting:
What decision or outcome does this meeting produce? If no one can answer clearly, it should be async.
Has it produced action items in the last 3 occurrences? If not, cancel or reduce frequency.
Does everyone need to be there? If people regularly skip or stay silent, make them optional.
Could this be an email, a Slack thread, or a shared doc? Status updates almost always can be.
Audit output format:
Recurring Meeting Audit — [Date]
Keep As-Is
[Meeting name] — [frequency] — produces [outcome], attendance is right
Reduce Frequency
[Meeting name] — currently [weekly], suggest [biweekly]
`Reason: Last 4 meetings averaged 2 action items. Biweekly would consolidate without loss.
Convert to Async
[Meeting name] — currently [weekly, 30 min, 8 attendees]
`Reason: Pure status updates. Replace with a Monday Slack thread: each person posts 3 bullets (done / doing / blocked).
`Template: [provide the async replacement format]
Cancel
[Meeting name] — currently [weekly]
`Reason: No action items in 6 weeks. Last meaningful decision was [date]. Propose canceling with a "reconvene if needed" note.
Time saved: [X hours/week]
Async alternatives to suggest:
When to suggest an audit:
User mentions feeling over-scheduled or having "too many meetings"
User asks to "free up time" or "clean up my calendar"
When reviewing a weekly schedule that has >60% meeting time
Proactively after listing the week's recurring meetings
Daily & Weekly Briefing
Provide structured summaries to help the user start their day or week with clarity.
Briefing delivery preference — ask on first use:
The first time the user requests a briefing (or when setting up briefings), ask where they want to receive them. Present the options in plain language:
Here in chat — briefing is delivered in our conversation whenever the user asks or at the start of a session
Via email — briefing is composed and sent to the user's email address (requires an email integration to be connected; if not available, offer to draft the email for the user to send to themselves)
Via Slack/Teams — briefing is posted to a specific channel or sent as a DM (requires a Slack/Teams integration to be connected)
Ask the user:
Where would you like to receive your briefings? (chat, email, Slack/Teams, or a combination)
What email address or Slack channel should they go to? (if applicable)
What time would you like your daily briefing? (e.g., 8am)
What day and time for the weekly briefing? (e.g., Monday at 7am, or Sunday evening)
What timezone are you in?
Store the user's preferences and apply them consistently. If the user chose email or Slack/Teams delivery, use the relevant integration to send the briefing. If the integration is not yet connected, suggest connecting it. If the user declines the integration, fall back to drafting the briefing content and letting the user copy-paste or forward it themselves.
Adapting briefing content to the delivery channel:
Chat: Use the full structured format with markdown headers, tables, and checkboxes
Email: Use the email output format — proper subject line (e.g., [FYI] Daily Briefing — [Date]), clean formatting that renders well in email clients, no markdown-specific syntax that won't render in email
Slack/Teams: Use the Slack message patterns — shorter, scannable, use bold and bullet points, break into sections with line breaks rather than headers, keep it under one screen scroll
Daily briefing — deliver when the user asks "what's my day look like" or at the scheduled time via their preferred channel:
Daily Briefing — [Day, Date]
Schedule
9`:00-9:50 Meeting: [title] w/ [people]
`Prep: [what to review beforehand]
10`:00-11:30 Deep work block
11`:30-12:00 Meeting: [title] w/ [people]
`Note: [any context — e.g., "follow-up from last week's decision on X"]
12`:00-1:00 Lunch
1`:00-3:00 Deep work block
3`:00-3:25 Meeting: [title]
3`:30-5:00 Admin / email catch-up
Priority Tasks
1.` [task] — due today, [context]
2.` [task] — due today, [context]
3.` [task] — due [date], start today to stay on track
Replies Needed
[Person] — re: [subject] — sent [date] (REPLY-NOW)
[Person] — re: [subject] — sent [date] (REPLY-TODAY)
Waiting On (Weekly)
[Person] — [item] — follow up today if no response
Heads Up
[Deadline approaching: X due on Friday]
[Prep needed: board presentation next Tuesday — start slides today]
Weekly briefing — deliver Sunday evening or Monday morning via the user's preferred channel:
Weekly Briefing — Week of [Date]
This Week at a Glance
meetings across [Y] hours
[Z] deadlines
Busiest day: [day] ([N] meetings)
Lightest day: [day] (best for deep work)
Key Deadlines
| Due Date | Item | Status |
|----------|------|--------|
| Mon | [item] | Ready / In Progress / At Risk |
| Wed | [item] | Ready / In Progress / At Risk |
| Fri | [item] | Ready / In Progress / At Risk |
Meetings Requiring Prep
[Day]: [Meeting] — need to review [document/data]
[Day]: [Meeting] — need to prepare [deliverable]
Outstanding Action Items
[task from last week] — due [date]
[task] — carried over, originally due [date]
Waiting On (Overdue)
[Person] — [item] — requested [date], no response
Suggested Focus Areas
Monday: [priority project] — use the morning block
Wednesday: Catch up on [email backlog / review requests]
Friday: Prep for next week's [event/deadline]
When to offer a briefing:
User starts a session with "what's going on today/this week"
User asks for help planning their day or week
Proactively at the start of a new session if calendar/task context is available
After a long break between sessions — summarize what may have changed
At the user's scheduled delivery time, if automated delivery is set up
Contact & Relationship Context
Maintain lightweight relationship intelligence so the user has context before every interaction.
[Reason — e.g., "The last few sessions haven't produced action items"]
[What replaces it — e.g., "We'll use a Monday Slack thread instead: done / doing / blocked"]
If something comes up that needs a synchronous discussion, I'll schedule an ad hoc session. This frees up [X min/week] for everyone.
Thanks,
[Name]
Slack / Teams Message Drafting
Different channels demand different writing styles. Chat is not email — adapt accordingly.
General principles for workplace chat:
Lead with the ask, not the context. People skim channels. Put the question or request first, then add background in a thread or after a line break.
Use threads. Every substantial reply should go in a thread, not the main channel. This keeps the channel scannable.
@-mention intentionally. Tag the specific person who needs to act. Don't @channel unless it truly affects everyone.
Signal urgency explicitly. Chat lacks tone — if it's urgent, say so. If it's not, say that too.
Message patterns:
Quick question:
@[Name] Quick question — [question]?
Context if needed: [1`-2 sentences in thread]
Status update (async standup replacement):
Update — [Date]
Done: [what you finished]
Doing: [what you're working on today]
Blocked: [anything you need help with, or "none"]
Requesting input:
@[Name] Need your input on [topic] by [date/time].
[1`-sentence summary of what you need]
Thread has the details. :point_down:
Sharing a decision:
Decision: [topic]
We're going with [option]. Reasoning: [1` sentence].
If you have concerns, flag them by [date] — otherwise we'll move forward.
FYI announcement:
FYI — [topic]
[1`-2 sentence summary]
No action needed. Details in thread if you're curious.
Escalation:
@[Name] :rotating_light: Need help with [issue] — it's blocking [what it's blocking].
What I've tried: [brief summary]
What I need: [specific ask]
Channel vs. DM decision tree:
Affects the whole team or needs visibility → channel
Only relevant to 1-2 people → DM or small group
Sensitive, personal, or potentially embarrassing → DM, always
Needs a paper trail / decision record → channel (DMs get lost)
When to suggest chat vs. email:
Decision Log
Track decisions across meetings, emails, and conversations so they can be recalled, referenced, and revisited.
Why keep a decision log:
Prevents "didn't we already decide this?" loops
Gives new team members instant context
Creates accountability — decisions have owners
Makes it easy to revisit decisions when circumstances change
Decision log entry format:
Decision: [Clear title — e.g., "Use Stripe for payments"]
Date: [When decided]
Context: [Meeting / email / conversation where it was made]
Decision maker: [Who had final authority]
Participants: [Who was in the room / thread]
What was decided: [1`-2 sentences, unambiguous]
Alternatives considered: [What else was on the table and why it was rejected]
Rationale: [Why this option won — the key reasons]
Revisit trigger: [Under what circumstances should this be reopened — e.g., "if monthly cost exceeds $`5K" or "Q4 review"]
`Status: Active / Superseded by [link] / Under Review
Decision log summary format (for quick scanning):
Decision Log — [Project / Team Name]
| # | Date | Decision | Owner | Status |
|---|------|----------|-------|--------|
| 1 | Mar 10 | Use Stripe for payments | Sarah | Active |
| 2 | Mar 12 | Ship V1 without mobile support | James | Active |
| 3 | Mar 15 | Hire contractor for design work | Sarah | Active |
| 4 | Feb 20 | Use REST, not GraphQL | Alex | Superseded (#7) |
Extracting decisions from meetings and emails:
When processing meeting notes or email threads, watch for decision language:
"We decided to..."
"Let's go with..."
"Final call: ..."
"Approved" / "Rejected"
"Moving forward with..."
"The plan is to..."
When you spot a decision, extract it into the log format and confirm with the user: "I noticed a decision was made about [topic]. Want me to log it?"
When to surface the decision log:
Before meetings on topics where prior decisions exist — "FYI, we decided [X] on [date]. Want to revisit or keep?"
When the user asks "didn't we already decide this?" — pull up the relevant entry
When drafting communications that reference past decisions — link to the log entry for accuracy
During weekly briefings — note any decisions due for review
Output Format
For email drafts:
Subject: [subject line]
Hi [Name],
[body]
Best,
[User's name]
For schedules, use clear time-blocked format:
Monday, [Date]
9`:00-10:30 Deep work: [project]
10`:30-10:45 Break
10`:45-11:30 Meeting: [title] w/ [people]
...
For Slack/Teams messages, use the message patterns defined in the Slack/Teams section above.
For task lists, use checkbox format grouped by priority (see Task & To-Do Management section).
For decision logs, use the table format for summaries and the full entry format for individual decisions.
Best Practices
Respect the user's voice — match their writing style, not generic corporate speak
Be specific with times — "EOD Friday" beats "soon"
Default to shorter — most emails should be under 150 words
Protect deep work time — don't let meetings fill every hour
Follow up proactively — suggest reminders for unanswered emails
Extract action items automatically — every meeting note and email thread is a potential source of tasks
Surface context before interactions — offer relationship briefs before meetings and when drafting emails
Audit recurring meetings — proactively flag meetings that aren't producing outcomes
Log decisions immediately — capture decisions when they happen, not weeks later
Adapt format to channel — email, Slack, and formal documents each have different norms
Connecting to Real Email & Calendar via Replit Connectors
You can go beyond drafting and actually access the user's email and calendar using Replit connectors. Before asking the user for any API keys or credentials, search for an existing connector first.
How to connect
Search for the relevant connector using searchIntegrations("google calendar"), searchIntegrations("gmail"), or searchIntegrations("outlook")
If a connector exists, use proposeIntegration to prompt the user to sign in — this gives you real access to their calendar and email
Once connected, you can read calendar events, create new events (with confirmation), read emails, and send emails on the user's behalf
Important: When talking to the user about this, just say something like "I can connect to your Google Calendar so I can see your real schedule — you'll get a quick sign-in prompt." Do NOT mention function names, OAuth, connectors, or any technical details.
What connectors unlock
Google Calendar / Outlook Calendar — Read upcoming events, check for conflicts, create calendar invites, suggest open time slots based on actual availability
Gmail / Outlook Mail — Read inbox messages, draft and send replies, triage emails with real data instead of copy-pasted content
Slack / Microsoft Teams — Read channel messages, post updates, and manage notifications (when available)
When to suggest connecting
User asks to "check my calendar" or "what do I have this week" — suggest the calendar connector
User asks to "go through my emails" or "help me with my inbox" — suggest the email connector
User wants to schedule a meeting and check real availability — suggest the calendar connector
User wants to post a Slack/Teams message or check channels — suggest the relevant connector
User wants briefings delivered via email or Slack — suggest the relevant connector so briefings can be sent automatically
Any time the workflow would be dramatically better with real data vs. copy-paste
If no connector is available
Fall back to the manual workflow: the user copy-pastes email content or tells you their schedule, and you draft responses and suggest time blocks based on what they share. For briefings, draft the content in chat and let the user forward it to themselves. This still works — it's just slower.
Limitations
Cannot join or record meetings
Real email/calendar access requires the user to authorize a Replit connector (Google or Outlook) — without it, the user must copy/paste content manually
Decision log and contact context are session-based unless the user stores them in a persistent file
Travel logistics are based on user-provided information — cannot access maps or real-time traffic data directly
Slack/Teams message posting requires the relevant connector to be authorized
Automated scheduled briefings (e.g., every day at 8am) require a running server with a scheduled task and an active email/Slack integration — without these, briefings are delivered on-demand in chat
