Learn and apply the coding style of any project so your code blends seamlessly with existing work — from open-source repositories to enterprise production systems.
When working in a new or unfamiliar codebase, it's easy to write code that doesn't match the team's existing style. This leads to:
- Code review comments about style inconsistencies
- Time wasted fixing style issues after review
- Embarrassment when the team leader criticizes your code
- Security or architecture violations caught late in review
- New hires taking weeks to internalize unwritten conventions
This skill automatically scans any project's codebase to extract style patterns, then provides clear actionable guidelines to follow when writing new code. The result: code that looks like it was written by the team themselves — from day one.
- Automatic Style Detection: Scans code files to extract naming conventions, import organization, function patterns, comment styles, and more
- Config-First Analysis: Reads
.eslintrc,pyproject.toml,.golangci.yml, and other lint configs as the authoritative source before scanning source files - Conflict Resolution: When the codebase has mixed styles, applies a decision tree to determine which convention to follow (lint config > newer files > majority pattern)
- Confidence Scoring: Rates each detected pattern as HIGH / MEDIUM / LOW confidence
| # | Dimension | What's Extracted |
|---|---|---|
| 1 | Naming | Variables, functions, classes, constants, files, boolean prefixes |
| 2 | Imports | Order, grouping, type imports, path aliases |
| 3 | Functions | Length, parameters, async patterns, arrow vs declaration |
| 4 | Error Handling | try/catch style, error types, logging patterns |
| 5 | Comments | Density, JSDoc style, language (EN/CN), TODO format |
| 6 | Testing | File naming, co-location, structure, assertions, mocking |
| 7 | Architecture (Enterprise) | Layer conventions, module boundaries, config management |
| 8 | Security Patterns (Enterprise) | Input validation, secret management, DB safety, PII handling |
| 9 | Collaboration (Enterprise) | Branch naming, commit format, PR templates |
- Actionable Rules: MUST follow / MUST NOT rules with file counts and percentages
- Reference Examples: Points to real files in the codebase as examples
- Saved Summary: Writes
.claude/project-style.mdfor persistent team reference
git clone https://github.com/Syxigd/code-style-imitator.git
cd code-style-imitatorThen add to your Claude Code settings:
{
"enabledPlugins": {
"code-style-imitator": true
}
}cp -r . ~/.claude/plugins/local/code-style-imitator/Run /reload-plugins to activate.
/code-style-imitator
The skill will:
- Detect primary language and framework
- Read lint/format config files first (authoritative)
- Scan 8–12 representative source files
- Extract patterns across all 9 dimensions
- Resolve any style conflicts
- Output a summary to
.claude/project-style.md
/code-style-imitator --project /path/to/project
/code-style-imitator --enterprise
Enables architecture, security, and collaboration scanning in addition to standard style dimensions.
# Style Summary: payment-service
Scan Date: 2026-04-08 | Language: TypeScript | Files Scanned: 10
Config Files Found: .eslintrc.json, .prettierrc, commitlint.config.js
## Naming Conventions
- Variables: camelCase — confidence: HIGH (12/12 files)
- Functions: camelCase, verb+noun — confidence: HIGH
- Classes: PascalCase — confidence: HIGH
- Constants: SCREAMING_SNAKE_CASE — confidence: HIGH
- Booleans: is/has prefix — confidence: MEDIUM (8/12 files)
## ✅ MUST Follow
1. camelCase for all variables and functions — 12/12 files (100%)
2. External → Internal → Types import order — 12/12 files (100%)
3. async/await for all async operations — 10/10 async files (100%)
4. JSDoc on all exported functions — 10/12 files (83%)
5. Use `logger` module, never console.log — configured in .eslintrc
## ❌ MUST NOT
1. snake_case for variables — never observed, eslint rule: error
2. Hardcode secrets — use process.env.* only (security pattern)
3. Direct DB access from controllers — layered architecture enforced
4. console.log — eslint no-console: error
## ⚠️ Style Conflicts
- Comment language: 7 files use English, 3 use Chinese → follow English
(newer files use English consistently)
## Reference Files
- src/services/PaymentService.ts — class structure, async patterns
- src/utils/validation.ts — input validation pattern (zod)
- src/controllers/OrderController.ts — layer boundary exampleCommit the generated summary to your repository:
git add .claude/project-style.md
git commit -m "docs: add project style summary for Claude"All team members using Claude Code will now share the same style reference automatically.
Add to your onboarding checklist:
Day 1:
- [ ] Clone the repository
- [ ] Read .claude/project-style.md for coding conventions
- [ ] Run /code-style-imitator to verify your understandingReference the style summary in your PR template:
## Before Submitting
- [ ] Code follows conventions in `.claude/project-style.md`
- [ ] No hardcoded secrets (security patterns followed)
- [ ] No layer boundary violations| Scenario | Use? |
|---|---|
| Starting work in a new project | ✅ Yes |
| Before writing code in unfamiliar codebase | ✅ Yes |
| After code review style feedback | ✅ Yes |
| Enterprise onboarding | ✅ Yes |
| Project has style guide in CLAUDE.md | ❌ Not needed |
| Personal project | ❌ Not needed |
| Only making trivial changes | ❌ Overkill |
Re-run the skill when:
- Significant codebase changes occur
- After major refactor
- Team style conventions are formally updated
- After adding new lint/format config files
Works with Claude Code CLI, desktop app, and IDE extensions.
Supported languages: TypeScript, JavaScript, Python, Go, Java, Rust, and any language with readable source files.
MIT License — feel free to use and modify for your needs.
Contributions welcome! Please:
- Fork the repository
- Create a feature branch (
feature/your-feature) - Submit a pull request referencing the issue
See CONTRIBUTING.md for full guidelines.
Created by sunyuxin
Open an issue on GitHub for bugs or suggestions.