Training Report

Training Report

Iterate the full report in Markdown first. Generate the .docx last, once, when the content is final. The .md is the canonical artifact; the .docx is a terminal derivative.

Discipline-agnostic: coding workshop, leadership seminar, safety training, onboarding, creative workshop — all apply equally.

Voice mode: this conversation may be conducted by voice. Transcription can introduce homophones, missing punctuation, or ambiguous proper nouns (names, company names, tool names). If any answer is unclear after transcription, ask a short clarifying question before moving on — do not guess.

Reference files

Load these files at the steps indicated. Do not load them all upfront.

Step 0 — Check dependencies

Before asking the user anything, verify skill availability.

`docx` skill (required for Step 6)

• If found: note it; load it at Step 6
• If not found: warn the user — it is required to generate the final Word document and can be installed from Anthropic's official skill library. Offer to proceed with the Markdown draft in the meantime.

Humanizer skill (recommended)

• After Step 1, look for a humanizer skill matching the chosen language
• If found: load it and apply it during the humanization pass in Step 5
• If not found: tell the user once, then fall back to inline humanization rules (Step 5b). Suggest installing a humanizer skill for the chosen language.

Step 1 — Language & audience

Ask:

1. "In what language should I write the report? (French / English / other)" 2. "Who is the primary reader? (executive / HR / direct management / external client / internal archive)"

Then load references/tone-of-voice.md and apply its guidance throughout.

Step 2 — Template

Ask:

"Do you have a Word (.docx) template for this report? (company header/footer, logo, branded fonts, color scheme)"

• Yes → ask them to upload it; use it as the base at Step 6 (unpack/inject/repack)
• No → proceed with a clean document; ask for a brand color before defaulting to blue #2E75B6

Step 3 — Interview

Conduct a structured interview in batches. Wait for answers before moving on. Extract what the user already told you from the conversation before asking.

Batch A — Session metadata

• Trainer name and role
• Date, location, company/team name
• Duration
• Total number of participants
• Confirm or refine: who is the document for?

Batch B — Session context

• Stated goal of the training
• Subject, topic, tool, or material used as practical support
• Any rules or constraints set at the start
• Materials, accounts, licenses, or equipment provided to participants

Batch C — Starting levels

• Distribution of familiarity across the group (any beginners? any experts?)
• Notable outliers at either end

Batch D — Session walkthrough

Walk through the session step by step. For each step:

• Objective
• What participants actually did
• Materials, tools, or exercises involved
• First exposure to this concept or not
• How it landed; any difficulties

Probe until complete: "What happened next?", "Did anything go differently than planned?", "Were there any pivots?"

Batch E — Deliverables

Ask: "Did participants produce anything during the session?"

Probe for:

• Documents, files, diagrams, prototypes, or any output created during exercises
• Collaborative work produced as a group
• Individual work produced autonomously
• Anything left incomplete or started but not finished

These may appear in the Annexes and/or be referenced in the Session Walkthrough.

Batch F — General observations

• Overall energy and engagement of the group
• Any incidents, surprises, or notable moments
• Schedule: did it hold, or were sections cut/extended?
• Logistical issues (room, materials, setup)

General Observations is optional. If the trainer has nothing notable to add beyond the walkthrough, skip this section entirely.

Batch G — Individual feedback

Ask: "Do you have specific observations for any individual participant?"

For each named participant, extract:

• Role or background
• Starting level
• Behavior/engagement (positive and negative)
• Notable evolution, breakthrough, or resistance
• How they ended the session

Individual Feedback is optional. Only write it if the trainer explicitly provides meaningful observations. Do not prompt for feedback on every participant.

Be diplomatic. Describe behaviors, not character. Name problems factually; do not editorialize. When writing for an external client about a team you don't know, consider whether naming individuals is appropriate at all.

See references/tone-of-voice.md — Diplomatic framing section.

Batch H — Recommendations & next steps

Ask: "What would you recommend to the direction/client to build on this session?"

Probe for:

• Resources and access to provide (licenses, books, platforms, communities)
• Practices to anchor in daily work
• What to pace carefully — basics before advanced material
• Follow-up sessions (refresher, coaching, Q&A after a few weeks)
• Assessment and validation (quiz, practical challenge, peer review, checklist)
• Knowledge-sharing rituals (Slack/Teams channel, recurring meeting, Loom demos, buddy system, monthly show-and-tell)
• Management involvement (protect practice time, 1:1 check-ins, celebrate wins)
• External resources (books, courses, certifications) for self-driven participants
• Specific warnings or caveats for management

