Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →syncable-dev/memtrace-style-fingerprint
Pull the codebase's empirical style norm from Memtrace and match it when writing or editing source code in an indexed repo.
Passed 15 of 18 test cases with the skill, and 3 of 18 without it.
and 14 more in the full report
14 fixed4 passed either way4 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
When examining identifier casing metrics for a Go repository, we do not see standard camelCase share breakdowns for functions. What field does Memtrace report for Go function naming instead?
| Checked | Without skill | With skill |
|---|---|---|
| Identifies `go_exported_share` as the metric returned for Go identifier casing. | Missed | Passed |
| Explains that Go identifier casing determines visibility. | Passed | Passed |
The instructions your model reads when the skill loads.
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.
| 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).
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 interpretationfunction_count — sample size at the repo levelsample_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.
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 filetest cases passed, vs 3 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.