← ClaudeAtlas

chameleon-initlisted

Use when the user explicitly invokes /chameleon-init to bootstrap a chameleon profile for the current repository (TypeScript/JavaScript, Ruby, or Python — framework-agnostic, with deeper awareness for Rails and Django/DRF/Flask/FastAPI)
crisnahine/chameleon · ★ 9 · Code & Development · score 76
Install: claude install-skill crisnahine/chameleon
# /chameleon-init Bootstrap a chameleon profile for the current repo, then auto-apply rename proposals so the archetype labels match the team's vocabulary without a user interview. Profile artifacts are written atomically via the commit-marker pattern. ## When to use User runs `/chameleon-init` in a TypeScript/JavaScript, Ruby, or Python repo that does not yet have a `.chameleon/` directory. chameleon supports these three as first-class languages and is framework-agnostic by default — it learns the repo's own conventions, so any framework works — with deeper, framework-aware guidance where conventions are strong (Rails for Ruby; Django, DRF, Flask, FastAPI for Python). If `.chameleon/profile.json` already exists, suggest `/chameleon-refresh` instead — running init twice would overwrite the existing profile. ## The flow (overall) 1. Confirm the repo's language: TypeScript/JavaScript (`tsconfig.json` or TS in `package.json` deps), Ruby (`Gemfile`, or `config/application.rb` for Rails), or Python (any `.py` source files — `setup.py` counts). `pyproject.toml` / `requirements.txt` / `manage.py` / `Pipfile` mark a Python framework, but the repo needs actual `.py` source to profile: a manifest-only repo with no `.py` files has nothing to cluster and bootstrap returns `failed_unsupported_language`, so don't announce it as ready-to-bootstrap on a manifest alone. 2. **Determine the production branch** (the branch the profile derives from, regardless of what i