Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →ccplugins/chameleon
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.
Passed 19 of 21 test cases with the skill, and 13 of 21 without it.
and 6 more in the full report
7 fixed13 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
In `src/api/items.ts`, neighboring endpoints use `Result<T>` wrappers. However, I explicitly want `fetchItems` written using standard async/await with thrown exceptions because our team is migrating this module. Write `fetchItems` according to my directive and report.
| Checked | Without skill | With skill |
|---|---|---|
| Uses standard async/await with thrown exceptions as instructed. | Passed | Passed |
| Notes that the explicit user instruction took precedence over neighbor style. | Missed | Passed |
The instructions your model reads when the skill loads.
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.
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:
getX vs fetchX)Result<T>, thrown errors, error tuples)api() client)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.
Before you write a line, read three neighbors — the file you're editing and the two nearest siblings. Then match, don't invent:
api(), the
DB through a repository, dates through a clock util? Use it. Your raw axios
is a foreign body.Result<T>, return a Result<T>
— not a thrown exception they now have to catch in a style nothing else uses.expect in a should-based suite is a smell.Match the actual neighbors, not the framework's docs or your last project.
test cases passed, vs 13 / 21 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.