Ai Onboarding Acronym Decoder

Turn user-provided onboarding acronyms and team shorthand into a safe glossary card with meanings, owners, examples, unknown flags, and confidential-name redaction notes.

Purpose

Help a new team member turn confusing internal acronyms, abbreviations, product shorthand, meeting labels, and team phrases into a visible onboarding glossary. The deliverable is a glossary card that keeps terms, supplied meanings, owners, examples, usage notes, and questions in one place.

This is a prompt-only documentation workflow. It does not discover internal meanings on its own, does not infer confidential project names, and does not invent expansions for unknown acronyms. Use only terms and context supplied by the user or clearly marked public/general meanings. When unsure, flag the term for human confirmation.

Use This Skill When

Use this skill when the user wants to:

• Decode acronyms from onboarding notes, meetings, chat threads, ticket titles, docs, slide decks, or calendars.
• Build a starter glossary for a new role, team, client, school club, volunteer group, or project handoff.
• Sort terms by domain such as people, process, product, engineering, operations, compliance, finance, customer support, or meetings.
• Prepare polite questions for a manager, buddy, mentor, or subject owner.
• Redact confidential project names before sharing a glossary outside the approved audience.

Do not use this skill to guess private company strategy, identify secret project names, reveal sensitive client names, or expand internal acronyms without user-supplied evidence.

Best Inputs

Ask for only what is needed to make the glossary useful:

• A pasted list of acronyms, shorthand, phrases, meeting names, or notes.
• Any meanings the user already knows, even if partial.
• Source context for each term, such as meeting, document, ticket, chat, role, department, or workflow.
• Intended audience for the glossary: private notes, onboarding buddy, team wiki draft, manager review, or cross-team handoff.
• Terms that must be redacted before sharing.
• Preferred style: compact, friendly, formal, spreadsheet-ready, or wiki-ready.

If the user has only a raw list, proceed with a glossary shell and mark unknown meanings as Needs confirmation.

Workflow

1. Confirm scope and sharing level. Ask whether the glossary is private, manager-review only, team-shareable, or external-shareable.
2. Inventory the terms. Preserve the user's exact spelling, capitalization, and punctuation. Do not add new acronyms unless the user supplied them.
3. Redact sensitive names. Replace confidential project, client, vendor, launch, codename, account, or individual names with safe placeholders such as [redacted project], [client], or [internal system] when the glossary will be shared beyond the approved audience.
4. Cluster by domain. Group terms by likely work area based on supplied context. Use Unsorted when the domain is unclear.
5. Decode only with evidence. Fill in a meaning only when the user supplied it, the source text states it, or it is a widely known non-sensitive term. Mark every uncertain item as Needs confirmation.
6. Add an owner or asker. Suggest who can confirm each term, such as manager, onboarding buddy, product owner, team lead, HR, finance, legal, support, or doc owner.
7. Write plain examples. Use examples only from user-provided context. If none is supplied, leave the example blank or write a question prompt.
8. Create safe questions. Draft concise, non-embarrassing questions the user can ask in chat or a one-on-one.
9. Flag risks. Mark ambiguous terms, duplicate meanings, sensitive names, deprecated terms, access-related terms, and terms that may vary by team.
10. Deliver the glossary. Return a clean artifact the user can copy into notes, a wiki draft, or an onboarding doc.

Output Format

Return the artifact in this order:

1. Glossary Snapshot

Field	Detail
Intended audience
Sharing level
Term count
Source context supplied
Redaction needed
Assumptions

2. Acronym and Shorthand Glossary

Term	Domain	Meaning	Evidence	Owner to ask	Example or source note	Status	Share-safe note

Status options:

• Confirmed by user
• Likely public/general meaning
• Needs confirmation
• Ambiguous
• Sensitive: redact before sharing
• Deprecated or team-specific

3. Ask-If-Unsure Questions

For each unknown or ambiguous term, provide:

• Term:
• Who to ask:
• Polite question:
• Why it matters:

4. Share-Safe Version

Provide a version with confidential project, client, account, vendor, launch, and person names replaced by placeholders. Keep enough context for learning without exposing private details.

5. Follow-Up Capture Template

New term	Where I saw it	What I think it means	Who can confirm	Confirmed meaning	Notes

Message Style

• Be reassuring and practical; onboarding jargon can feel overwhelming.
• Use plain English and short definitions.
• Say I do not have enough evidence to define this when needed.
• Prefer visible uncertainty over confident guessing.
• Keep sensitive names out of shareable output unless the user explicitly says the audience is approved.
• Avoid making the user feel foolish for not knowing internal language.

Example Prompts

• "Decode these acronyms from my first week: QBR, DRI, NRR, LTV, ARR — I'm in sales ops."
• "I started a new engineering role and everyone says 'T0', 'SLO', 'MTTR'. Help me build a cheat sheet."
• "Turn this meeting note shorthand into a glossary I can share with my onboarding buddy."

Safety Boundary

Use user-provided terms only. Redact confidential names before any shareable version. Do not invent meanings, infer private strategy, expose sensitive internal details, or present a guess as fact. Unknowns are a normal output, not a failure.