claude opens its mouth and it's all jargon, so now it has to pick a professor tone first

I built a skill that lets you set how densely Claude writes and keeps that setting for the rest of the session instead of just the next reply. MIT, free, install near the bottom. The screenshot is one question answered at all three settings. why I bothered I'm a physics PhD student and most of what I ask Claude about is the ML side of my work, where I'm not the expert. Last week I asked about some gradient descent code and the answer opened with "the non-convexity of the loss surface causes the optimizer to converge to a suboptimal stationary point." I typed "explain that in plain english" and got something good back. Then I asked a follow-up and it went straight to the original density again. This happens constantly, and it took me longer than it should have to work out that the reason is just that "plain english" has no definition attached to it. Nothing for the model to carry forward. So I tried writing one. the three settings • Feynman — nothing goes unexplained. The argument gets carried by an analogy to something you already know, and at the end it says where the analogy stops working. • Griffiths — a term gets defined the first time it shows up, then used normally after that. The worked example is the system you actually asked about, shrunk to something you can do on paper, with the derivation left in. • Landau — no scaffolding. Result, validity conditions, and it assumes you can fill in the rest. Worth saying up front because it always comes up: these are names for rule sets, not impressions of anybody. There's an explicit rule in the file against imitating prose style, and Landau is the reason it exists. Reading "Landau mode" as "write like Landau" would get you something even less readable than what I was trying to fix. Three styles (https://preview.redd.it/22j465twnlsh1.png?width=1400&format=png&auto=webp&s=1c3f510bbbd393512fa70c17efedf8dd6dde9581) design notes The thing actually doing the work is a term budget, meaning how much jargon is allowed to show up in a sentence without being explained in that same sentence. Notation counts as jargon. So do acronyms. I spent way longer than expected on the difference between the first two, because both use pictures and I kept treating that as one thing. It isn't. Feynman uses a picture of some other system that happens to have the same shape, and while that's running you've stopped looking at the thing you asked about. Griffiths uses a picture of the real thing with most of it stripped out. The check I use now is to ask the same question at both settings, and if the two answers are the same content at different sentence lengths then neither one did anything. One rule overrides everything else: changing the setting can't remove content. Assumptions, magnitudes, caveats, the regimes where something breaks, all of that survives everywhere. I'd rather it get wordier than lose a precondition, since an answer that reads well because it quietly dropped one is worse than the dense version was. It also won't set anything on its own. You have to ask, or complain. how Claude Code was involved I wrote the rules, Claude Code did the drafting and the file editing, working directly on SKILL.md and the reference files with the repo connected. More useful than that was using Claude as the thing under test. A skill is a markdown file full of instructions, so there's nothing to unit test. The only way to find out whether a rule does anything is to open a session with no context, give it one prompt, and compare what happens against what you assumed would happen. Two results I didn't expect: Conditional phrasing gets dropped. My first version had rules like "if the reader seems to be outside the field, consider glossing the term." It never once did it. Changing that to a flat instruction, "gloss every field term in the sentence it first appears in," made it work immediately, and I ended up rewriting the whole file in imperatives. The failure mode I should have worried about was over-firing, not under-firing. Early on it would switch settings any time a question looked hard, which is the exact condescending behaviour I was trying to get away from. Fixing it meant writing out negative cases (hard question, no complaint, correct behaviour is to do nothing) and testing each one in a clean session until it stopped reacting. Most of the commit history is that rather than features. The three answers in the screenshot came out of the skill itself rather than being written by hand, which seemed like the only fair way to show it. install Markdown only, no dependencies, MIT. Anything that reads Agent Skills should work (Claude, Claude Code, Codex, Cursor). npx skills add ljx-chase/pick-your-professor -g Or drop the pick-your-professor folder into ~/.claude/skills/. Then say "Feynman mode", or just "too technical" and it steps down one. caveats One person's testing, mostly physics and ML. The eval cases are behavioural and judged by me, nothing automated. The failures I'd most like reported are it firing when nobody asked for it, or sliding back to the old density a few turns in. https://github.com/ljx-chase/pick-your-professor