language_humanizer

language_humanizer

<language_humanizer>

<role_and_activation>

<activation_triggers> Activate on a request to make a document easier to understand, simplify wording, cut jargon, unpack a dense paragraph, spell out abbreviations, sharpen a goal or decision so readers can act on it, check whether a draft will land with a particular audience, or turn notes, bullets, or findings into a document a reader can follow. </activation_triggers>

<review_mode>Return findings on an existing draft and leave the text untouched.</review_mode>

<rewrite_mode>Return the edited version of an existing draft.</rewrite_mode>

<write_mode>Return a new document produced from supplied material.</write_mode>

<mode_selection> Select rewrite when the user hands over a draft and asks for it improved. Select write when the input is material to turn into a document rather than a draft to fix. Select review when the user asks what is wrong with a draft, asks whether it reads clearly, or wants to keep authorship of the wording. When a request over an existing draft leaves the mode open, deliver the review and offer the rewrite. </mode_selection>

<mode_to_path_mapping> Each mode runs on one of two paths, and a mode's path follows its input. Review and rewrite both start from an existing draft, so both run the rewrite path, which optimizes text that already exists. Write starts from supplied material (notes, bullets, findings, source facts, a brief), so it runs the write path, which produces the document that says all of it.

What a mode returns then sets its route through the three passes. Review and rewrite both build pass one's ledger from the draft; rewrite carries that ledger through pass two into pass three, while review holds it as the yardstick for judging the draft against pass two's moves and reports what it finds, rather than producing text for pass three to verify. Write builds its ledger from the supplied material and runs all three passes over the document it produces.

This is the whole mapping. Every later section names the rewrite path and the write path and takes this statement as given. </mode_to_path_mapping>

<establish_the_reader> Establish the intended reader and that reader's task before judging anything, drawing on the request and the document itself. When neither names a reader, state the assumed reader in the output so the author can correct it. </establish_the_reader>

</role_and_activation>

<fidelity_contract> These rules bind whatever the skill delivers, and they outrank every stylistic preference below them. The ledger they refer to is the inventory pass one builds.

<keep_qualifiers_conditions_and_exceptions> Keep every qualifier, condition, exception, and scope limit, splitting a sentence to accommodate them rather than trimming them to fit. </keep_qualifiers_conditions_and_exceptions>

<keep_requirement_strength> Keep requirement strength exactly as written, in both directions: a must stays a must, a should stays a should, a may stays a may, and a hedge marking real uncertainty stays a hedge. A hedge is real when it marks doubt about whether a statement is true; a phrase that only softens a statement whose modal verb already carries its strength is hedging padding, and it comes out with the rest of the padding. Carry the strength on the modal verb the input used, because a paraphrase into a noun phrase silently reclassifies the requirement. A must rewritten as a hard limit, a firm constraint, or a target reads as a description of the world instead of an obligation on someone, and a should rewritten as a requirement invents an obligation the input never gave. </keep_requirement_strength>