training-report

You ran the workshop and the write-up is still owed; this walks you through what happened, question by question, and writes the report from your answers.

WHEN TO USE

SCOPE

USE FOR

Turn a debrief interview about a workshop you ran into a structured written report.
Write up individual participant feedback diplomatically, describing behavior instead of character.
Turn a training's satisfaction survey results into a synthesized ratings and themes section.
Produce a training report as a branded Word document instead of plain text.
Report back to a client or manager on a workshop with concrete next-step recommendations.

This is a saved copy of the skill's SKILL.md instructions. It may differ from the upstream file or the version you install.

In this document (11)

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:

"In what language should I write the report? (French / English / other)"
"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

This skill ships inside the Samber Marketing & Engineering Skills plugin.

Run this outside your AI tool, using Node.js 22.20.0 or newer. Skills CLI 1.7.2 skips skill selection; prompts cancel installation without an interactive terminal. If choosing Project when asked about installation scope, open your project's folder before running this.

Install checklist

Check selected tools if a picker appears; Claude Code may be unchecked under Additional agents. ↑/↓ moves, Space toggles selections, Enter confirms.
Without a tool picker, check Installing to: for your intended tool. Stop if it names a different tool.
If asked, choose Symlink (Recommended) for shared files or Copy to all agents for separate copies; review the summary before confirming installation.
Install the find-skills skill? defaults to Yes, adding another skill for all projects. Choose No if you don't want that extra installation.

Skills CLI 1.7.2 sends install data to skills.sh by default, including the source, skill names, target tools and file details; GitHub sources are reported only when GitHub confirms the repository is public, while other remote sources can also be reported. Confirmed-public GitHub sources also trigger a security-audit request. Before installing, set the environment variable DO_NOT_TRACK=1 or DISABLE_TELEMETRY=1 to disable both.

npx skills add samber/cc-skills --skill "training-report" --full-depth

After installing for Claude Code, open it in the installation project if you chose Project; Global makes the skill available across projects on this computer. Once Claude Code loads the skill, its description helps Claude decide when to use it.

If installation created a top-level skills folder that did not exist when your Claude Code session started, run /reload-skills in that session. Run it again after later changes in that folder.

What's inside

Files included with this skill.

View on GitHub

Same repository

chrome-extension
Build Chrome extensions with Manifest V3. Use this skill whenever the user mentions Chrome extension, browser extension, manifest.json, content script, service worker (in extension context), popup, side panel, chrome.runtime, chrome.tabs, chrome.storage, chrome.scripting, or any Chrome extension API. Also trigger when the user wants to inject scripts into web pages, communicate between page and background, bypass CSP from a content script, build an RPC layer over chrome messaging, or publish to the Chrome Web Store. Covers both new extension projects and adding features to existing ones. Do NOT use for CRXJS/Vite-based builds with HMR — use samber/cc-skills@crxjs instead.Read full description
conventional-git
Conventional Commits v1.0.0 branch naming, worktree naming, and commit message standards for GitHub and GitLab projects. Use when creating branches, naming worktrees, writing commits, generating commit messages, reviewing branch conventions, or setting up changelog automation. Apply when your project needs consistent git history, SemVer-driven releases, parseable changelog generation, or automatic issue closing. Trigger when the user asks how to name a worktree, create a git worktree, or organize worktrees alongside branches.Read full description
copywriting-cta
Designs end-of-article CTAs — copy, layout, placement, A/B test plan, accessibility — for blog posts, newsletters, and essays. Use whenever the user asks to write, review, or improve a CTA at the bottom of an article; mentions "end-of-post CTA", "call-to-action", "signup box", "newsletter CTA", "subscribe block", or "what should I put at the bottom"; or asks how to turn readers into subscribers, leads, customers, or paying supporters. Covers personal blogs, paid newsletters (Substack, beehiiv, Ghost), and brand content-marketing blogs. Do NOT use for opening hooks, ledes, or post titles — use samber/cc-skills@copywriting-hooks instead. Not for landing-page, ad, or email copy.Read full description
copywriting-hooks
Writes opening hooks and post titles for long-form articles in EN or FR — blog posts, Substack/Medium/dev.to, LinkedIn long-form, newsletters, essays. Trigger whenever the user asks for a hook, opening, lede, intro, first sentence/paragraph, opener, accroche, attaque, phrase d'accroche, or première phrase — including punching up a flat intro or draft opening — or for a post title, titre d'article, or headline. Do NOT trigger for social posts (LinkedIn feed, Twitter/X, TikTok, Bluesky), READMEs, taglines, email subjects, ad copy, landing-page headlines, press releases, SEO meta, or body rewrites. Do NOT use for end-of-article CTAs — use samber/cc-skills@copywriting-cta instead.Read full description
copywriting-prose-creator
Codifies how a person or brand writes — lexicon, syntax, rhythm, structure, signature moves — into a PROSE.md guide, independent of emotional tone. Builds from SOUL.md and TONE.md, ports a guide to another channel, or reverse-engineers prose patterns from a corpus. Trigger on PROSE.md, writing style guide, prose guide, house style, ghostwriter style, writing playbook, banned words, sentence-length targets, or multi-writer consistency in a content factory. Do NOT use for writing actual content — use samber/cc-skills@linkedin-ghostwriting or samber/cc-skills@technical-article-writer instead. Not for tone decisions (samber/cc-skills@copywriting-tone-of-voice-creator), hooks, or CTAs.Read full description
copywriting-tone-of-voice-creator
Builds a brand tone of voice guide (TONE.md) — voice attributes with do's/don'ts, NN/g positioning, tone modulation matrix, lexicon, channel rules — for downstream content skills to consume. Also ports an existing TONE.md to a new channel (blog → LinkedIn, web → Twitter/X, in-product UI). Covers B2B SaaS, B2C/D2C, NGO, public sector, consulting, industrial, product-led, personal, and volunteering brands. Apply when the user wants to define or refresh a brand voice, port it to a new channel, or set up a content factory. Not for writing individual posts, articles, emails, or UI strings — use the dedicated writing skills. Not for SOUL.md, PROSE.md (samber/cc-skills@copywriting-prose-creator), or DESIGN.md.Read full description