← ClaudeAtlas

convention-learnerlisted

Protocol for detecting and replicating existing project conventions before generating new code — naming, folder structure, DI registration, test framework, DTOs, and error handling.
zdanovichnick/dotnet-pilot · ★ 3 · AI & Automation · score 76
Install: claude install-skill zdanovichnick/dotnet-pilot
# Convention Learner Protocol for detecting project conventions before generating code. Run this before creating any new files in a project you haven't worked in during this session. **Purpose**: Prevent naming drift and structural inconsistency. Generated code that doesn't match project conventions creates review friction, merge noise, and long-term maintenance debt. ## When This Protocol Is MANDATORY - First file creation in any session - Adding a new feature to an existing codebase - Any time the project's architecture style is unknown - When the user's request doesn't specify naming or structure Skip only when: the user explicitly specifies all conventions in their request, or you have confirmed conventions in the same session (within the current conversation). ## Detection Protocol Run Steps 1–6 before writing any code. You need all six answers. ### Step 1 — Naming Suffix Convention What suffix does this project use for its handlers/services? ``` Grep pattern: "class \w+(Handler|Service|Manager|Controller|UseCase|Interactor)" Files: src/**/*.cs ``` Determine: `Handler`, `Service`, `Manager`, `Controller`, or a mix? If mixed: use the suffix most common in the feature area you're working in (e.g., if `Orders/` uses `Handler`, use `Handler` for new order code even if `Customers/` uses `Service`). ### Step 2 — Folder / Architecture Style What is the top-level organization under `src/`? ``` Glob: src/**/*.cs → inspect top-level directory names under src/<AppNa