Detects and enforces project-specific coding conventions by analyzing existing codebase patterns. Learns naming conventions, folder structure, test organization, and coding style from the existing code. Load when: "conventions", "coding standards", "project patterns", "enforce style", "detect patter

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. Step 1: Project Structure Analysis Step 2: Type Naming Patterns Step 3: Folder Structure Patterns Scan the file system for structural conventions: Feature folders: Features/{FeatureName}/ with all files together? Layer folders: Controllers/ , Services/ , Repositories/ separate? Shared patterns: Common/ , Extensions/ , Middleware/ ? Configuration location: root? Config/ folder? Infrastructure/ ? Step 4: Configuration Detection Check for explicit convention enforcers: Step 5: Build Convention Summary Compile findings into a structured summary: Add categories as needed: EF Core (configurations, naming, migrations), Testing (framework, naming, fixtures), etc. Convention Enforcement Apply detected conventions when generating new code or reviewing existing code. When Generating Code: Match every detected pattern: When Reviewing Code: Flag deviations from detected conventions: Suggesting Enforcement Rules: After detecting conventions, suggest .editorconfig rules to enforce them automatically: Anti pattern Tracking Use detect antipatterns to track recurring quality issues across sessions. Periodic Check: Prioritization: When patterns recur, add explicit rules to CLAUDE.md: Anti patterns Enforcing Without Detecting Overriding Explicit Project Rules Applying Generic Conventions to Unconventional Projects Documenting Conventions Without Evidence Decision Guide Scenario Action Tool Joining existing project Run full convention detection flow get project graph, get public api Generating new code Check detected conventions first Previous detection results Reviewing code Flag convention deviations get public api + comparison Convention conflict (kit vs project) Project wins — Convention conflict (team disagreement) Document both, suggest .editorconfig — No conventions detected Use kit defaults, document them architecture advisor skill Recurring anti pattern Add to CLAUDE.md conventions detect antipatterns New team member onboarding Run detection, generate convention doc Full detection flow .editorconfig exists Trust it, don't override Read .editorconfig No .editorconfig Suggest creating one based on detected patterns Detection + generation Pattern seen once Create instinct at 0.3 confidence via instinct system skill instinct system Pattern confirmed 3+ times Instinct auto promotes to 0.7, suggest adding to CLAUDE.md instinct system

convention-learner