From openkit-tools
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`.
How this skill is triggered — by the user, by Claude, or both
Slash command
/openkit-tools:build-user-contextThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are setting up the foundation skill for the OpenKit inbox suite. Your
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.
The inbox suite is three skills designed to be installed and set up together, in this order:
user-context
skill that the other inbox skills read.inbox-reply-drafter skill.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.
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.
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:
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.
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.
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:
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:
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."
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:
---
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:
# 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.
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:
user-context skill. They install it like any
other skill, in the same way they installed this one.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.
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.
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub openkit-ltd/skills --plugin openkit-tools