Communications kit

Launch announcements, an exec-sponsor note, a pilot invite, a weekly tips campaign and FAQ replies for rolling Claude Code out to engineers.

This is the copy I reach for when a client asks me to help them launch Claude Code to their engineers. It has a launch checklist, announcement drafts for email and chat, a set of weekly tips to keep adoption moving, and short answers to the questions that always come up.

Note: Treat every message here as a first draft. Rewrite it in your organisation's voice, replace the [bracketed] placeholders, and swap my example tasks for real bugs and modules from your own codebase. The launches that work are the ones that sound like a colleague wrote them.

Before you announce anything

Run through this list first. Each item prevents a specific launch-day support thread.

A channel exists (#claude-code or similar) and the announcement links to it, so questions land in one place.
Someone has installed it on a real company machine. Proxies, TLS inspection and firewalls break installs; find out before 300 people do. See Network configuration.
A data-handling link is ready. "Where does my code go?" will be the first reply. Use Data usage or your internal equivalent.
One concrete first task is chosen. "Try it on something" converts nobody. "Fix the intermittent failure in checkout_spec.rb" does.
A named person owns the channel for the first two days. Unanswered questions on launch day kill momentum faster than anything.
An executive sponsor has agreed to send or co-sign it. In my experience, launches sent under a senior leader's name get noticeably more people trying it in week one than ones from a tooling team.

The launch announcement

Email version

Subject: Claude Code is now available to [team]

Hi all,

From today you can use Claude Code. It's an AI coding agent that runs in
your terminal against our real repositories. You describe a task, it reads
the code, edits files and runs commands, and you review what it did. Think
"pair who does the typing", not autocomplete.

Setup takes a couple of minutes:

    curl -fsSL https://claude.ai/install.sh | bash
    cd <a repo you work in>
    claude

Once you're in, type /init. Claude reads the project and writes a CLAUDE.md
with our build commands and conventions, so you don't have to explain them
every session.

Then give it something real. Some ideas:

  - "[test file] fails about one run in ten. Find out why and fix it."
  - "Explain how [service] decides [behaviour], with file references."
  - "Review my uncommitted changes and flag anything risky."

Your code: Claude Code runs locally and sends requests to Anthropic's API.
Under our [Team / Enterprise] agreement, Anthropic does not train models on
our code or prompts. More detail: [data handling link]

Questions go in #claude-code. [Owner] is looking after it this week.

[Your name]

PS: If you live in your editor, there are extensions for VS Code and
JetBrains with the same agent inside.

Chat version

*Claude Code is live for [team]*

An AI agent in your terminal that works on our actual repos: bugs,
refactors, tests, PRs.

Install: curl -fsSL https://claude.ai/install.sh | bash
Then: cd your-repo && claude

First thing: run /init, then try "[test file] is flaky, find out why and fix it".

Data: runs locally, talks to Anthropic's API. Our code and prompts aren't
used for training under our plan. [data handling link]

Getting started: [quickstart link] · VS Code: [extension link]
Questions in this thread. [Owner] is on it.

For the links, point people at your internal wiki or at pages such as Quickstart, VS Code and Data usage.

Send this from the CTO, CIO or VP Engineering, from their own account. It deliberately makes one ask only; the standard announcement and the channel handle the detail.

Subject: Ten minutes this week, please

Team,

We've switched on Claude Code across engineering. It's an AI agent that
works in your terminal on our real code, and the teams who've been using it
have seen enough that I'd like everyone to try it this week.

My ask is ten minutes:

    curl -fsSL https://claude.ai/install.sh | bash
    cd <your repo>
    claude

Then hand it one real job: the bug you keep deferring, or "explain how
[system] works".

That's all. [Owner] and the team are in #claude-code if you get stuck.

[Name]
[Title]

A chat version is the same three lines: we have switched it on, please give it ten minutes on real work, questions in #claude-code.

Pilot cohort invite

For a phased rollout, send this to the pilot group only.

Subject: Welcome to the Claude Code pilot

[Names],

You're the first group at [company] to get Claude Code. We picked you
because you'll use it on real work and tell us honestly how it went.

What we need: use it on at least one genuine task this week, then post in
#claude-code-pilot what helped, what got in the way and what surprised you.
Your feedback shapes how we roll it out to everyone else.

[Paste the setup steps from the main announcement]

One tip for pilots: before your first change that spans several files,
press Shift+Tab until the mode shows "plan". Claude will set out what it
intends to change without touching your code, which is the quickest way to
judge how far to trust it.

Recruiting champions

A week or two after launch, message the two or three people posting most in the channel. The champion kit is the playbook you send them.

Hi [name], I've noticed your posts in #claude-code. A couple of people
mentioned your [thread / screenshot] is what got them to try it.

Would you be up for making that a bit more official? It's light: keep
sharing what you're already sharing, get early access to new features, and
a direct line to us for feedback. Happy to send over a short guide.

Weekly tips campaign

After launch, post one or two of these a week in the channel. Each one follows the same shape: the problem, the fix, one thing to try right now, and a pointer to the handbook page. They are independent, so pick the ones that match gaps you are seeing.

Choosing a model

*Tip: pick the model for the job*

Running the biggest model on a one-line fix wastes time and budget.
Running the smallest on a twelve-file refactor means doing it twice.

Switch at any point with /model.
  - Sonnet: the everyday default for features, fixes, tests and reviews
  - Opus: large refactors, tricky debugging, high-stakes changes
  - Haiku: quick questions and mechanical edits where speed matters
  - Fable: the most capable option for the hardest, longest tasks.
    Opt-in only, with /model fable

Try it: run /model and check which one you're on.

Model	Reach for it when
Fable	The hardest, longest-running work. Not the default; choose it with `/model fable`. Cybersecurity and biology content automatically falls back to Opus
Opus	Big refactors, complex debugging, architectural decisions. On Opus 5.5 and Opus 5, flagged cybersecurity or biology content falls back to an earlier model or is refused
Sonnet	Most day-to-day work, and the recommended default. On Sonnet 5.5, flagged content falls back or is refused
Haiku	Fast questions, formatting and repetitive edits

Model configuration has the details of fallback behaviour.

Your first ten minutes

*Tip: three things to try today*

Not sure what to ask? Start with whatever annoyed you this week.
  - "The test in [file] fails intermittently, work out why"
  - "Walk me through [module] like I've never seen it"
  - "Check my diff before I push and tell me what worries you"

No setup needed beyond cd-ing into your repo and running claude.

Project memory with /init

*Tip: stop repeating yourself*

If you've told Claude "we use pnpm" more than once, run /init in that repo.
It writes a CLAUDE.md with build commands and conventions, and every future
session reads it. Keep it short: a cheat sheet, not a manual.

Try it: open your main repo, run claude, type /init.

See Memory.

Pointing at files with @

*Tip: don't paste code into the prompt*

Type @ and a path and Claude reads the file itself. Directories work too:
"which components in @src/ui/ have no tests?"

Try it: type @ and press Tab to browse.

Permission modes

*Tip: Shift+Tab changes how much Claude does without asking*

  - Manual (the "default" setting): asks before edits and most commands
  - acceptEdits: lets file edits and common filesystem commands through,
    still asks about other commands
  - plan: researches and proposes, no edits to your source

Plan mode is the best way to build trust on anything multi-file.

Try it: on your next refactor, Shift+Tab to "plan" and describe the change.

See Permission modes.

Undo with /rewind

*Tip: you can rewind*

Went down the wrong path three turns ago? Don't fix forward. Press Esc
twice, or type /rewind, and pick a point before it went wrong. File
changes Claude made are rolled back too. It's automatic, nothing to set up.

See Checkpointing.

Connecting your tracker with MCP

*Tip: let Claude read the ticket*

Copying tickets into the terminal is busywork. An .mcp.json at the repo
root connects Claude to GitHub, Jira, Linear and others, so "what's my
top-priority issue?" and "fix it" happen in one conversation.

Try it: ask Claude to "set up an MCP server for [tracker] in this repo".

See MCP.

Skills for repeated prompts

*Tip: turn a prompt you keep retyping into a command*

A SKILL.md inside .claude/skills/<name>/ becomes /name. The second time you
type the same multi-step prompt, make it a skill. Easiest way: ask Claude.

Try it: "make me a /release-notes skill that summarises merged PRs since
the last tag".

See Skills.

Hooks for notifications

*Tip: get a ping when a long task finishes*

A Stop hook runs a command when Claude finishes. Point it at a desktop
notification and you can walk away from long refactors.

Try it: ask Claude to "add a Stop hook that shows a desktop notification".

See the hooks guide.

Screenshots

*Tip: show, don't describe*

Drag a screenshot into the terminal, or paste with Ctrl+V (Alt+V on
Windows and WSL). Error dialogs, mock-ups, whiteboard photos all work.

Try it: next time the UI breaks, paste a screenshot and ask "what's wrong?"

Git chores

*Tip: let Claude handle the commit and PR*

"Fix the off-by-one, commit it with a conventional message and open a PR"
is one request. Reviewing a colleague's PR? Paste the URL and ask for a
walkthrough of the diff.

See Common workflows.

Plugins

*Tip: check before you build*

About to write a /deploy skill? Someone may have shipped one. /plugin
browses and installs plugins in one step.

See Install plugins.

The security answer

*Tip: the short answer to "is this safe?"*

Permission modes decide what Claude can do without asking. The CLI runs on
your machine, talks to Anthropic's API, and can sandbox shell commands at
the OS level. Under our plan, our code and prompts aren't used for
training. Detail: [security link] and [data handling link]

See Security.

Habits that stick

*Tip: four habits of people who keep using it*

  - Start in plan mode for anything touching several files
  - Run /init early
  - Read diffs before committing; it can be confidently wrong
  - Double-check anything on a critical path

Pick the one you skip and do it on your next task.

See Best practices.

FAQ replies

Question	One-line answer
Does it work in my editor?	Yes, there are VS Code and JetBrains integrations with the same agent
Do I need to configure anything?	No. Install it, run `claude` in a repo, then `/init` once. See Quickstart
Where does my code go?	It runs locally and sends context to Anthropic's API; under a Team or Enterprise plan it is not used for training. See Data usage
Can it see the whole repo?	It reads what you let it. Reads inside the working directory do not prompt. See Permissions
How is it different from Copilot?	Copilot completes lines; Claude Code is an agent that reads files, runs commands and makes multi-file changes. See Overview
What should I try first?	A tedious bug you have been avoiding

Starter prompts

Hand these to people who have installed it but stalled. Replace the brackets with real paths.

Task	Prompt
Fix a failing test	"the tests in [file] are failing, find the cause and fix it"
Learn a module	"explain how [module] works and where execution starts"
Careful refactor	"refactor [module] to [goal]; use plan mode so I can review first"
Add tests	"write tests for [file] covering the edge cases around [scenario]"
Pre-commit review	"review my uncommitted changes and flag anything risky"
Ship a fix	"fix [issue], commit with a conventional message and open a PR"
Build a skill	"make me a /preflight skill that runs lint and tests before a commit"
Root-cause a crash	"here is the stack trace; find the root cause rather than patching the symptom"

Tip: Claude Code changes quickly. Check commands and version-specific behaviour against this handbook before you send anything company-wide.