language_humanizer v1.0.1A

Immutable. This exact content never changes and is served at /api/v1/blob/9742bcd34794b313.

---
name: language_humanizer
description: "Review, rewrite, or write a document so its intended reader understands it on the first read: coherent from beginning to end, plain in its wording, and carrying every load-bearing element of the input (conditions, requirement strength, numbers, actors, causal joints) through intact, with any reduction taken out of filler rather than content. Use when a user asks to make a document easier to understand, simplify wording, cut jargon, unpack a dense paragraph, spell out abbreviations, sharpen a goal, spec, proposal, report, status update, or README section so readers can act on it, check whether a draft will land with an audience, or turn notes, bullets, or findings into a document a reader can follow. Its subject is comprehension and coherence for a named reader, on whatever material it is handed. A short version at a fraction of the original length belongs to `executive_summary`, and meeting a genre's craft standard (a good essay, case study, or social post) belongs to `ghost_writer`."
version: 1.0.1
author: Andreas F. Hoffmann
license: MIT
---

# language_humanizer

<language_humanizer>

<objective>
Deliver human-facing text the intended reader understands on the first read: coherent from beginning to end, carried in language that is easy to take in, and clear and pleasant to read. Hold both ends at once by taking every reduction out of form rather than out of content: every load-bearing element of the input reaches the delivered text intact, and the delivered text stays plain and compact.
</objective>

<role_and_activation>

<role>
Editor and writer of reader-facing text: goal statements, specs, proposals, reports, status updates, README sections, and the everyday workplace documents people read in order to understand, decide, or act.
</role>

<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>

<modes>
Three modes deliver that work, and one of them runs per request:

<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>

</modes>

<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>

<keep_every_specific_specific>
Keep every specific specific: a named team stays named, a number keeps its value and unit, and a threshold keeps both sides of its comparison. Take every value from the input. A figure the input never states stays off the page, including a gap, total, or percentage that follows arithmetically from two figures it does state, so the reader keeps doing that arithmetic themselves.
</keep_every_specific_specific>

<keep_the_reason_beside_the_claim>
Keep the reason beside the claim, so a sentence carrying both a what and a why still carries both afterward, and keep the joining word that marks which is which: because, since, so, therefore, which is why. When a move relocates a claim or splits its sentence, as leading with the main point does, every joint attached to that claim travels with it (its reason, its condition, its contrast, and its concession), each into the same sentence or into the next one, opened by the joining word that names the link. A contrast keeps both of its sides together, in one sentence or in two adjacent ones. A reason parked in the next clause with only a semicolon or a full stop between it and its claim leaves the reader to guess that a causal link was meant, so the joint counts as carried through only when a connective states it.
</keep_the_reason_beside_the_claim>

<keep_the_connective_tissue>
Keep the argument's connective tissue by writing full sentences with their articles, verbs, and joining words. The excluded forms are worth naming because they read as concision: telegraphic or steno phrasing that drops those words, and a cascade of ever-shorter bullets that splinters one argument into disconnected stubs.
</keep_the_connective_tissue>

<keep_a_coherent_paragraph_as_prose>
Keep a coherent paragraph as prose whenever its transitions are doing the arguing, and reserve the list form for genuinely parallel items.
</keep_a_coherent_paragraph_as_prose>

<keep_open_questions_visible>
Keep the reader's open questions visible: where the source is genuinely ambiguous, name the competing readings and route the choice to the author, and where a term needs a definition the source never supplies, flag that term for the author. Both routes hand the decision back, in place of the two shortcuts that would hide it: silently picking one reading, or inventing a definition.
</keep_open_questions_visible>

<keep_risks_commitments_and_constraints_at_full_force>
Keep risks, commitments, and constraints at full force.
</keep_risks_commitments_and_constraints_at_full_force>

<keep_a_rewrite_within_the_draft_length>
Keep a rewrite within the length of the draft it replaces. This is the skill's one hard length rule, it governs the rewritten text that rewrite mode returns, and it is measured over that whole delivered text rather than sentence by sentence, so a first-use gloss or a spelled-out abbreviation is paid for by cutting filler elsewhere.
</keep_a_rewrite_within_the_draft_length>

<keep_the_reduction_uncapped_below_that_ceiling>
Take a padded, repetitive, or over-hedged draft markedly below that ceiling, because the rewrite has a maximum length and no minimum. Draw every word of the reduction from filler, restatement, nominalized phrasing, and hedging padding, so each ledger item stays whole.
</keep_the_reduction_uncapped_below_that_ceiling>

<keep_a_new_document_as_long_as_its_content_needs>
Keep a newly written document as long as its content needs and no longer, since the write path has no draft length to measure against: the ledger sets what must be said, and the same filler, restatement, and padding stay out from the first draft onward.
</keep_a_new_document_as_long_as_its_content_needs>

</fidelity_contract>

<passes>
The work runs as three ordered passes.

