/memtrace-style-fingerprint

name: memtrace-style-fingerprint
description: "Pull the codebase's empirical style norm from Memtrace and match it when writing or editing source code in an indexed repo. Use when choosing between competing idioms (ternary vs if-else, arrow vs function declaration, const vs let, await vs .then, early-return vs nested-return), matching naming case, or when the user asks what the convention here is. Do not re-derive style from training priors or maintain a markdown style guide for the project; the fingerprint is sampled live from the actual code."

Overview

Every indexed Memtrace repository carries an empirical **style fingerprint** — descriptive histograms of competing AST idioms (ternary vs if-else, arrow vs function declaration, const vs let, await vs `.then`, early-return vs nested-return depth) computed at parse time and rolled up to Repository + Community level. This workflow tells you when and how to consult it so your edits match the codebase's existing idioms instead of drifting on stylistic choices the linter doesn't catch.

The fingerprint is **descriptive, not prescriptive**. It reports what the codebase actually does, not what a style guide says it should do. If the codebase deviates from a popular convention for some reason, the fingerprint captures the deviation and you should match the deviation — that's the whole point. For prescriptive bug/security/perf rules, use `find_code_review_issues` instead.

Best Fit

| Situation | Action | |---|---| | About to write new code (function, component, module) in an indexed repo | Step 1 + Step 2 with `file_path=<the file you'll create>` | | About to edit an existing file | Step 1 + Step 2 with `file_path=<that file>` | | Asked "what's the convention here for X?" | Step 1 only — repo-mode fingerprint answers it | | Deciding between two equivalent idioms (ternary vs if, arrow vs fn-decl, await vs then) | Step 2 with `file_path` — `delta_from_codebase_norm` tells you which idiom matches the norm | | Reviewing a diff | Step 2 on each modified file — flag any new idioms that diverge from the file's language norm | | Session start in a multi-day project | Read the `style:` line in `get_codebase_briefing` (auto-included) |

If the repo is not indexed in Memtrace, this workflow does not apply — fall back to your default behavior.

Full parameter spec for every Memtrace tool: `references/mcp-parameters.md` (bundled at the memtrace-skills plugin root).

Steps

1. Get the codebase's overall norm

Call `get_style_fingerprint(repo_id)` with no `file_path` (`repo_id` comes from `list_indexed_repositories` if not already known). The response includes:

• `histogram` — raw counts (e.g. `ternary_count: 1005, if_stmt_count: 8087`)
• `ratios` — computed shares for each competing pair (e.g. `ternary_share: 0.11`)
• `dominant_idioms` — top-3 dimensions sorted by `|ratio - 0.5|` (strongest preferences first), each with a `dimension`, `ratio`, and human-readable `interpretation`
• `function_count` — sample size at the repo level
• `sample_threshold` — minimum observations before a ratio is committed (currently 20)

A `ratio` of `null` means the codebase doesn't have enough observations for that dimension to commit a norm — treat it as "no signal", do not assume one.

2. Get the file's deviation from the norm (when about to edit a specific file)

Call `get_style_fingerprint(repo_id, file_path=<file>)`. The response adds:

• `file_fingerprint` — the same shape as `histogram`/`ratios`/`function_count` but computed over just the functions in that file
• `codebase_fingerprint` — repo aggregate for comparison
• `delta_from_codebase_norm` — array of dimensions where the file diverges ≥0.15 from the codebase, sorted by absolute delta, capped at top 5. Each entry has `dimension`, `file_ratio`, `codebase_ratio`, `abs_delta`, and a `note` describing the direction

**Match the file's `language_fingerprint`, not the repo aggregate.** In file mode the response carries `language` (the file's language), `language_fingerprint` (that language's slice — the primary comparator), and `delta_from_language_norm` (divergence vs the language, not the repo). Per-language slicing prevents cross-applying Python norms to JS code or vice versa — read the `language_fingerprint`. (`delta_from_codebase_norm` is retained as a deprecated alias and is removed in 0.5.14.)

If `delta_from_language_norm` is empty, the file is already aligned — proceed without style adjustments. If it has entries, your edits should not amplify the divergence (e.g. don't add more ternaries to a file that's already above the language's ternary norm).

3. Read the briefing line at session start (passive)

`get_codebase_briefing(repo_id)` auto-includes a `style:` line in its summary when the sample threshold is met and at least one ratio is outside the 0.4..0.6 no-preference band. Format:

style: <interpretation 1> (<%>); <interpretation 2> (<%>); <interpretation 3> (<%>)

Example on a TS/JS-heavy codebase:

style: strongly prefers arrow functions (98%); strongly prefers async/await over .then chains (88%); strongly prefers const over let (94%)

You should already be reading the briefing at session start (per `memtrace-codebase-exploration`). The `style:` line lands in your context for free — no extra call needed.

Decision points

| Condition | Action | |---|---| | `dominant_idioms[0].ratio >= 0.85` or `<= 0.15` | Treat as a hard preference — match it unless there's a specific structural reason not to | | `dominant_idioms[0].ratio` in `0.65..0.85` or `0.15..0.35` | Treat as a soft preference — match it for new code, leave existing patterns alone | | `ratio` in `0.4..0.6` | No clear preference — use your own judgment, match local file context | | `ratio` is `null` (below sample threshold) | No signal — don't assume a norm; pick the idiom that fits the immediate context | | `delta_from_codebase_norm` shows your target file already diverges from the norm | Don't amplify