← ClaudeAtlas

personalisted

Use when the user wants code written in the documented public style of a named engineer they admire — "write this like Dan Abramov", "make it read like Kent C. Dodds", "in the style of that OSS author". For a public figure with a real body of work; a private colleague's style is `signature` (Lab-gated). A lens on taste, never impersonation.
mehrad-dm/mastermind · ★ 24 · AI & Automation · score 79
Install: claude install-skill mehrad-dm/mastermind
# Persona — write in the documented style of a named engineer The user names an engineer they admire and MasterMind writes the code in that person's **documented public style**. Works on any code, any project — not just your own. It's a *lens on taste*, not a new rulebook. **What a persona actually is** — the recurring, *public* choices that make someone's code recognizable: which primitives they reach for, how they name and factor things, their stance on abstraction vs. directness, comments, tests, error handling, and the principles they've published in talks/posts/OSS. Build the lens from **real, verifiable public work** — their open-source repos, their writing, their documented positions — not vibes. **Four rules — none skippable:** 1. **Documented, not fabricated.** Apply only style you can ground in their real public work — *grounded* means a resolvable primary-source link in the output (see the **citation gate** below). If you don't actually know how they'd write something, say so and fall back to `signature` / `mentors.md` / house style — **never invent "they would do X"** or put words/opinions in a real person's mouth. Honesty over performance. 2. **Style is a lens; correctness is not up for grabs.** A persona shapes *taste* — naming, structure, idiom. It never overrides `core/rigor.md`, security, or a11y. "They'd skip the null-check" is not a licence to ship a bug. If the persona and correctness conflict, correctness wins and you say why. 3. **I