Claude Onboarding Session

You are helping onboard a new user. Your goal is to learn about their role, responsibilities, and working context so future responses can be tailored to them, and to propose both durable memory and standing Instructions for Claude.

Conduct a short, friendly interview. Ask one question at a time and build on their answers rather than running through a fixed checklist. Ask questions in a multiple-choice format widget. Aim to understand:

- Their job title and the team or organization they work in
- Their main responsibilities and what a typical week looks like
- The tools, systems, or platforms they rely on
- Who they collaborate with most often (clients, teammates, leadership)
- Their goals or current priorities
- How they prefer information delivered (level of detail, tone, format, and any hard rules like "no bullet points" or "always cite sources")

Keep it conversational and keep each question brief. Do not interrogate. If an answer reveals something worth exploring, follow up naturally before moving on. Ask at least 10 questions before wrapping up, and more if you still don't have a clear working picture. A handful of answers is not enough to write good instructions.

As you go, sort what you learn into two buckets:

1. Memory: durable facts about the user (stable things like their role, team, tools, and key collaborators, not one-off details). These persist across conversations so you have context.

2. Instructions for Claude: standing directives about how you should behave in future responses, derived from their preferences and workflow. These are actionable rules, phrased as instructions, not facts. For example, if they say they skim on mobile and hate long preambles, propose an instruction like "Lead with the answer. Keep responses short and skip preamble." If they always need work in a specific format, propose "Default deliverables to [format]." Only propose instructions that are clearly supported by what they told you; do not invent preferences.

Confirm with the user before saving anything that seems sensitive or that they may not want retained.

When the interview is done:
- Give a short summary of what you learned.
- List the memory entries you will save.
- List the proposed Instructions for Claude, each as a concrete directive, and ask the user to confirm, edit, or remove any before you save them.
- Invite them to correct anything.

Help me create a Claude Skill called Email Voice.
Review all my sent emails from the last 90 days and analyze my writing style, including:

- Sentence structure: How I phrase and structure my sentences.
- Opening and greetings: How I begin emails and address recipients.
- Closing and sign-offs: How I end emails and sign off.
- Tone and formality: How my tone varies depending on the recipient and situation.
- Internal vs. external emails: Identify the differences between emails sent to colleagues and those sent to clients, vendors, or other external contacts.
- Common patterns: Identify recurring phrases, wording preferences, and other characteristics of my writing style.

Before creating or committing to the Skill, present your analysis of my email voice first. Explain what you think my writing style is, and provide specific examples from my sent emails for each category above. Clearly distinguish between internal and external email styles.
Wait for my approval. If I agree with your analysis, proceed to create the Email Voice Skill based on the findings.

Triage and draft replies for my Outlook inbox (Microsoft 365 connector).

SCOPE
- Pull every unread email received in the last 24 hours from my Inbox.
- Do not send anything, mark anything as read, move, label, or delete anything. Drafts only.

STEP 1: DRAFT REPLIES

- Use the email-voice skill for voice and style. Read it before drafting.
- Draft a reply for every unread email in the last 24 hours.
- Exception: skip no-reply addresses and fully automated system notifications (alerts, receipts, calendar responses), since replies to those go nowhere. List them as skipped in the report.
- Create each draft as a threaded reply in the original conversation. Use reply-all only when others on the thread need my answer; otherwise reply to the sender only.
- Never invent facts, commitments, dates, prices, or availability. Where you need information from me, put a clear placeholder like [CONFIRM: delivery date] in the draft.
- If an email is ambiguous enough that you can't draft a useful reply, skip the draft.

STEP 2: TRIAGE
Categorize every email into one bucket:

- High: a client or my manager needs a decision, answer, or deliverable from me; anything with a deadline in the next 48 hours; anything about money, contracts, scope, or a production issue.
- Medium: needs a reply from me but isn't time-sensitive; internal coordination; scheduling.
- Low: FYI, CC-only, newsletters, marketing, automated notifications, calendar accept/decline receipts, no-reply senders.

STEP 3: REPORT (inline in chat, not a file)
One table per bucket, High first, with these columns:
Sender | Subject | One-line summary | What I need to do | Draft created (Y/N)
Then list:

- Every draft containing placeholders, so I know what to fill in before sending.
- Every email skipped (no-reply, automated, or too ambiguous) and why.

Run every weekday at 7:30 AM Mountain Time