mastermind-style-deep

Mastermind — deep style portrait

mastermind miner profile records corpus-level lexical observations (indentation, quotes, braces, line length). Those are diagnostic evidence because formatter, language mix, and repository policy often explain them better than personal taste; do not apply them directly as coding rules. This skill writes the part that matters: a grounded portrait of how the author develops. The binary gathers evidence; you (the agent, already running a model) read code and write the portrait. No separate claude -p process or authentication.

When to use

• The user wants a real "write like me" profile, not formatter-config rules.
• The user says "deep style", "design patterns", "qualitative profile", "make it richer".
• After mastermind miner profile, to add the section the deterministic core can't.

What you're producing

A portrait of how this person works — the kind a senior writes after reading someone's PRs for a month. Organized by the dimensions below, every claim tied to a concrete tell. Prose per dimension, not a list of isolated counts — the measured static rules already live in the section above this one.

Gather evidence — quantitative AND qualitative

Don't just grep. A portrait needs both numbers and read code:

1. Counts with their contrast. Any "prefers X over Y" needs BOTH counted — early-return/let-else vs nesting depth; iterator chains vs for loops; typed errors vs Box<dyn Error>; table-driven tests vs one-assertion-per-fn. A bare count of X is not evidence of a preference.
2. Read 4–6 real files. A core module (design), a hot path (optimization), a public API (ergonomics), a test file (test style), a recent diff. Greps can't see why or what they watch for — reading can.
3. Commits. Reuse the author identity selected by mastermind miner profile when available. Otherwise inspect git shortlog -sne --all and confirm the identity from local evidence; do not assume git config user.name matches the author being profiled. Read up to 100 matching subjects and a few bodies.
4. Enforcing config FIRST. rustfmt.toml / .eslintrc / pyproject lint config, #![deny(...)] / #![warn(...)], clippy.toml, CI lint steps. Anything a formatter or linter forces is not personal style — exclude it, or mark it "enforced". Do not credit a /// on every fn as a habit if #![deny(missing_docs)] mandates it.
5. Optimization signals. Benchmarks (criterion / #[bench] / *.bench.*), #[inline], with_capacity, caching/memoization, tracing/profiling spans, comments mentioning perf. Their presence — or absence — tells you whether they optimize and whether it's measured or by feel.
6. Observability & safety signals. Logging/tracing/metrics density, assertions, input validation, #[must_use], where error boundaries sit.