Cross-Department Translation

When to Use

• Reframe a message, spec, metric, or decision for a different internal audience
• Produce dual-audience briefs (e.g., engineering detail + executive summary on one page)
• Decode department jargon and unstated assumptions before handoff
• Convert meeting notes into action items by owner with RACI clarity
• Translate technical specs, incidents, or architecture for business stakeholders
• Translate business constraints, policy, or financial limits for engineering implementation
• Draft escalation summaries that each function can act on without re-interpretation
• Align vocabulary across product, finance, legal, compliance, sales, ops, and actuarial threads

When NOT to Use

• Company-wide messaging strategy, launches, crisis wording, or brand voice → communication-lead
• Issue trees, business cases, operating models, or steerCo analysis without audience reframing → business-consultant
• Multi-team milestones, RAID ownership, dependency maps, launch program governance → technical-program-manager
• Contract, DPA, or legal redlines and negotiation positions → commercial-counsel
• Control mapping, audit evidence pipelines, or attestation engineering → compliance-engineer
• Actuarial engagement SOW, reserve opinions, or regulatory actuarial deliverables → actuarial-consulting
• Natural-language product localization (locale strings, RTL, cultural adaptation) → route to localization/l10n skills if present
• Deep technical modeling execution (pricing triangles, IBNR) → actuary

Related skills

Core Workflows

1. Identify source and target audiences

1. Source — who wrote this; what they assume the reader knows
2. Target — who must understand, decide, or execute
3. Decision or ask — one sentence: what changes if they get it right
4. Sensitivity — legal, regulatory, financial materiality, security, personnel

Load references/audience_profiles_and_register.md for register, depth, and vocabulary norms.

2. Jargon and assumption pass

Before rewriting:

1. Highlight terms that are department-local or overloaded (e.g., "platform," "risk," "material")
2. List implicit assumptions (data exists, approval granted, timeline fixed)
3. Flag ambiguous metrics (gross vs net, ARR vs revenue, calendar vs fiscal)
4. Build a mini-glossary only for terms that appear in the artifact

See references/jargon_decoding_and_glossary.md.

3. Requirements and decision briefs

Use pyramid structure for executives; appendices for specialists.

See references/requirements_and_decision_briefs.md.

4. Meeting notes and handoffs

1. Capture decisions (what was decided, not discussed)
2. Extract actions with one owner, due date, and definition of done
3. Separate FYI from needs response
4. Add RACI when multiple teams share work
5. Include open questions with who resolves them

See references/meeting_notes_and_handoffs.md.

5. Escalation and executive summaries

Escalations need: situation, impact, options, recommendation, asks by role, and what not to do yet.

Keep exec sections to one screen; link detail for operators.

See references/executive_and_escalation_summaries.md.

Output standards

• Lead with decision or ask for executive readers; lead with context and constraints for implementers
• Define acronyms once; prefer plain language over metaphor
• Separate facts, assumptions, and recommendations
• Preserve numeric precision; never round material figures without stating basis
• Tag sections when dual-audience: ## Executive, ## Engineering, ## Finance, etc.
• Flag [LEGAL REVIEW], [COMPLIANCE], [FINANCE SIGN-OFF] when content touches those domains

When to load references