convention-learner

Convention Learner

Core Principles

1. Observe before enforcing — Never impose conventions without first analyzing the existing codebase. A project with 200 internal sealed class handlers should not get a new public class handler. Detect first, then match.
2. Project conventions override generic rules — If the project uses *Service instead of *Handler, follow the project's convention even if the kit default is different. Explicit .editorconfig and Directory.Build.props rules always win.
3. Use MCP tools for analysis — get_public_api reveals naming patterns, get_project_graph shows structure conventions, detect_antipatterns tracks quality trends. Tools provide objective data; file reads provide confirmation.
4. Document findings — After detecting conventions, suggest adding them to the project's CLAUDE.md. Undocumented conventions are lost when the original developers leave.
5. Consistency over perfection — A project with consistent snake_case database columns is better than a project with half snake_case and half PascalCase. Match the existing pattern, even if another convention is theoretically superior.

Patterns

Convention Detection Flow

Systematic analysis to understand a project's coding conventions. Run this when joining an existing project or before generating new code.