Signature: capture a team's code style, turn it into rules the AI follows

A signature is your team's code style and conventions: the way your code recognizably looks and reads, like handwriting. The name is MasterMind's; the thing it captures is plain old code style.

A codebase has a real style that's rarely written down: people can't list their own conventions, but recognize a violation instantly. This skill surfaces that tacit style and makes it durable: a correction you give once becomes a permanent rule, not a repeated fix. Two phases: capture (private, in the quarantine), then distil (name-free, into a field pack).

The rule that never bends: patterns, not people. Describe what the code does ("this codebase resolves X by Y"), never rate a person ("so-and-so writes bad code"). The artifact is the pattern; the person is incidental: and a file that judges a named person is a career-risk if it leaks. Group by contributor only as a source of signal, phrased neutrally.

Their own words stay theirs: propose, never rewrite unasked (~/.mastermind/engineering/core/rigor.md → Stay in scope).

Phase 1: Capture (private, stays in the quarantine)

1. Consent + Lab first. Ask before scanning a real, possibly-private codebase (and which paths). All output has names, so it lands in lab/ (gitignored): if there's no Lab, set one up (quarantine skill) first.
2. Two sources, the second is the gold:
   • Repeated corrections (highest value). What people tell the AI over and over: "do X not Y", "always…", "stop doing…", recurring review comments, AI diffs reverted-and-redone. Explicit, human-validated, de-noised. Weight by frequency (seen 20× = a rule; once = noise). Read the corrections log if one exists; help start one if not.
   • Codebase patterns (lower confidence). Recurring idioms in code/history: naming, layout, how state/data/errors are handled. Candidate patterns, not truth (blame is noisy; in-repo ≠ endorsed).
3. Output: neutral profiles in lab/analysis/: pattern · frequency · source · first-pass kind (convention | correctness | unsure). Neutral wording is not optional: if you can't phrase it about the pattern, drop it.

Phase 2: Distil into rules (three gates, none skippable)

Gate 1. Classify: convention or correctness.

• Convention (style: naming, layout, which primitive) → the rule is "match the house style," framed as conformance; justification is "the team does it this way."
• Correctness (a real defect: a11y gap, unsafe input, a cache/lifecycle bug) → allowed only with a primary-source citation + a concrete failure scenario. No citation/failure → demote to convention or drop. The test: "Can I cite a source saying this is wrong AND name a failure it causes?"

Gate 2. Promotion bar (keep the pack lean). A candidate graduates only if it recurs across more than one source/author: the antidote to encoding one loud voice as team law, and to bloat. Replay it against recent examples to confirm it holds. Use all three signals: corrections (add a rule), approvals (confirm an existing rule is right: stop second-guessing it), and implicit edits (human shipped it differently than proposed, the richest source of unstated conventions).

Gate 3. Sanitize (identities never leave the quarantine). Strip every project/product/person/package/host name and replace with a generic description before anything reaches a field pack. If a rule can't be expressed without an internal name, it stays in the quarantine. The guards are the backstop, not a license.

Output: propose, never apply

Hand surviving rules to levelup as proposed pack edits (category · kind · generic rule · why [+citation]). Show the user the diff; never auto-commit or push. Convention → lessons/stack-defaults; correctness-with-citation → same, tagged for the code-reviewer audit. Frontend today; the gates apply to any field.

Gotchas

• A convention is not a defect: the commonest failure is "fixing" house style. When unsure, conform.
• Negative signal dominates: capture approvals too, or rules drift into timid nitpicks; retire a rule that keeps getting dismissed.
• One incident is not a pattern: respect the promotion bar.
• Let tooling own what tooling enforces: if a lint rule/type/template guarantees it, strengthen that; keep only the "why."
• code-reviewer finds defects; this captures style. Keep the layers separate.
• A named private colleague's style stays here, never in persona. persona is for public figures with a documented body of work. A real coworker's style is private material: quarantine-gated, and it never leaves.