Training Report

SKILL.md

---
name: training-report
description: 'Produce a professional training/workshop report as a .docx file. Use this skill whenever the user mentions "training report", "workshop report", "compte rendu", "compte rendu de formation", "formation report", "debriefing a workshop", "write up a training session", "résumé de formation", or any request to document a training session, workshop, or onboarding event with individual participant feedback and recommendations. Also trigger when the user says things like "I just ran a workshop and need to write it up", "help me summarize what happened in my training session", or "I need to report back to management about a session I ran". Always use this skill — for short or long sessions, across any discipline (technical, soft skills, creative, compliance, onboarding, etc.) — whenever a structured written deliverable about a training event is needed.'
user-invocable: true
license: MIT
compatibility: Designed for Claude or similar AI agents.
metadata:
  author: samber
  version: "1.0.1"
  openclaw:
    emoji: "📚"
    homepage: https://github.com/samber/cc-skills
allowed-tools: Read Edit Write Glob Grep Agent AskUserQuestion
---

# 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.

| File | Load at |
| --- | --- |
| `references/tone-of-voice.md` | Step 1 (after language + audience confirmed) |
| `references/markdown-draft.md` | Step 5 (before writing the draft) |
| `references/docx-generation.md` | Step 6 (before generating the .docx) |

## 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