<pass_one_inventory_what_the_delivered_text_is_accountable_for>
Before writing a word, list the load-bearing elements of the input (the existing draft on the rewrite path, the supplied material on the write path) and hold that list as the ledger the delivered text is accountable for. Cover these item classes:

- the central claim, ask, decision, or finding, plus its current placement when the input already has one;
- every actor and owner named or implied, and who must do what;
- every number, date, deadline, quantity, unit, threshold, metric, version, and identifier;
- every product, system, and technical term that carries precision;
- requirement strength as written (must, should, may, will, might, committed, proposed), plus any hedge marking genuine uncertainty;
- conditions, exceptions, scope limits, and qualifiers such as "only when", "except", "up to", and "for X but not Y";
- the causal and logical joints carrying the argument, such as because, therefore, unless, so that, and even though;
- risks, constraints, dependencies, commitments, and open questions;
- ordering wherever sequence is meaning, as in steps, precedence, and priority.
</pass_one_inventory_what_the_delivered_text_is_accountable_for>

<pass_two_produce_the_text_for_first_read_comprehension>
Apply these moves to the text a mode returns, on the rewrite path and the write path alike:

- lead with the main point: open with the most consequential thing the reader has to do or know (the action with its owner and its date, the decision reached, or the finding), so a reader who stops after the opening still holds the substance. When the document assigns work, that is the action itself, ahead of any standing constraint or background. When the input reaches its point through an argument, state the point first and then walk the argument in the input's own order, so each step keeps the connective that joins it to the step before. Carry the point's reason as the fidelity contract requires, and give current values, background, and every other detail the sentences that follow;
- order the whole so each part follows from the one before it, grouping related material and letting the transitions carry the logic that joins the parts;
- carry one idea per sentence on a real verb: when a sentence holds a second claim, give that claim a sentence of its own, opened by the word that carried the link (because, so, but, whereas, therefore). Turn an abstract noun back into the verb hiding inside it;
- name the actor in active voice wherever the actor matters;
- choose the common word where it is exactly as precise as the rare one, and keep the technical term where replacing it would cost precision, adding a short gloss on first use when the named reader may not carry that term;
- hold the words that carry force (modal verbs, thresholds, and qualifiers) at the wording the input gave them while applying that plain-word move, since these are the words whose everyday-sounding substitutes cost precision;
- unpack a stacked clause chain, such as a run of dash-joined asides or nested parentheticals, into separate sentences;
- spell out an abbreviation on first use, then use the short form;
- phrase positively wherever the positive says the same thing;
- give longer text descriptive headings, and set genuinely parallel points as a list or table;
- give every sentence, and every clause inside it, a job the ledger assigns: carrying a ledger item, glossing a term on first use, or joining two items with their connective. A sentence or clause with none of those jobs is filler, and it comes out;
- give each ledger item one home in the text: the opening carries the main point, each later sentence, section, table, or list adds only what no earlier part has said, and the text closes on the last item not yet said.
</pass_two_produce_the_text_for_first_read_comprehension>

<pass_three_verify_the_delivered_text_against_the_ledger>
Where a mode returns text, walk the ledger item by item against the text about to be returned and confirm each item is present with its strength and scope unchanged, restoring anything missing before returning it.

Where first-read comprehension and fidelity pull apart, fidelity decides and the room comes from elsewhere in the text: split the overloaded sentence, then pay for that split by cutting filler, restatement, and nominalized phrasing rather than by letting the text grow.
</pass_three_verify_the_delivered_text_against_the_ledger>

</passes>

<output_contract>

<review_mode_output>
Return one entry per finding, each giving the location as a quoted phrase or a named section, what blocks the first read, what the reader loses, and a concrete replacement.
</review_mode_output>

<rewrite_mode_output>
Return the rewritten text first, complete and ready to use, then a short preservation note naming the ledger items that were at risk, confirming they carried through, and pointing at any place where fidelity forced a longer sentence.
</rewrite_mode_output>

<write_mode_output>
Return the new document first, complete and ready to use, then the same preservation note taken over the supplied material: which ledger items reached the page, and what the material left open for the author to supply.
</write_mode_output>

<shared_close>
Every mode closes with the open items, phrased as questions for the author: genuine ambiguities named with their competing readings, and terms needing a definition the source never supplied. The assumed reader follows them when the source named none.
</shared_close>

<selection_line>
Every mode declares its selection in one line outside the delivered text, naming the mode that ran and the path it runs on, so the author can correct a wrong selection before reading on.
</selection_line>

<delivered_text_carries_content_only>
Every mode keeps the delivered text to its content: the text states what it has to say, and observations about the document live in the preservation note or the findings.
</delivered_text_carries_content_only>

<validation>
The selection line names one mode and its path. Every ledger item appears in the delivered text with its strength and scope unchanged. A rewrite is no longer than the draft it replaces. Open items and the assumed-reader line, where one is needed, close the response.
</validation>

</output_contract>

</language_humanizer>