Framework Idioms Coach

Every framework rewards a particular shape of code, and every codebase has already voted on its dialect. This skill makes an agent write code that reads like the existing team wrote it: it detects the conventions actually in force — not the ones the framework's documentation recommends — and applies them, flagging rather than silently "fixing" the places where the codebase disagrees with itself.

When to use this skill

Adding a feature to an unfamiliar codebase in any web, mobile, or backend framework
Reviewing a diff that "works but feels off" relative to the surrounding code
Porting a snippet written in one framework style into a project that speaks another
Onboarding docs are missing and the code itself is the only style guide available
A team wants their conventions written down as a brief new contributors can follow

Instructions

Before writing anything, collect three existing examples of the kind of thing you are about to create — three components, three route handlers, three test files. One example is an accident, two are a coincidence, three are a convention.
From the examples, extract the local dialect along four axes:
- Naming: file names, symbol casing, suffix habits (UserCard vs user-card, _test vs .spec)
- State and data flow: where fetching happens, how errors propagate, which layer owns validation
- Structure: folder-by-feature vs folder-by-type; where shared helpers live; barrel files or direct imports; how deep relative paths are allowed to reach
- Boilerplate: what a "new unit" of this kind minimally includes — types, registration, exports, a test file
Check for enforced opinions before stylistic ones: lint configuration, formatter settings, CI checks, and commit hooks outrank any pattern you infer by reading.
Write the new code by imitation first, framework best practice second. When the two conflict, follow the codebase and note the divergence you preserved in a one-line comment or in your summary.
If the codebase disagrees with itself — two competing patterns for the same job — adopt the pattern used by the most recently modified files and say so explicitly. Recency approximates the team's current intent better than frequency does.
Never introduce a third pattern. The worst outcome is a diff that adds a new dialect to a codebase already speaking two.
On request, produce an idioms brief (format below) so the detection work is reusable by the next contributor instead of dying with this task.

Output format

When asked for the brief rather than code:

### Idioms brief: <area of codebase>
- A new <unit> lives in: <path pattern>, named <convention>
- Data access: <pattern, with one file citation>
- Error handling: <pattern, with citation>
- Tests: <location, naming, minimum expected assertions>
- Known inconsistencies: <pattern A (n files) vs pattern B (n files); currently winning: A>

Every claim cites at least one real file. A brief without citations is folklore.

Quality bar

A reviewer cannot tell from style alone which lines are new
Zero new lint or formatter violations introduced
Divergences from framework defaults are preserved deliberately and noted, never "corrected" in passing
No new abstraction invented when three files already demonstrate the local way
The diff imports from the same layers its neighbors import from

Checklist before submitting code

Found three precedent examples and read them fully
File location and name match the dominant pattern
Imports follow local ordering and path-alias habits
Error and loading states handled the way the neighbors handle them
Tests mirror a neighboring test file's structure
Any deliberate divergence is written down where a reviewer will see it