MAKE CLAUDE ANSWER IN PLAIN ENGLISH
LLMs are inherently verbose. When working on technical task we need clear context and instructions, instead of three paragraphs of text.
Searching for the solution for this problem I built a small plugin (skill) for Claude Code and Desktop. It makes Claude reply in short, plain English by using Simplified Technical English.
The rules and word list are packaged in a small Python linter with no dependencies. The rules never enter the context window. Keeping the rules in code is also cheaper.
For developers working in Claude Code the tool is a plugin. You can install directly with:
*/plugin marketplace add stayukasabov/Stayux-Clear-Answer * /plugin install clear-answer@stayux
In the dialogue, /clear-answer:on and /clear-answer:off turn the mode on and off, and /clear-answer:mode sets prose or strict. For documents, /clear-answer:check reports the problems in a file,/clear-answer:rewrite shows a before and after, and /clear-answer:init writes the rules into a project’s CLAUDE.md so a whole team inherits them. The plugin also loads on its own when you ask for a clear answer or plain English.
Product managers, designers, and writers work in Claude Desktop, where a plugin does not apply. For them the tool is a single skill. You download one file from the latest release and upload it once in Settings, and it is ready. Desktop has no slash commands, so you turn the mode on and off with words: “clear answer on” to start, “clear answer off” to stop.
Example:
What should a PRD for a small feature contain?
With the tool off:
For a small feature you don’t need a heavy template, but a few things really should be there. Start with the problem you’re solving and who has it, because if that isn’t clear up front, everything downstream gets shaky. Then state the goal, ideally as something you can actually measure, so you’ll know later whether the thing worked. It’s worth being explicit about scope, both what you’re building and what you’re deliberately not building, since scope creep tends to sneak in through the gaps you didn’t name. From there, list the actual requirements or user stories, keep them short, and note any key user flows or edge cases. I’d also include a success metric, any dependencies or risks you’re aware of, and a rough sense of how you’ll know it’s done. For a small feature you can usually skip the exhaustive detail and keep the whole thing to a page or so.
With the tool on:
A PRD for a small feature needs these parts. 1. Problem. Tell the user problem in one sentence. 2. Goal. Give one outcome you can measure. 3. Scope. List what you make and what you do not make. 4. Users. Name who uses the feature. 5. Requirements. Write each rule as one short sentence. 6. Metric. Give the number that shows the feature works. 7. Risks. List what can fail and your plan for each risk.
Keep the PRD to one page.
One honest note. This is an unofficial tool, not affiliated with ASD, who own the ASD-STE100 standard and its dictionary. It ships my own plain-English word list, not their copyrighted one. If you need a check against the official words, you load your own copy locally and the tool uses it. Nothing copyrighted is shipped or committed.