style-analyzer
Analyze the user's communication style across their Teams chats and emails to build a reusable mimicry profile — greetings, tone, length, punctuation, sign-offs, common phrases, and quirks. Use this skill when the user asks to capture or analyze their writing style, or before configuring an assistant (e.g. an OOO auto-responder) that should write in their voice.
- License 许可
- MIT
- 最近更新
- 2026-11-07
- Stars
- ★ 103
- Forks
- 118
01 前言 Front Matter
- name
- style-analyzer
- description
- Analyze the user's communication style across their Teams chats and emails to build a reusable mimicry profile — greetings, tone, length, punctuation, sign-offs, common phrases, and quirks. Use this skill when the user asks to capture or analyze their writing style, or before configuring an assistant (e.g. an OOO auto-responder) that should write in their voice.
02 资源文件 2
- 参考文档metadata.json560 B
- 参考文档README.md2.1 KB
03 SKILL.md 正文
Style Analyzer
Analyze the user's communication patterns across Teams and Outlook and build a style profile that other skills or automations (e.g. an out-of-office auto-responder) can use to write in the user's voice. Save the profile to memory so it's available across sessions.
Tool names. This skill refers to Microsoft 365 tools as
m365_*and to memory as remember/recall tools. If your host exposes these under different names, map them to the equivalent capability.
Data collection
1. Gather sent emails (20–30 samples)
- List the last ~30 emails in the Sent folder.
- For emails with real body content (not just meeting accepts/declines), fetch the full text body.
2. Gather Teams chat messages
- List recent chats (~50).
- For each relevant chat (prioritize active 1:1 and group chats), fetch the last ~30 messages.
- Filter to messages from the current user (match the
fromfield to the user's display name).
3. Sample diversity
Aim for:
- 10+ sent emails with body content
- 50+ Teams messages across 20–25 different chats
- A mix of 1:1, group, and meeting chats
- Both internal and external conversations where available
Analysis framework
Analyze the collected messages across these dimensions:
- A. Greetings — how they address people (first name, "Hi [Name]", "Hey", formal titles); patterns by relationship type (internal vs external).
- B. Tone & formality — professional/casual/mixed; direct vs hedging; warmth indicators.
- C. Message length — average sentence count; frequency of one-word replies; when they write longer messages.
- D. Punctuation & grammar — consistency; common typos (e.g. lowercase "i"); emoji usage (none / occasional / frequent).
- E. Sign-offs — email signature style; Teams message endings; closing phrases ("Thanks", "Regards", etc.).
- F. Common phrases — frequently used expressions for agreement ("sounds good", "makes sense"), requests ("can you", "would you mind"), availability, and FYI/context-setting.
- G. Technical communication — how they explain technical concepts; level of detail; hedging vs confidence.
- H. Action patterns — how they delegate, loop others in, and schedule meetings.
Output
1. Display a summary
Present findings as a formatted table:
## Communication Style Profile for [Name]
| Dimension | Pattern |
|-----------|---------|
| Greetings | ... |
| Tone | ... |
| Length | ... |
| Emojis | ... |
| Sign-offs | ... |
| Technical | ... |
### Common phrases
- "..."
- "..."
### Quirks & notes
- ...
2. Save to memory
Store the style guide in memory. Use two entries to stay within any per-fact length limits:
- Entry 1 — greetings, tone, brevity, punctuation, emojis.
- Entry 2 — common phrases, delegation style, technical communication, quirks.
Tag both as a preference so they persist and can be recalled later.
3. Confirm storage
Tell the user:
- The style profile has been saved to memory.
- It can be recalled with a query like "writing style".
- It's available to other assistants and automations that write in their voice.
Usage notes
- Re-run periodically (e.g. quarterly) to keep the profile current.
- Pairs well with an OOO / auto-responder skill that should mimic the user's voice.
Privacy
All analysis happens inside the user's own agent environment against their own Microsoft 365 data. No communication content is sent to any third party. The saved profile describes how the user writes, not what they wrote — do not store verbatim private message content in the profile.
04 同仓库更多 Skills
stakeholder-and-decision-map
Mines customer interactions to identify stakeholders, infer their likely roles and engagement, map the decision process, and highlight who or what may be missing. Use when asked to "map a deal's buying group", identify influential or missing stakeholders, "assess who has gone quiet", or "explain how the customer will decide". Do not use for phased engagement plans, contact sequences, choosing or drafting outreach to the single next contact, seller or team performance reviews, or contacting, scheduling, or changing records.
sales-progress-update
Creates or refreshes a sales progress update for a manager or team about work done, deal movement, pending outcomes, supported forecast position, and help needed. Use when asked to "create my weekly sales update", "refresh my sales progress deck", "report my forecast position", "where do I stand against my quarter forecast", or "catch my manager up on committed deals". Do NOT use for non-sales project updates, a since-date deal change digest, momentum or blocker analysis, meeting prep, or outreach drafting.
submission-assemble
Put the checked CSR or 510(k) sections together in template order with a reviewer-facing open-items register, as a draft package for human sign-off. Use when the user asks "assemble the CSR draft", "put the module together for review", "build the review package with the open items on top", "compile the 510(k) sections in order" or "package this up for the submission lead". Do NOT use for assembling an unchecked draft - use consistency-check instead. Do NOT use for loading protocol, SAP or TLF sources - use source-ingest instead. Do NOT use for compiling general documents or slide decks - use the built-in docx or pptx skill instead. Do NOT use for filing or submitting to a regulator - use the sponsor's validated gateway, operated by a human, instead. Guardrail: draft for human approval only (L1); status is draft_clean or draft_open_items, never submitted.
source-ingest
Pull every number, date and population definition out of a study's protocol, SAP, TLF tables, investigator brochure and prior approved text into one cited fact map, keyed per config/field-dictionary.json, before any CSR or 510(k) section is written. Use when the user asks "here's the locked TLF set and SAP, set up the CSR", "load the protocol and tables before we start drafting", "what figures do we have from the database lock?", "pull the disposition counts out of Table 14.1.1" or "ingest the IB for the 510(k)". Do NOT use for drafting or assembling submission sections - use section-draft or submission-assemble instead. Do NOT use for reconciling a patient's medications - use the discharge-care-transition plugin instead. Guardrail: reads and cites sources only; never estimates, rounds or invents a fact.
section-plan
Work out which sections a CSR or 510(k) requires, from the templates in config, check each one against the cited fact map, and name what is missing before a word is drafted. Use when the user asks "what do we still need before we can draft the CSR?", "which sections are ready to start?", "what's blocking the performance data section?", "do we have everything for the synopsis?" or "map our tables to the E3 structure". Do NOT use for writing section language - use section-draft instead. Do NOT use for cross-checking a finished draft - use consistency-check instead. Do NOT use for outlining general Word documents or business reports - use the built-in docx skill instead. Only structures with a template in config are supported. Guardrail: plans only; never marks a section ready on a missing fact and never invents a structure.
section-draft
Write or revise the language for one planned CSR or 510(k) section - synopsis, efficacy, safety, discussion, device description - using only figures already in the cited fact map, each with its TLF or SAP citation. Use when the user asks "draft the Synopsis from our locked tables", "write up safety from Table 14.3.1", "give me a first pass at the discussion", "draft the device description for the 510(k)" or "tighten the wording of the Discussion section". Do NOT use for supplying a number not already in source_facts - use source-ingest instead. Do NOT use for verifying a draft's figures - use consistency-check instead. Do NOT use for appeal letters, clinical notes or discharge summaries - use the matching HLS plugin instead. Guardrail: drafts for human approval only (L1); never asserts an unsourced number or harmonises two figures.