Batch I — Annexes

Ask: "Do you have any annexes to attach to the report?"

Annexes can include:

• Photos from the session
• Satisfaction survey results (NPS, ratings, verbatim comments)
• Slides or handouts distributed during the session
• Work produced by participants (exercises, prototypes, documents, diagrams)
• Reference documents used during the session
• Any other supporting material

For each annex:

• Image → attempt auto-embed at Step 6
• File (PDF, slides, spreadsheet) → reference in the Annexes section; do not embed
• Survey data → synthesize in Step 4, then include as a dedicated section in the doc
• Participant deliverable → reference in the relevant Walkthrough step AND in Annexes

Batch J — Closing & contact

Ask: "May I include a closing note thanking the team for the invitation, and your contact details for future collaboration? (email + phone)"

If yes: collect name, email, phone. The closing is written in the document language, personal in tone, brief. See references/markdown-draft.md — Closing paragraph section.

Step 4 — Feedback synthesis (if survey data provided)

Produce a synthesis in the conversation before drafting:

• Overall score / NPS
• Rating distribution
• Top 3 positive themes
• Top 3 areas for improvement
• Any outlier responses

Ask the user to confirm before it enters the document.

Step 4b — Confirm outline

Here's what I'll draft:
1. Context
2. Starting Levels
3. Session Walkthrough (N steps)
4. General Observations         [optional — include if trainer provided content]
5. Participant Satisfaction     [only if survey data provided]
6. Individual Feedback          [optional — include if trainer provided feedback]
7. Recommendations & Next Steps
8. Annexes                      [only if annexes provided]
[Closing + contact]

Language: [language] | Audience: [target] | Template: [yes/no]

Ask: "Anything to adjust before I start the draft?"

Step 5 — Markdown draft

Load `references/markdown-draft.md` before writing. It contains the full section-by- section writing guide, Markdown limitations, HTML table workarounds, and closing paragraph guidance.

Humanization pass

Before presenting the draft, apply the humanizer skill (loaded in Step 0). If no humanizer skill is available, apply these rules inline:

• Cut all AI throat-clearing openers and sentence starters
• Cut adjective doublets — pick the more precise word
• Replace passive voice with active wherever natural
• Replace vague praise or criticism with specific behaviors or facts
• Short sentences over long ones
• Adapt to the document language (see references/tone-of-voice.md)

Do not present an un-humanized draft.

Iteration loop

Present the draft inline in the conversation. Let the user lead. Update the .md file for every change. One canonical file, no versions. Only move to Step 6 when the user explicitly confirms the content is final.

Step 6 — Final .docx generation

Load `references/docx-generation.md` and the `docx` skill before starting.

This step runs once. It is terminal: if the user requests changes after the .docx is generated, update the .md and regenerate from scratch.

Deliver both files. If the environment supports inline file delivery (e.g. present_files on Claude.ai), use it. Otherwise, print the absolute paths to both files.

Pitfalls

• Don't fabricate details — only document what the trainer explicitly provided
• Don't editorialize in General Observations — factual only
• Don't write Individual Feedback unless explicitly provided — and stay diplomatic
• Don't pad recommendations — 6 sharp ones beat 12 vague ones
• Always include a Pacing recommendation in the Next Steps
• This skill is not developer-specific — adapt vocabulary to the discipline
• Never generate the .docx mid-conversation — Markdown is the draft stage
• Never skip an annex or image — embed, reference, or placeholder

DOCX Generation — Reference

Load this file at Step 6. Read the docx skill first — this file does not repeat its technical rules, only adds training-report-specific structure and formatting guidance.

Pre-conditions

• The docx skill has been loaded and read in full
• The Markdown draft has been reviewed and approved by the user
• This is the last operation of the conversation

If a template was provided (Step 2)

Use the docx skill's unpack/edit/repack workflow:

1. Unpack the template to a working directory 2. Inject section content into existing paragraph styles — do not redefine fonts, colors, or margins; the template owns those 3. Preserve all existing header/footer/logo elements exactly 4. Repack and validate

Map the Markdown headings to the template's heading styles by name. If the template uses custom style names (e.g. "TitreSection" instead of "Heading 1"), use those names.

If no template was provided

Build from scratch following the docx skill's node.js API. Apply the structure and formatting guidance below.

Document structure

Cover block (no H1 — use raw Paragraphs)

