Champion kit
A practical playbook for engineers spreading Claude Code on their team: what to share, how to answer questions, a 30-day plan and replies to sceptics.
This page is for the engineer who already uses Claude Code and wants their team to get the same benefit. Tooling rarely spreads because of an announcement. It spreads because one person uses it well, talks about it in the open and makes it easy to copy. That is what a champion does, and it costs far less time than people expect.
The job in three parts
| Part | In practice | Why it works |
|---|---|---|
| Show your work | Post prompts, screenshots and small wins where the team already reads | Examples from your own codebase beat any documentation, because colleagues recognise the problem |
| Answer with something runnable | When someone asks "how did you do that?", reply with the exact prompt | A prompt they can paste closes the gap between curiosity and a first success |
| Make it self-sustaining | Set up a channel or a weekly thread that keeps going without you | Adoption that hangs on one person stalls when they get busy |
Time budget
Agree this with your lead so it stays a multiplier on your work, not a second job as a helpdesk.
| Activity | Per week | How |
|---|---|---|
| Posting wins and prompts | ~15 minutes | Screenshot plus a sentence, in the moment. No write-ups |
| Answering questions | ~20 minutes | Answer once in public, then link to it next time |
| Weekly show-and-tell thread | ~5 minutes | You post the question; others bring the content |
| Pairing | 0 to 30 minutes | Only for people who are stuck, and send the Quickstart first |
Show your work
What is worth posting
Post techniques someone can reuse tomorrow, not finished outcomes. "I shipped X" is a status update; "here is how I got it to do X" spreads. Some that have landed well on teams I have worked with:
- "You can @ a whole folder. I asked which handlers in
@api/routes/had no input validation and it found three." - "I put Claude in plan mode before touching the billing code. It laid out every file it wanted to change, and I struck one off before it started."
- "Added a Stop hook that plays a sound when it finishes. Kicked off the migration and made a coffee. Config in thread."
- "
/initwrote our CLAUDE.md in thirty seconds. I added the 'never touchvendor/' rule and it has respected it since."
Where to post
| Place | Good for | Format |
|---|---|---|
#claude-code or a general engineering channel | Discoveries and prompts | Screenshot and one or two lines |
| Pull request descriptions | Showing the approach on code reviewers are already reading | "Did this refactor with Claude; happy to walk through how" |
| Standups or weekly updates | Making it normal in front of leads | One sentence, one concrete result |
| Team wiki | Durable patterns, shared skills, CLAUDE.md examples | A short page linked from the channel topic |
Keep it short
A screenshot and a line, or a quick before and after, is the right size. People copy short posts and bookmark long ones, and bookmarks are where good ideas go to die. Write in your own voice; these are just for length and tone:
TIL @-mentioning a directory works. Asked which files in @services/payments/
had no tests and it listed four. Two of them handle refunds.
Plan mode is why I'm happy using this on shared code. Shift+Tab until it
says "plan" and it tells you exactly what it wants to change first.
Be the person people ask
Reply with the prompt
The best answer to "how did you get it to do that?" is the prompt itself.
Them: How did you get it to spot the deadlock?
You: I said "The job in @workers/sync.py hangs under load, find out why".
It found two locks taken in opposite orders. Try the same wording on yours.
Point at the feature, not the manual
"Press Shift+Tab until you see plan" helps more in the moment than a link. If they want depth they will find it.
Questions you will get
| Question | What to say | Where to send them next |
|---|---|---|
| What should I try first? | A real but contained chore they have been putting off because it is boring, not hard | Common workflows |
| How can I trust it with my code? | Plan mode: Claude researches and proposes without editing | Permission modes |
| Is setup a faff? | Two-minute install, runs in the terminal, /init once and go | Quickstart |
| It got it wrong | Paste the error or failing test back in. Feeding back the failure beats rephrasing the request | Common workflows |
| It ignores our conventions | Run /init, then add conventions, test commands and no-go directories to CLAUDE.md | Memory |
| Isn't this just autocomplete? | Show it: have it explain an unfamiliar file, trace a bug across services or draft a migration plan | A two-minute live demo |
| What about security and data? | Defer to your admin. The organisation's policy is already set and champions should not improvise it | Security, Data usage |
Make it self-sustaining
You are not running a programme. Success is the day questions in the channel get answered by someone other than you.
| Habit | How | Effort |
|---|---|---|
| A dedicated channel | Create #claude-code (or a standing thread), pin the Quickstart and one strong example, answer in public | Five minutes, then ambient |
| Friday show-and-tell | Post "What did Claude help you with this week?" No slides, no meeting | Two minutes a week |
| Share a skill | Post your best .claude/skills/<name>/SKILL.md, say a /preflight that runs lint and tests before committing. It is plain Markdown, so people adopt it instantly | Five minutes per skill |
| Generate an onboarding guide | Run /team-onboarding in a project you know well. It looks at your recent sessions, commands and MCP servers and writes a guide a new teammate pastes as their first message to replicate your set-up. Pin it | Two minutes |
| Pair once | Fifteen minutes with someone new, on their code. One win on their own work beats any demo | Fifteen minutes per person |
| Find the next champion | Whoever asks you the most questions is usually ready. Send them this page and split the channel duties | Negligible |
Skills covers the skill format if you have not written one yet.
A 30-day plan
Loose, and adjust to taste.
Week 1: seed it. Create the channel, pin the Quickstart, post two or three of your own examples with the prompts. Working if: a few reactions and at least one question.
Week 2: set a rhythm. Start the Friday thread, answer everything in public, share one skill or CLAUDE.md snippet. Working if: someone else posts their own example.
Week 3: pair and consolidate. Offer two or three short pairing sessions and turn the most common questions into a pinned FAQ. Working if: the same people keep coming back rather than trying once.
Week 4: hand over. Recruit a second champion and send your lead or admin a short note on what is and is not working. Working if: other people are answering questions.
When someone wants more
You are the warm introduction, not the training course. Once a colleague is past "should I bother?" and into "how do I get good at this?", send them to the Quickstart, Common workflows and Best practices.
Handling sceptics
Scepticism about tools that touch code is healthy. Do not argue the general case. Acknowledge it, reframe briefly, and offer one demonstration on their own code. Most concerns dissolve after one good experience.
| Concern | Reframe | What to show |
|---|---|---|
| "I'm faster without it" | Probably true for code you write every day. Try it on what you avoid: legacy files, unfamiliar services, test scaffolding | Time one tedious task both ways |
| "I don't trust AI near production" | Agreed, nothing should land unread. Use plan mode, then review the diff like any PR | Plan mode on a real file |
| "It'll make juniors worse" | Used well it is a patient explainer. Have juniors ask it to explain before asking it to change | "Explain @file and everywhere it is called from", together |
| "I tried it and it made things up" | Usually missing context, not a bad model. Add @ references, run /init, give it the real error | Re-run their prompt with proper context |
| "No time for another tool" | It is a terminal command, not a platform. If the first session is not worth it, drop it | Two-minute install, one real bug |
Cheat sheet to pin
| Technique | How |
|---|---|
| Give it context | @file or @dir/, or paste the actual error or log. Context beats clever prompting |
| Plan before editing | Shift+Tab into plan mode |
| Teach it the repo | /init, then add conventions, test commands and off-limits paths. See Memory |
| Reuse a workflow | A SKILL.md in .claude/skills/<name>/ becomes /name for the whole team |
| Walk away from long tasks | A Stop hook that notifies you. See the hooks guide |
| Recover from a wrong answer | Paste the failing test or stack trace back and ask it to fix that specific failure |
| Keep changes tight | Ask for a diff, or say "only change X". It respects stated scope |
Tip: Claude Code ships often. Check anything version-specific against this handbook before you share it widely.