v4.14.1 — Reply language follows your instructions

The skills that talk with you no longer fix the reply language to the language you write in. Your own instructions on reply language decide, and the language of your message stands in only when you have given none.

The discovery rules, generate-brief, diagnose-bug, and prototype said to match the user's language, with a per-language example. That is a more specific rule than a user's own "always reply in X", and may outweigh it. That it does was suspected, not measured; the neutral rule is right either way. The brief and diagnose-bug's documents follow your instructions on document language the same way, since you can want replies in one language and documents in another.

This release also fixes the retro scripts writing a __pycache__ into the plugin's own directory.

Compatibility: no CONTEXT key, command, skill argument, or report layout changed. A session with no instruction on reply language behaves as before. Rules that keep a line, a heading, or a file in English whatever the conversation language are unchanged.

What changed

Reply language

• shared/discovery-framework.md, generate-brief, diagnose-bug, and prototype: follow the user's instructions on reply language; without one, match the user's language.
• init-project: the first message names the language your instructions set for replies, or else the language you wrote in. The README's Project setup says the same.
• autopilot: the user report and the conversation follow your instructions on reply language, and the main-session rulings list is in the user report's language.

Document language

• generate-brief's brief and diagnose-bug's task document or brief: your instructions on document language, standing or given during the conversation, come first; without one, the conversation's language.

retro

• The scripts load each other by path, and each load wrote a __pycache__ beside them, inside the plugin. The loaders now set sys.dont_write_bytecode before loading.
• check-retro-scripts.sh fails when a __pycache__ is left beside the scripts, with a self-test mutant that turns the switch off. Its own load of rank.py runs python3 -B.
• In this repository, the bytecode made check-instruction-files.sh fail, so the release pre-flight failed whenever it ran a second time.

Upgrading

claude plugin marketplace update kenspc-claude-plugin

claude plugin update kenspc@kenspc-claude-plugin

Restart the session afterwards.

Verification

• Pre-flight, run twice in a row before the release edits and again after them: the effort-override diff, claude plugin validate --strict on the marketplace and the plugin, and check-all.sh --self-test (guards run: 17, self-tests run: 16).
• The new bytecode check failed against the 4.14.0 scripts, on the __pycache__ they left, and passes against the fixed ones.
• No smoke row was run. Only rule text in skill bodies and the retro scripts changed, no frontmatter, and the plugin loader's own validation passed. The reply-language change was not measured in a session.