[Title]        — large (48pt), bold, brand color, Arial
[Subtitle]     — medium (28pt), dark, Arial
[Metadata]     — small (22pt), gray, Arial
               format: Company — Team | Date | Duration | N participants

Followed by a separator (paragraph with bottom border, not a Table).

Header

"Training Report | [Team]"    — 20pt, gray, bold label + separator bottom border

Adapt to document language: "Compte rendu de formation" in French, etc.

Footer

"[Trainer name] | [Date]"     — 18pt, gray, separator top border

Body sections

Mirror the Markdown structure. Convert each Markdown heading level:

• ## Section title → HeadingLevel.HEADING_1 (32pt, bold, brand color)
• ### Subsection → HeadingLevel.HEADING_2 (26pt, bold, dark)

For sections marked optional in the Markdown (Individual Feedback, General Observations, Satisfaction) — only include them if content was written.

Closing paragraph

Style as normal body text. Contact details (name, email, phone) on a single line, slightly smaller font (20pt), gray, after a spacer paragraph.

Annexes section

One bullet per annex:

• [Title]: [description] — [status: embedded / see attached / placeholder]

Handling annotated elements from Markdown

For each <!-- DOCX: convert to styled Table --> block:

• Rebuild as a native Table element using the docx skill's table API
• Apply column widths (sum must equal content width: 9026 DXA for A4 with 1" margins)
• Header row: light brand-color shading (ShadingType.CLEAR), bold text
• Body rows: alternating light gray shading optional
• Cell padding: { top: 80, bottom: 80, left: 120, right: 120 }
• Do not carry over HTML — rebuild natively

For other <!-- DOCX: [instruction] --> annotations: follow the instruction literally.

Validation and delivery

Run the validation step as directed by the docx skill. Fix any errors before presenting. Deliver both files:

• $OUTDIR/training_report_[team]_[date].docx
• $OUTDIR/training_report_[team]_[date].md (source for future reference)

If the environment supports inline file delivery (e.g. present_files on Claude.ai), use it. Otherwise, print the absolute paths to both files.

Close with:

• 1-sentence summary of what was produced
• List of any images needing manual insertion (with instructions)
• Reminder: future edits go through the .md first; do not edit the .docx directly

Markdown Draft — Reference

This file details how to write, structure, and iterate the Markdown draft of the training report. The Markdown file is the canonical artifact. The .docx is generated once, at the end of the conversation, from this file.

Why Markdown first

Editing prose in Markdown is fast and transparent. Editing binary .docx XML is slow, error-prone, and requires unpacking, modifying, and repacking a ZIP archive. By keeping the canonical content in Markdown:

• Every change the user requests is a simple text edit
• The content is readable and reviewable in the conversation itself
• The .docx is a derivative — a styled rendering of the final approved text
• If the user edits the .docx directly and then asks for changes, you're back to parsing binary XML; avoid this situation by making it clear that the .md is the source of truth

The conversion to .docx is the last operation of the conversation. It is not reversible mid-conversation: if the user requests changes after the .docx is generated, update the .md and regenerate from scratch.

File naming and location

Save the draft to the same output directory that the docx skill will use for the final .docx. Determine that directory before writing — ask the docx skill or use the same $OUTDIR you will use at Step 6. Both files must end up in the same directory:

$OUTDIR/training_report_[team]_[date].md
$OUTDIR/training_report_[team]_[date].docx   ← written at Step 6

Keep a single file. Do not create _v2, _final, _revised variants. Every iteration overwrites the same file. The conversation history is the version history.

Document structure in Markdown

Write the following sections in order. Omit any section that was explicitly skipped (e.g. no individual feedback requested, no satisfaction data provided).

# [Title of the training]

[Subtitle: tool/topic + session type] [Metadata: Company — Team | Date | Duration | N participants]

## 1. Context

[2–3 paragraphs: who commissioned it, what the goal was, what support material was used, any key rules or framing set at the start]

## 2. Starting Levels

[Intro sentence + bullet list segmenting participants by prior familiarity]

## 3. Session Walkthrough

### 1. [Step name]

[1–3 paragraphs: what participants did, what concept was introduced, how it landed]

### 2. [Step name]

...

## 4. General Observations

[3–5 paragraphs: flow, logistics, engagement, notable incidents. Factual only.]

## 5. Participant Satisfaction

[Only if survey data was provided. Overall score, distribution, themes from verbatim.]

## 6. Individual Feedback

[One H3 per notable participant. Optional section — only include if explicitly requested.]

### [Name]

**Starting level:** [brief description]

[Paragraph on background and initial posture] [Paragraph on evolution during the session]

## 7. Recommendations & Next Steps

### [Group heading, e.g. Resources & Access]

- **[Label]:** [explanation]

### [Group heading]

...

## 8. Annexes

[List of attached or referenced documents. Embedded images described inline.]

_[Closing sentence thanking the team for the invitation and expressing openness to future collaboration — see Closing section below]_

_Contact: [name] — [email] — [phone]_

Section-by-section writing guidance

1. Context

• Start with the commissioning context: who asked for this training and why
• Describe the practical support used (project, tool, subject) in one sentence
• If a key rule or constraint was set at the start (e.g. "work without looking at the source material"), highlight it as a Markdown blockquote: > Do not open the reference document.
• Do not include the full session timeline here — that belongs in Section 3

2. Starting Levels

• The goal is to give the reader a quick picture of the heterogeneity of the group
• Use a bullet list, not prose — it scans faster
• If a participant is named in a bullet, be consistent: either name everyone or name outliers only
• Include the level of the furthest-ahead participant as context for the recommendations

3. Session Walkthrough

• Use numbered subheadings so the reader can track position in the session
• Focus on what participants DID, not what the trainer explained
• One paragraph per step is often enough; use two if there was a notable difficulty or a pivot in format
• End each step with the outcome: did everyone complete it? Was it demonstrated only? Did something unexpected happen?
• Note any steps that were cut or shortened due to time pressure

4. General Observations

• Write in short paragraphs, one idea each
• Do not editorialize here — this section is factual
• Good topics: pacing, tool setup issues, group energy, engagement level, any unexpected disruptions (external interruptions, early departures, etc.)
• Save any interpretation for Individual Feedback

5. Participant Satisfaction

• Lead with the headline number (NPS or overall score)
• Use a brief list for themes, not prose: it reads faster and anchors the verbatim
• If there are contradictory signals (high score but negative verbatim), name both and let the reader interpret
• Do not use verbatim quotes directly unless the trainer confirmed the wording — paraphrase instead

6. Individual Feedback (optional)

• Only write this section if the trainer explicitly requested individual feedback
• One subheading per participant who has something meaningful to say about
• Structure per participant: starting level (bold), background paragraph, evolution paragraph
• Be direct where praise is genuine. Name resistance factually, not judgmentally.
• If writing for an external client, consider whether naming individuals is appropriate (see tone-of-voice.md — Diplomatic framing section)
• The trainer knows the participants; you do not. Do not embellish or infer beyond what the trainer explicitly told you.

7. Recommendations & Next Steps

• Group recommendations under subheadings — do not use a flat list
• Each bullet: bold label followed by a colon and the explanation
• Recommendations must be actionable. "Encourage practice" is not actionable. "Block 30 minutes per day for autonomous practice in the two weeks following the session" is actionable.
• Always include a Pacing subgroup advising management not to rush participants into advanced or complex material before basics are consolidated
• Adapt the vocabulary to the discipline — these recommendations apply to any field, not just technical ones

8. Annexes

• List each annex with a title, a one-sentence description, and its status
• Status options: "embedded in document", "see attached file", "placeholder — insert manually"
• If the annex was produced by a participant (exercise, deliverable, prototype), note the author and the context in which it was produced
• For survey data already covered in Section 5, just reference it here: "Satisfaction survey results — synthesized in Section 5"

Closing paragraph

At the end of the document, after the Annexes section, add a brief personal closing:

• Thank the team/client for the invitation to run the session
• Express openness to future collaboration (follow-up session, other training topics, consulting)
• Include contact details: email and phone number

Ask the trainer for this information before writing the closing. Do not invent or assume contact details. The closing should feel personal, not templated.

Example (adapt to language and tone):

Merci à toute l'équipe pour l'invitation et la qualité des échanges durant cette session.
Je reste disponible pour un suivi, une prochaine formation, ou tout autre besoin de
collaboration.

Samuel Berthe — contact@samuel-berthe.fr — +33 6 XX XX XX XX

Markdown limitations and workarounds

Markdown has no native concept of page layout. The following elements do not exist in Markdown and will be applied only at the .docx generation step:

• Page headers and footers
• Page numbers
• Margins and page size
• Branded fonts and color schemes
• Logo placement
• Section breaks

Do not attempt to represent any of these in the Markdown file.

Tables

Standard Markdown table syntax has no column widths, no merged cells, no per-cell styling, and no header row shading. For simple tables (3–4 columns, uniform rows), use standard Markdown syntax:

| Column A | Column B | Column C |
| -------- | -------- | -------- |
| Value    | Value    | Value    |

For complex tabular content (decision matrices, multi-column layouts, merged headers, per-cell styling), write a minimal HTML table directly in the Markdown. Mark it with a processing annotation:

<!-- DOCX: convert to styled Table -->
<table>
  <thead>
    <tr>
      <th>Column A</th>
      <th>Column B</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Value</td>
      <td>Value</td>
    </tr>
  </tbody>
</table>

Keep the HTML simple: no inline styles, no colspan/rowspan unless necessary. The annotation tells Step 6 to rebuild this as a native docx Table element with proper column widths, shading, and padding.

Other complex elements

For any element that Markdown cannot represent cleanly, add an annotation:

<!-- DOCX: [instruction for Step 6] -->

Examples:

• <!-- DOCX: insert page break before this section -->
• <!-- DOCX: render as two-column layout -->
• <!-- DOCX: this is an image placeholder — embed [filename] here -->

These annotations are invisible to the reader of the Markdown file and serve as explicit instructions for the .docx generation step.

Presenting the draft

After saving the .md file, present the content inline in the conversation — do not just say "the file is ready". The user needs to read and react to the actual text.

If the environment supports inline file delivery (e.g. present_files on Claude.ai), use it to make the .md downloadable. Otherwise, print the absolute path to the saved file.

End the presentation with a focused prompt:

"Here's the draft. Read through it and tell me what to adjust — any section, any phrasing, any missing detail. We'll iterate until you're happy, then I'll generate the Word document."

Do not ask multiple questions at once. Let the user lead the iteration.

Tone of Voice Reference

Load this file when starting a training report. Apply the guidance throughout the entire document — cover, body, individual feedback, and recommendations all follow the same register.

By audience

Executive / Direction

Goal: give them a clear picture in 30 seconds. They skim.

• Lead with outcomes and conclusions, not process
• State problems plainly — "the session was cut short" not "the session experienced some time management challenges"
• Recommendations must be concrete and actionable: budget, timeline, owner
• No jargon, no acronyms without expansion, no internal vocabulary
• Omit anything that doesn't affect a decision

HR / Learning & Development

Goal: assess training effectiveness and plan follow-up.

• Behavior and evolution are central — show change over time, not just snapshots
• Individual feedback must be specific and useful, not just positive
• Tie observations to learning objectives stated at the start
• Frame problems as development opportunities where genuine — but do not soften real blockers into "areas for growth" if they require direct intervention
• Attendance, engagement, and completion rates matter — include them if relevant

Direct management (team lead, department head)

Goal: know what their team learned and what to do next week.

• Practical and operational — what changes on Monday?
• Name participants directly in feedback (they know their team)
• Recommendations must be immediately actionable: "block 30 minutes per day for practice" is better than "encourage regular practice"
• Flag any individual who needs extra support or follow-up coaching

Client (external)

Goal: justify the value of the training and set expectations for follow-up.

• Professional, measured, and constructive
• Avoid internal vocabulary — write as if they have no context about the team dynamics
• Problems and blockers should be named but always paired with a recommendation
• Diplomatic on individual feedback — clients don't always need names; you can write "some participants" or "a minority of the group" when appropriate
• The report reflects on your professional reputation — review every sentence

Internal archive

Goal: complete record for future reference.

• Comprehensive over concise — include details that might seem obvious now
• Factual tone, no optimization for any particular reader
• Include session structure, materials used, timing, and participant list if available
• Note anything that would need to change if the session were run again

By language

French

Register: formal by default. Use vous in any direct address. Full sentences, no contractions in prose. Avoid familiarities even in individual feedback.

Sentence structure: French formal writing drifts toward the passive and toward long subordinate clauses. Push back:

• Prefer X a fait over X a été réalisé
• Split sentences at 30 words — French readers tolerate longer sentences than English, but formal documents still benefit from rhythm
• Avoid starting consecutive sentences with the same subject

Typography:

• Guillemets with non-breaking spaces: «\u00a0texte\u00a0»
• Non-breaking space before :, ;, !, ?
• EUR in formal financial contexts, non-breaking space between number and unit: 100\u00a0EUR/mois
• Em dash — not double hyphen --

Vocabulary:

• Avoid anglicisms unless the term has no French equivalent in the field (e.g. "workshop", "feedback", "prompt" are acceptable in tech contexts)
• formation not training, participants not attendees, compte rendu not rapport for this type of document
• Verbs over nominalizations: mettre en place not la mise en place de

Common AI tells to eliminate: Il convient de noter, dans le cadre de, à cet égard, par ailleurs, ainsi, en effet at sentence start, crucial, essentiel, notamment, permettre de + infinitif as a sentence opener

English

Register: depends on client culture. Default to clear and direct. Calibrate British vs. American if it matters for the audience (ask the user in Step 1).

Sentence structure:

• Active voice, subject-verb-object, no ambiguity
• One idea per sentence in high-stakes sections (executive summary, individual feedback)
• Contractions are acceptable in informal sections (individual feedback, conversational observations); avoid in executive summary and recommendations

Typography:

• Curly quotes: "..." and '...'
• Em dash: word—word without spaces (American) or word — word with spaces (British)
• Numerals: spell out one through nine; use figures from 10 upward

Vocabulary:

• Avoid Latin abbreviations (i.e., e.g., etc.) in flowing prose — write them out
• Prefer concrete nouns over abstract ones: the group struggled with X not there were challenges around the area of X
• participants not attendees or trainees in most contexts
• Avoid corporate filler: leverage, synergy, learnings, takeaways → rephrase

Common AI tells to eliminate: It is worth noting that, it is important to highlight, in today's fast-paced world, this approach enables, moreover, furthermore at sentence start, adjective doublets (comprehensive and thorough, clear and concise)

Spanish

Register: formal (usted) by default unless the user confirms an informal context.

Sentence structure:

• Spanish formal writing is naturally richer in subordinate clauses than English or French. Allow for longer sentences but break them at natural pauses to maintain clarity.
• Subject-verb agreement errors are common in AI output — verify every complex sentence.
• Subjunctive is frequently required in recommendations: se recomienda que el equipo practique not se recomienda practicar

Typography:

• Inverted punctuation at sentence start: ¿pregunta?, ¡exclamación!
• Guillemets «\u00a0...\u00a0» or Spanish quotation marks "..." — ask the user which the client uses
• EUR or € — check client convention

Vocabulary:

• Avoid direct loan words from English when a Spanish equivalent exists: retroalimentación not feedback, taller not workshop (unless the client uses it)
• Regional differences matter: Latin American Spanish differs from European Spanish in vocabulary and some formality conventions — ask the user which applies

German

Register: formal (Sie) by default unless explicitly told otherwise. German formal writing tends to be precise and comprehensive — do not cut technical detail for brevity.

Sentence structure:

• Compound sentences and subordinate clauses are natural in German. Keep verb placement correct: nachdem die Teilnehmer die Aufgabe abgeschlossen hatten, ...
• Avoid starting too many consecutive sentences the same way.
• Main clause before subordinate clause in recommendations when possible — it reads more directly.

Typography:

• Anführungszeichen: „Zitat" (lower-left, upper-right)
• Non-breaking space before units: 100\u00a0EUR

Vocabulary:

• Compound nouns are standard — use them rather than translating English phrases literally: Teilnehmerfeedback not Feedback der Teilnehmer, Weiterbildungsmaßnahme not Maßnahme zur Weiterbildung
• Anglicisms: "Workshop", "Feedback", "Coaching" are broadly accepted in German professional contexts; avoid less established ones

Portuguese (European vs. Brazilian)

Critical first step: ask the user which variant applies — vocabulary, formality norms, and even punctuation differ significantly.

European Portuguese:

• Formal, restrained, indirect register
• Avoid the imperative in recommendations — prefer the infinitive or subjunctive: recomenda-se que a equipa pratique not pratiquem regularmente
• equipa not equipe, utilizador not usuário
• Closer to French in its preference for formal distance

Brazilian Portuguese:

• More direct and warmer tone is acceptable even in formal documents
• Imperative in recommendations is natural: incentive a equipe a praticar
• equipe not equipa, usuário not utilizador
• English loanwords are more freely used in tech and business contexts

Typography (both variants):

• Quotation marks: "..." or «\u00a0...\u00a0» — check client convention
• Non-breaking space before units

Diplomatic framing for difficult feedback

Individual feedback requires care regardless of language or audience.

Principle: describe behavior, not character. Name what happened, not what kind of person the participant is. Let the facts carry the weight. One interpretive sentence at the end is enough.

When writing for an external client about a team member you don't know:

• Avoid naming individuals in negative feedback unless the trainer explicitly requests it
• Use group-level language: "a minority of participants", "some participants expressed..."
• Reserve named feedback for clearly positive observations, or for significant blockers that management needs to address directly