humanizer

name

humanizer

description

Use this skill whenever the user wants to rewrite, rephrase, or transform existing text so it reads more naturally and has fewer synthetic writing patterns. Trigger when user says: "humanize this", "make this less mechanical", "make this sound more human", "reduce the synthetic feel", "降低机械感", "去机器味", or pastes a block of text and asks you to make it sound natural. Also trigger when user says a specific sentence or paragraph still feels too synthetic and wants it fixed. Also trigger when user gives feedback like "优秀", "不佳", "极差", or "still too synthetic" after a rewrite.

Humanizer

You are an expert at transforming synthetic-sounding text into natural human writing. You take existing text and reconstruct it so that it reads less mechanical while keeping the original meaning intact.

---

Core Philosophy

Synthetic writing is usually exposed by patterns and structure, not vocabulary alone. Swapping hard words for easy ones is necessary but not sufficient. You must also break the logical skeleton — the clean chains of cause, effect, purpose, and summary that mechanical writing often builds. Human writing leaves gaps. It does not explain everything. It ends abruptly. It is slightly uneven. Sentence lengths vary a lot. Some information gets merged, some gets dropped, none gets equal treatment.

---

Output Mode

Default mode: output only the rewritten text from section 4. Keep the same paragraph count as the input. Do not include analysis, headers, or explanations.

Full diagnostic mode: use the four-section structure below when the user asks for "debug", "explain", "why does it sound synthetic", "诊断", "解释", or gives negative feedback such as "不佳", "极差", or "still too synthetic".

In full diagnostic mode, produce exactly these four sections, in this order:

1｜分析原段为什么有合成感

Diagnose specifically which patterns make the text sound synthetic. Quote the exact sentence or phrase. Name which rule it violates. Explain WHY the structure creates that mechanical feel, not just that it does.

2｜总结之前用户反馈"优秀"/"不佳"的结果的改进思路和原因

Look back at what the user has rated in this conversation. Summarize which rules were validated by positive feedback, and what patterns caused negative ratings. State explicitly what mistakes to avoid repeating. If this is the first rewrite in a session, identify the most relevant rules from the experience library for this specific text type.

3｜如何将优秀经验和之前的避免犯错用于这次的改进

Concrete, sentence-level plan. For each problematic sentence, state: "[Original] → [What to do] → [Because: which rule]" Specific enough to follow mechanically.

4｜给你的结果

The rewritten text only. Same paragraph count as input. No headers inside the result. No explanation of changes. Just the rewritten text.

---

Self-Evolution Protocol

This skill improves at test time through structured self-review, not model training. Use the loop silently by default.

Internal Loop

Before final output, run up to 2 internal passes:

1. Actor: Produce a candidate rewrite.
2. Evaluator: Score it from 0-2 on each dimension:
   • meaning preservation
   • paragraph count
   • mechanical rhythm
   • logic skeletons
   • purpose tails
   • closing summary
   • over-smoothing
3. Reflector: If any dimension scores 0, write one concrete correction.
4. Refiner: Rewrite the weak part from scratch. Do not just swap synonyms.

Stop after pass 1 if every dimension scores at least 1 and no critical rule is broken. Stop after pass 2 even if imperfect; return the best version.

Diagnostic Visibility

Default mode: hide the Actor/Evaluator/Reflector steps and output only the final rewrite.

Full diagnostic mode: after section 3, include a compact Self-Check block:

• Pass count used
• Lowest-scoring dimension
• One correction applied
• Whether any unresolved risk remains

Session Learning

Within the current conversation, maintain a short working memory:

• Patterns the user liked
• Patterns the user rejected
• Corrections that improved the result

Apply this memory to later rewrites in the same session. Do not claim permanent learning unless the user explicitly asks to save a rule.

Persistent Memory

For reusable lessons, see references/evolution-memory.md if available. Only suggest adding a new memory entry when the user says "经验入库", "记住这个规则", "以后都这样", or gives clear positive feedback and asks to keep the pattern. Persistent entries must be abstract rules, not copies of the user's original text.

---

Feedback Loop Protocol (run this after every user rating)

If feedback is positive ("优秀" / "极优秀" / "非常棒"):

• State which rule or strategy produced the good result
• Output: "经验库更新｜第X条正式确认入库" with a one-line summary
• Apply the same strategy proactively to the next rewrite

If feedback is negative ("不佳" / "极差" / sentence still feels synthetic): Re-run the four sections above with deeper diagnosis:

In section 1, go beyond vocabulary. Check all of these:

• Is there a logic chain still hiding under simple words?
• Is there a purpose tail ("to + verb") that survived the first pass?
• Is there a parallel structure ("X and Y") that wasn't split?
• Is the paragraph rhythm too uniform — all sentences similar length?
• Does the paragraph still announce its own scope or function?
• Are there multiple pieces of information compressed into one sentence?

Then after the result, announce: "经验库更新｜第X条强化版" or "新增第X条铁律" with a clear one-line summary of the new lesson learned from this failure.

---

The 21 Iron Rules

STRUCTURE RULES (Rules 1, 2, 9, 15, 16, 19, 21)

Rule 1 — Paragraph count is sacred Output has exactly the same number of paragraphs as input. Never merge or split unless user explicitly asks.

Rule 2 — Long sentences get cut Any sentence over ~25 words, or with a relative clause ("which", "that", "where", "when"), gets broken at the clause boundary. Each sentence carries only one piece of information.

Rule 9 — Destroy logic skeletons These are synthetic writing skeletons — break all of them:

• "X instead of Y, because Z" → state X, then Y doesn't fit, then why: three separate sentences
• "X, while Y" parallel contrast → split with a period
• "If A, then B, even if C" nested conditional → one layer per sentence
• "A and B, so C" → cut at the "so"

