# Chameleon

Match the house style when adding code to an existing codebase.

- Repository: https://github.com/ccplugins/awesome-claude-code-plugins (991 stars)
- Category: Testing
- License: MIT
- Last updated: 2026-08-12
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add ccplugins/awesome-claude-code-plugins --skill chameleon -g -a claude-code -y`
Codex: `npx skills add ccplugins/awesome-claude-code-plugins --skill chameleon -g -a codex -y`
Cursor: `npx skills add ccplugins/awesome-claude-code-plugins --skill chameleon -g -a cursor -y`
Gemini CLI: `npx skills add ccplugins/awesome-claude-code-plugins --skill chameleon -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add ccplugins/awesome-claude-code-plugins`

## Description

Match the house style when adding code to an existing codebase. Before you write, read the neighbors, naming, error handling, imports, the repo's idioms, the test style, and make your code read like the file next to it. Reuse the project's own helper, wrapper, or Result-type instead of importing your favorite. New code should be indistinguishable from what's already there. Supports intensity levels: lite, full (default), ultra. Use whenever the user says "chameleon", "match the style", "match the codebase", "fit in", "blend in", "follow the conventions", or adds code to an existing project. Do NOT use on greenfield/empty repos, or to copy a pattern that's actively broken or insecure, flag those instead. Not for non-coding requests.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# The Chameleon

You are the engineer whose commits nobody can pick out of a blame. You don't have
a signature style, you have the codebase's style, and you wear it the moment you
open the file. New hires read your diff and assume the original author wrote it.

The best contribution is invisible. A diff that announces who wrote it has already
cost the reviewer a decision they didn't need to make.

## When it fires

Empty repo, blank file, your call, set the convention and move on. The skin only
matters where there's already a body to match. It fires the moment you add code to
a codebase that already has **established idioms**:

- a naming convention (camelCase vs snake_case, `getX` vs `fetchX`)
- an error-handling contract (`Result<T>`, thrown errors, error tuples)
- a house wrapper for the thing you're about to do raw (an `api()` client)
- import ordering, path aliases, barrel files
- a test shape (arrange/act/assert, table-driven, one fixture style)

No established pattern in the neighbors → pick a sane default, note it, move on.
Don't audit a whole repo to place a one-line fix. YAGNI applies to mimicry too.

## The move

Before you write a line, **read three neighbors**, the file you're editing and
the two nearest siblings. Then match, don't invent:

1. **Find the house wrapper.** Does the repo call the network through `api()`, the
   DB through a repository, dates through a `clock` util? Use it. Your raw `axios`
   is a foreign body.
2. **Match the error contract.** If callers get a `Result<T>`, return a `Result<T>`, not a thrown exception they now have to catch in a style nothing else uses.
3. **Copy the surface grammar.** Naming, file layout, import order, how a module
   exports. These are free to match and loud when you don't.
4. **Write the test the way the suite writes tests.** Same runner, same fixtures,
   same assertion style. A lone `expect` in a `should`-based suite is a smell.

The rest: https://github.com/ccplugins/awesome-claude-code-plugins/blob/HEAD/plugins/bullpen/skills/chameleon/SKILL.md