Claude Code Spinner Verbs: A Team Playbook for Personality

I used to ignore loading microcopy.

Then I noticed something weird: my team spends hours in tools where tiny pieces of language repeat all day long. If that language is generic, we tune it out. If it is intentionally designed, it can improve energy and create small moments of identity.

That is why this post exists. After reading Alexop's How I Turned Claude Code's Thinking Indicator into a One Piece Adventure, I adapted the same idea for team workflows: use claude code spinner verbs not just for fun, but as a lightweight layer of culture and consistency.

If you are new to our workflow stack, start at home, browse the blog, and pair this with Motion Without Jank and WordPress to Next.js Migration Playbook.

Hook

Most teams talk about developer experience at the big level: CI speed, flaky tests, editor setup, docs quality.

All of that matters.

But small interface text matters too, especially in high-frequency surfaces. Spinner text is one of those surfaces. Developers see it dozens or hundreds of times per day.

When that text is intentional, two things happen:

1. the tool feels more human and less sterile;
2. your team gets a tiny but consistent signal about tone and identity.

The key is to keep personality without turning the interface into noise.

Claude code spinner verbs: the setting that powers it

The mechanism is straightforward: Claude Code supports a spinnerVerbs config. You set mode and provide a list of verbs/phrases.

Use user-level config:

{
  "spinnerVerbs": {
    "mode": "replace",
    "verbs": [
      "Mapping the scope",
      "Pressure-testing assumptions",
      "Composing the patch",
      "Tracing edge cases"
    ]
  }
}

Add this to ~/.claude/settings.json, then restart Claude Code.

If you want project-specific conventions for a team, use project-level settings instead of global user defaults so language stays consistent inside the repo.

Replace vs append: how to choose

You have two practical modes:

• replace: show only your custom verbs.
• append: mix your verbs with defaults.

I recommend deciding this by workflow maturity.

If your goal is a branded daily experience, replace usually works better.

The phrase design system I use

Most teams jump straight to "funny phrases." That works for one day and gets old by day five.

I use a design system with constraints:

Rule 1: keep each phrase short

Long spinner text wraps poorly and creates visual friction.

Target 2-5 words when possible.

Rule 2: prefer action language over jokes

Humor is good in moderation, but action-focused phrases age better.

Good:

• "Tracing dependencies"
• "Drafting solution paths"

Less useful:

• random meme references with no context.

Rule 3: group verbs by intent

I organize phrases into categories:

• analysis (understanding, exploring, mapping),
• execution (building, patching, shipping),
• validation (testing, checking, verifying),
• polish (refining, tightening, documenting).

This creates tonal variety while staying coherent.

Rule 4: avoid terms that create false certainty

Do not use phrases that imply completion when work is still in progress, such as "done" or "fixed." Keep it process-oriented.

Rule 5: review quarterly

Language drifts as team priorities change. Refresh the list every quarter and remove stale phrases.

My starter list for product and growth teams

Here is a 30-item starter pack you can use or adapt:

[
  "Mapping the problem",
  "Parsing the context",
  "Reading constraints",
  "Comparing tradeoffs",
  "Tracing dependencies",
  "Locating bottlenecks",
  "Drafting approach",
  "Composing the patch",
  "Staging the rollout",
  "Shaping the flow",
  "Polishing microcopy",
  "Refining hierarchy",
  "Testing assumptions",
  "Running QA checks",
  "Validating edge cases",
  "Checking fallback paths",
  "Hardening behavior",
  "Smoothing interactions",
  "Tightening latency",
  "Guarding accessibility",
  "Reviewing metrics",
  "Calibrating signal",
  "Aligning the brief",
  "Stress-testing logic",
  "Preparing handoff",
  "Cleaning artifacts",
  "Updating docs",
  "Packaging insights",
  "Locking confidence",
  "Shipping with care"
]

This list is neutral enough for serious work but still has personality.

If I had to roll this out from zero today

If I needed to implement this across a team this week, I would use this sequence.

Day 1: define tone boundaries

• Decide tone (serious, playful, or mixed).
• Set banned patterns (inside jokes that do not scale, ambiguous slang, inflammatory words).
• Pick owner for list quality.

Day 2: create phrase bank

• Draft 40-60 candidates.
• Remove anything too long.
• Keep final set to 20-35 phrases.

Day 3: run readability test

• Test in your actual terminal width.
• Check legibility in dark and light themes.
• Remove phrases that visually clutter spinner area.

Day 4: choose mode and scope

• append for trial rollout.
• replace once stable.
• Choose ~/.claude/settings.json (personal) or project settings (team-level).

Day 5: document and ship

• Add one short README section with intent and update process.
• Include "how to opt out" for personal preference where appropriate.
• Ship and gather feedback after one week.

Small rollout, fast feedback, low risk.

Examples and counterexamples

Counterexample: pure meme list

A list of 40 meme references can feel fresh for two days, then become distracting.

Better: balanced list

A mixed set where 80% are practical action phrases and 20% add flavor tends to survive longer.

Counterexample: no ownership

Without an owner, phrase lists decay and become inconsistent across machines.

Better: one maintainer, lightweight review

Assign one editor and review changes in normal PR flow.

Counterexample: team-wide forced rollout without context

People resist changes they do not understand.

Better: intent-first rollout

Explain that the goal is clarity + identity, not novelty.

Mistakes to avoid

1. Phrases that are too long for terminal width.
2. Over-optimized humor that harms readability.
3. No distinction between personal and team-level settings.
4. Changing phrases too often, causing fatigue.
5. Treating this as cosmetic only instead of part of DX quality.
6. Forgetting to test in real tool usage conditions.

Team rollout checklist

• Selected append or replace intentionally.
• Phrase list capped and readability-tested.
• Team owner assigned for ongoing edits.
• Settings scope documented (user vs project).
• Baseline list added to onboarding docs.
• One-week feedback loop scheduled.
• Quarterly refresh cadence defined.

FAQ

Do spinner verbs actually improve productivity?

Not directly in a measurable "hours saved" way. Their value is usually in tool feel, consistency, and reducing interface fatigue.

Should we use one global list for all repos?

For personal workflows, global is fine. For teams, project-scoped settings usually create better alignment.

Is replace always better than append?

No. append is safer for early experiments. replace is stronger when you want consistent identity.

How many verbs should we keep?

I usually keep 20-35. Fewer can feel repetitive, more can dilute quality.

Can this become distracting?

Yes, if phrases are long, chaotic, or joke-heavy. Keep them concise and action-oriented.

Should we localize language across regions?

If your team is multilingual, choose one default working language for shared settings and offer local variants for personal scope.

Conversion CTA

If you want help building a stronger UX voice system across your product touchpoints (site microcopy, UI states, docs, and tooling language), I can help you design and operationalize it.

• Start on WhatsApp
• Or send context by Email

You can also read our related operating guides: B2B Homepage That Converts and Motion Without Jank.

Closing synthesis

The point of claude code spinner verbs is not novelty. It is intentionality.

When repeated interface language is designed with the same care as layout, motion, and system architecture, the whole workflow feels more coherent.

That coherence compounds. Small text decisions, repeated every day, shape how teams experience their tools and how seriously they treat quality.