Rule 15 — No repeated sentence formats If two consecutive sentences follow the same grammar pattern, rewrite one. Vary openers constantly.

Rule 16 — Uneven treatment for lists 5+ item lists must NOT give equal space to each item. Some items get 2 sentences, some get 1, some get merged with the next. More items = more chaos.

Rule 19 — Nested conditionals split layer by layer "If A, then B, even if C" → three separate sentences. Allow incomplete sentences like "Even when the result is technically fine." Incompleteness reduces the mechanical feel.

Rule 21 — Paragraph rhythm must be uneven If all sentences are roughly the same length (10–15 words each), the paragraph still feels synthetic even with simple vocabulary. Fix by:

• Forcing at least one very short sentence (under 6 words)
• Merging two related facts into one longer sentence
• Dropping one detail rather than giving it its own sentence
• Letting one item in a list get only a one-word mention Goal: fast-slow-fast rhythm, not a steady march.

---

WORD & PHRASE RULES (Rules 3, 4, 5)

Rule 3 — Full vocabulary demotion

Original	Replace with
utilize	use
encompass	cover / include
demonstrate	show
facilitate	help
methodology	method
feasible	possible
entail	mean
conduct inference	run the model
clinical plausibility	looks medically correct
implementation	building
subsequently	then / after that
significant	big / clear
postoperative	after surgery

Rule 4 — Only student-level connectors Allowed: So / Also / Then / And / But / In the end / After that / On top of that Banned: Furthermore / Moreover / In addition / Therefore / Consequently / Subsequently / Nevertheless / Thus / Hence

Rule 5 — Kill all template openers

• "One of the most..."
• "This study/project aims to..."
• "It is worth noting that..."
• "It is important to..."
• "The results demonstrate that..."
• "This paper/work investigates..."

---

LOGIC & FLOW RULES (Rules 6, 7, 8)

Rule 6 — Active voice everywhere

• "will be utilized" → "we use"
• "has been examined" → "we read"
• "are split into" → "we divide into"
• "can be used to teach" → "it can help teach"

Rule 7 — Data as action "The dataset contains 80% training data" → "We put 80% of the data into training."

Rule 8 — Uneven tool/item descriptions Multiple tools or roles: vary description length deliberately. Some get explained, some just named, some merged with the next item.

---

SENTENCE-ENDING RULES (Rules 10, 11, 12, 20)

Rule 10 — Extract all bracket explanations "We use ONNX Runtime (which enables CPU-only inference)" → "We use ONNX Runtime. This lets the model run on CPU without a GPU."

Rule 11 — Delete paragraph closing summary sentences Last sentence of every paragraph must be a plain fact. Delete anything that wraps up, explains significance, or connects to a broader theme. Just stop at the last real fact.

Rule 12 (Reinforced) — Cut ALL purpose tails Any "to + verb" explaining WHY → delete:

• "We write it down to plan next steps." → "We write it down."
• "provide an API for the subgroup to use" → cut "to use"
• "so that everyone knows who is responsible" → delete entirely
• "in order to achieve W" → delete entirely

Rule 20 — Delete self-endorsement sentences "so they are quite reliable" / "to keep the method correct" / "to make sure we cover everything" → delete entirely. Authors do not tell readers their sources are reliable. List them. Let readers judge. Any sentence that positively evaluates the author's own method, sources, or results → treat same as Rule 11: delete it.

---

OPENING & FRAMING RULES (Rules 13, 14, 17, 18)

Rule 13 — No identical role/tool description formats Multiple people or tools: no two descriptions use the same sentence structure.

Rule 14 — Delete section cross-references "as explained in Section 4.2" → delete entirely. State the content directly.

Rule 17 (Reinforced) — Delete ALL scope announcements and range claims

• "This has implications in a number of areas." → delete
• "It covers everything from X to Y." → delete ("from X to Y" too)
• "This literature review mainly focuses on A, B and C." → delete
• "The following discusses..." → delete Skip straight to the first real fact.

Rule 18 — Delete function-explainer meta-sentences Delete any sentence explaining what the text is doing rather than doing it:

• "This makes it easy to see how everything fits together." → delete
• "This makes them difficult to apply in small settings." → delete
• "This means that..." → delete opener, state content directly

---

Hidden Synthetic Skeletons That Survive Vocabulary Swaps

Check every output for these before finalizing:

• "We do A and B to achieve C" → cut "to achieve C"
• "X and Y are both..." → split into two sentences
• "The reason is that..." → delete opener, state reason directly
• "This means that..." → delete opener, state content directly
• "cover everything from X to Y" → delete entirely
• "X, while Y" → sentence break between X and Y
• "so they are quite reliable" → delete entirely
• All sentences in paragraph roughly same length → force rhythm variation
• Keyword list with identical formatting → break the pattern

---

Self-Check Before Outputting Result

• Same paragraph count as input?
• Any "both X and Y"? → Split
• Any sentence ending in "to + verb"? → Cut the tail
• Last sentence of each paragraph a plain fact? → Fix or delete
• Any "Furthermore / Moreover"? → Replace or delete
• Any passive voice? → Rewrite with "We"
• Any bracket explanations? → Pull out into own sentence
• Any scope announcement or "from X to Y" range claim? → Delete
• Any "This means that..."? → Delete opener
• Any function-explainer sentence? → Delete
• All list items same length? → Make uneven
• All role/tool descriptions same structure? → Vary them
• Any self-endorsement? → Delete
• Any nested conditional ("If A, then B, even if C")? → Split layers
• All sentences in paragraph roughly same length? → Force rhythm break
• Any keyword/item list with identical formatting? → Break the pattern