--- name: build-user-context description: | Interviews the user and researches their email to produce a personalised `user-context` skill that captures who they are professionally, who they work with, what projects matter, and how they communicate. Run this skill first, before any other inbox skill. Trigger when the user says they want to set up the OpenKit inbox skills, build their user context, install the inbox assistant, get started with inbox triage, or any phrasing that indicates first-time setup of the inbox suite. Also trigger when the user says their context is stale, their role has changed, or they want to refresh the user-context skill. This skill is the prerequisite for build-inbox-voice and inbox-triage; both depend on the user-context skill that this one produces. Combines targeted multiple-choice questions with autonomous email research, then generates a single SKILL.md file the user installs as `user-context`. --- # Build user context You are setting up the foundation skill for the OpenKit inbox suite. Your job is to produce a single high-quality `user-context` SKILL.md file that captures who the user is at work, the people in their professional life, the projects and themes that recur, and how they tend to communicate. Two downstream skills (`build-inbox-voice` and `inbox-triage`) will read what you produce. The quality of those skills depends on the quality of yours. You will not get this perfect from email alone, and you will not get it perfect from questions alone. The recipe is: ask a few targeted questions to anchor the basics, then go and research email patterns thoroughly, then return with findings and let the user confirm or correct. Then synthesise. ## Where this fits The inbox suite is three skills designed to be installed and set up together, in this order: 1. **build-user-context** (this skill). Captures who the user is, who they work with, and how they communicate. Produces the `user-context` skill that the other inbox skills read. 2. **build-inbox-voice**. Reads the user's email more deeply to learn their writing voice and produces a personalised `inbox-reply-drafter` skill. 3. **inbox-triage**. The daily-use skill. Produces a structured brief of what's urgent, what's worth watching, and what to skip. This skill is step 1. The other two depend on the `user-context` you produce here. When you finish, hand off explicitly to `build-inbox-voice` as step 2, not as one of two options. ## Before you start Check that an email MCP is connected. The skill works with any email connector the user has available (Gmail, Outlook, Zoho, or any Anesi-style Outlook MCP). If none is connected, call `search_mcp_registry` with terms like `["email", "inbox", "gmail", "outlook"]` and use `suggest_connectors` to offer the user the relevant ones. Do not proceed until at least one email source is reachable. If the user is running this in a session with no email MCP available and does not want to connect one, you can still produce a context skill from interview alone, but tell the user clearly that the result will be thinner and that re-running once they have email connected will substantially improve downstream skills. ## Phase 1: Anchor with multiple-choice questions Open with three to five multiple-choice questions using `ask_user_input_v0`. Keep them short and ask them one at a time, or in a single call if they're independent. The aim is to anchor the research, not exhaust the topic. Examples of the kinds of questions to ask: - What's your role type? (Individual contributor / Team lead or manager / Senior leadership / Founder or owner / Other) - What kind of organisation? (Startup / Scaleup / Large company / Professional services / Public sector / Other) - How much of your work is external vs internal? (Mostly external clients or counterparties / Mostly internal team and stakeholders / Roughly balanced) - What's the dominant communication style around you? (Formal and measured / Direct and brief / Warm and collegial / Mixed depending on audience) Adapt these questions to what makes sense. You're trying to set baseline expectations before reading email, so research doesn't get derailed by unusual signals (a partner at a law firm and a designer at a startup both send and receive emails; the same patterns mean different things). Do not ask the user to enumerate their colleagues or projects at this stage. You'll discover most of that from email, and asking up front turns a 20-minute setup into a 45-minute slog. ## Phase 2: Autonomous email research Now go and read. The goal is a structured understanding of the user's working world, grounded in evidence. Use whatever email MCP is connected. Different connectors have different tool names but the same underlying actions: list messages in a date range, read a message, read a thread. If you're not sure which tools you have, call `tool_search` with terms like `["email search", "list emails", "thread"]`. Pull email from the last 90 days. You can go further if the user is in a quiet role or has low email volume, but 90 days is usually the right balance between recency and signal. Focus on sent items and threads the user has engaged with (replied to at least once). Skip newsletters, automated alerts, calendar invites, and CC-only threads where the user never replied. Skip threads the user hasn't actively participated in. For each thread you read, you're building up four kinds of evidence: **People.** Who does the user actually correspond with? Build a list with: sender/recipient email, name (best guess from headers and signatures), frequency over the period, the direction of conversation (who initiates), and any hints about their role (signatures, job titles, what they're asking about). Don't speculate beyond what evidence supports. If you can't tell whether someone is internal or external, note that you can't tell. **Projects and themes.** What named projects, deals, products, accounts, or initiatives recur? Look for proper nouns in subject lines and bodies that appear across multiple threads. Note approximately when each one first appears in the user's recent email and whether it still seems active (recent activity vs gone quiet). **Rhythms.** What does the user's working week look like through their email? When are they most active? Are there standing meetings or weekly deliverables visible from email? Do they handle inbound in real-time or batch? **Communication norms.** How does the user write? Formal vs casual, long vs short, warm vs direct, signature style, salutation style, how they handle delicate situations (chasing, declining, disagreeing). This is intentionally lighter than what `build-inbox-voice` will do later; you're capturing the high-level register, not the full voice. The downstream voice skill will go deeper. Aim to read enough to be confident in your findings without burning the user's tokens. A few dozen substantial threads will usually suffice for a clear picture. If you hit ambiguity, prefer reading another thread over guessing. While you research, keep a running scratchpad. You'll use it to brief the user in phase 3. ## Phase 3: Confirm and fill gaps Come back to the user with what you found. Don't dump raw data; present it as a structured digest they can react to. Show, for each of the four evidence buckets, what you observed and where you have low confidence. Use `ask_user_input_v0` to confirm or correct specific findings: - "I see you correspond most with [X, Y, Z]. Are these your closest working relationships, or am I overweighting noisy ones?" - "I see project names [A, B, C] recurring. Which are still active?" (multi-select) - "[Person] seems to be your manager based on the patterns I see. Is that right?" (yes / no / other relationship) - "How would you describe your default tone with external counterparties?" (multi-select among the patterns you observed) Ask at most six to eight questions in this phase. The user has already done one round of questions; this is the confirm-and-fill round, not a second interrogation. Prioritise: 1. Things that will most affect downstream skill behaviour (who matters, what counts as urgent). 2. Things you're least confident about. 3. Things the user is likely to have strong opinions on. Skip questions you're confident the email already answered well. Also ask one open question at the end: "Anything else important about your work that wouldn't show up in email? Direct reports who don't email much, contractors, off-platform contacts, projects you're spinning up that haven't hit your inbox yet." ## Phase 4: Generate the user-context skill You now have everything you need. Write a single SKILL.md file at `/mnt/user-data/outputs/user-context/SKILL.md`. The file is the entire deliverable; do not create reference files or subdirectories. The generated skill's frontmatter must be: ```yaml --- name: user-context description: | Reference skill containing the user's professional context: role, people they work with, projects, communication norms. Read by inbox-triage, build-inbox-voice, and inbox-reply-drafter. This skill is consulted explicitly by other skills via `view`; it should not be triggered directly by user prompts. If the user wants to update their context, they should re-run build-user-context or edit this file directly. --- ``` The triggering language in the description is deliberately weak. This skill is a data file, not an actor. Below the frontmatter, organise the content with these sections: ```markdown # User context _Generated by build-user-context on [DATE]. Snapshot in time; the user's working world will change. Re-run build-user-context to refresh._ ## Who the user is A short paragraph: name (if known), role, organisation type, what they broadly do day-to-day. Two to four sentences. ## People A list of the user's significant correspondents. For each, in order of significance: - **Name** ([email]). Role/relationship, internal/external, approximate interaction frequency, one sentence on what they tend to discuss with the user. Group by category where it helps (e.g. "Internal team", "Key external counterparties", "Senior stakeholders"). If the user mentioned anyone in phase 3 who doesn't appear in email, include them with a note: "(mentioned in setup, low email signal)". ## Projects and themes The active projects, accounts, deals, or initiatives that recur. For each: - **[Name]**. What it is, status (active/winding down/new), who else is involved. Include any themes that aren't named projects but recur (e.g. "Weekly sales pipeline reviews", "Quarterly board reporting"). ## Communication norms Two or three short paragraphs covering: - Default register (formal/direct/warm), with concrete examples observed. - Common scenarios the user handles and how (chasing, declining, delegating, internal updates). - Anything distinctive about the user's voice the downstream voice builder should know. ## How this skill should be used A short closing note for other skills that read this one, explaining that this is a snapshot, that some people and projects will become more or less relevant over time, and that the user has the final word on what matters. ``` Do not include speculation. If you're uncertain about something, either omit it or mark it explicitly as low-confidence. The user will read this file and downstream skills will rely on it; getting it wrong is worse than leaving it sparse. Keep the total file to roughly 200-400 lines of markdown. Long enough to be useful, short enough that downstream skills can read it all at once without burning context. ## Phase 5: Present, explain, and hand off to step 2 Once the file is written, use `present_files` to show the user `/mnt/user-data/outputs/user-context/SKILL.md`. Then tell them three things: 1. This file is their `user-context` skill. They install it like any other skill, in the same way they installed this one. 2. They can edit it freely. It's just a markdown file. If you got someone's role wrong or missed a project, they should fix it directly. 3. **Next step: install this file, then run `build-inbox-voice`.** That's step 2 of 3 in the setup chain. It reads their email more deeply to learn their writing voice and produces a personalised `inbox-reply-drafter` skill. Once that's done, they're set up to use `inbox-triage` for the daily inbox brief whenever they want it. Don't offer `build-inbox-voice` and `inbox-triage` as a choice. They are sequential, not alternatives: the voice-builder reads deeper email patterns that triage doesn't need, and the resulting drafter makes the day-to-day workflow much better. Send the user to `build-inbox-voice` next. **Bootstrap case.** If this run was triggered by another skill (typically `inbox-triage` or `build-inbox-voice`) because `user-context` was missing, say so explicitly in this final message: "Once you've installed this, ask me to [triage your inbox / build your inbox voice] again and I'll pick up where we left off." The user should know the original request hasn't been forgotten. Then end the run. ## Reflexes **Evidence-first.** Every person, project, or pattern in the output should be traceable to something you actually observed in email or something the user confirmed. No inferring from one signal; no inventing context to fill gaps. **The user is the source of truth.** If the user corrects something you observed in email, the correction wins. Don't argue with a user who says "that person isn't my manager"; update and move on. **Snapshot, not prophecy.** The skill you generate will go stale. Say so in the generated file. Don't pretend the context is permanent. **Generic, not bespoke.** This skill ships to anyone. Don't bake in assumptions about industry, company, tooling, or workflow that wouldn't generalise. If the user works in a niche, the generated `user-context` will capture that, but `build-user-context` itself stays universal. **No silent failures.** If you can't reach email, can't get past Phase 1, or run into something you can't handle, tell the user clearly. Don't generate a context skill from thin air and pretend it's grounded.