Back to Details

write-human

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

write-human

write-human

Write text that sounds like one specific person wrote it for one specific reader — not like a template written for everyone at once. Specific, honest, and short enough to read. If a sentence can be removed without losing anything, remove it.
This is a narrow skill: one job only. It writes and rewrites long-form text — documents, READMEs, copy, explanations. It does not research facts, plan a project, or write code. It feeds the meta-skill 
super-intelligence
, which decides what needs writing and what happens with the text after.
写出像某个具体的人为某个具体的读者所写的内容，而不是像一份面向所有人的模板。具体、坦诚，而且篇幅短到便于阅读。如果删掉某句话不会损失任何信息，就删掉它。
这是一个范围很窄的 skill：只负责一项工作。它用于撰写和改写长文本——文档、README、文案、说明。它不查找事实、不规划项目，也不编写代码。它为元级 skill 
super-intelligence
提供输入，由后者决定需要写什么，以及文本生成后如何处理。

When to load this skill

何时加载此 skill

Load it when ANY of these is true:
  • The user asks to write, rewrite, shorten, or explain something in words: a document, README, message, guide, announcement, or piece of copy
  • The user says existing text "sounds like AI" and wants it to sound like a person wrote it
  • A plan, research result, or build needs to be turned into text a real person will read
Do NOT load it when:
  • The task is to find facts, prices, or sources — use the 
    research
    skill first, then this skill only to write up what was found
  • The task is to plan a project — use the matching skill for the plan, and this skill only for writing it up
  • The task is to write code or build a UI — use the matching skill; this skill writes words, not code
  • The user only wants a one-line answer or a short chat reply — just answer plainly, do not load a whole skill
出现以下任一情况时加载此 skill：
  • 用户要求用文字撰写、改写、缩短或解释某项内容，例如文档、README、消息、指南、公告或文案
  • 用户表示现有文字“听起来像 AI”，并希望它更像人写的
  • 计划、研究结果或构建成果需要转化为真实读者会阅读的文本
以下情况不要加载此 skill：
  • 任务是查找事实、价格或来源——先使用 
    research
    skill，然后仅使用本 skill 整理已找到的内容
  • 任务是规划项目——使用对应的规划 skill，然后仅使用本 skill 整理规划内容
  • 任务是编写代码或构建 UI——使用对应的 skill；本 skill 只写文字，不写代码
  • 用户只需要一句话的答案或简短的聊天回复——直接回答即可，不必加载整个 skill

Steps

步骤

1. Clarify the reader and the point (1 question at a time)

1. 明确读者和核心信息（一次只问一个问题）

Restate, in the user's words: who reads this, what should they understand or do after reading it, and how long should it be. Ask the ONE question whose answer would most change the text — usually "who is this for, and what do they need to do next?" If the request is already clear, skip the question and start. Do not interrogate the user for a short rewrite.
用用户自己的话复述：谁会阅读它，读完后应该理解或采取什么行动，以及应该写多长。提出那个最能影响成文效果的问题——通常是“这是写给谁的，他们接下来需要做什么？”如果请求已经清楚，就跳过提问，直接开始。不要为一次简短改写连续盘问用户。

2. Gather the facts first — do not invent them

2. 先收集事实——不要编造

  • Use only facts already in the conversation, in files the user gave you, or in research that was actually done. A fact without a source is a draft, not a finding.
  • Copy names, numbers, dates, prices, file paths, commands, and quotes exactly as the source wrote them. Do not paraphrase a number. Do not round a price to make it look nicer.
  • If a fact is needed and not available, do one of these: ask the user, run the 
    research
    skill, or mark it clearly as unverified — never fill the gap with a confident-sounding guess.
  • If the user gave you a claim you cannot verify, do not repeat it as fact. Write "the user says" or leave it out, and say so.
  • 只使用对话中已有、用户提供文件中已有，或实际完成的研究所提供的事实。没有来源的事实只是草稿，不是查证结论。
  • 准确复制来源中的名称、数字、日期、价格、文件路径、命令和引文。不要改写数字的含义，也不要为了好看而对价格进行四舍五入。
  • 如果需要某项事实但目前无法获得，可以询问用户、运行 
    research
    skill，或清楚地将其标为未核实——绝不能用听起来很确定的猜测填补空白。
  • 如果用户提供的主张无法核实，不要将其作为事实重复。可以写“用户表示”，也可以略去，并说明原因。

3. Draft in the user's language, in this order

3. 使用用户的语言，按以下顺序起草

Write in the language the user is using. If they switch language, switch with them. Structure the draft as:
  • The point first — the direct answer or the one thing the reader must know, in 2-3 sentences.
  • The details — only what the reader needs to act on, in the order they need it.
  • What is not known yet — stated plainly, if anything is unverified or undecided.
Rules for the draft:
  • One concrete detail beats ten generic adjectives. "Installed 9router 0.5.109, tested /v1/models, it answered" beats "successfully leveraged cutting-edge AI infrastructure".
  • Vary the rhythm. Mix short sentences with longer ones.
  • Use the user's own terms and names, exactly as they wrote them.
  • Admit limits plainly: "I could not verify this price" is human. Inventing a price is not.
  • Cut a sentence if removing it loses nothing. Let one honest detail carry the paragraph.
使用用户正在使用的语言起草。如果用户切换语言，你也随之切换。按以下顺序组织草稿：
  • 先说重点——直接给出答案，或说明读者必须知道的一件事，用 2 至 3 句话。
  • 具体细节——只保留读者采取行动所需的信息，并按行动所需的顺序排列。
  • 尚不确定的内容——如果存在未核实或尚未决定的事项，就直截了当地说明。
起草规则：
  • 一个具体细节胜过十个笼统形容词。“已安装 9router 0.5.109，测试了 /v1/models，并且成功作答”比“成功利用前沿 AI 基础设施”更有说服力。
  • 改变句子节奏。混合使用短句和长句。
  • 准确沿用用户自己的术语和名称，不做改写。
  • 直白地承认限制：“我无法核实这个价格”才像真人在说话，而编造价格不是。
  • 如果删掉一句话不会损失任何信息，就删掉它。让一个诚实而具体的细节承担整段的重点。

4. Run the humanize check

4. 执行人性化检查

Read the draft out loud. If it sounds like a template, a press release, or a motivational poster, rewrite it.
Remove all of these:
  • Openers like "Great question!" / "I'd be happy to help!"
  • Emoji bullets, ALL-CAPS hype, and words like "revolutionary / game-changing / next-level / ultimate" unless the user wrote those words
  • Invented statistics, testimonials, or "studies show"
  • Generic praise ("amazing", "incredible", "perfect") with nothing concrete behind it
  • Generic empathy that adds no information ("I understand how frustrating this must be...")
  • Confident language that smooths over a failure. Say what failed, in plain words.
Keep all of these:
  • Specific numbers, names, and dates the reader can check
  • Short sentences that say one thing
  • "I don't know" where you don't know
  • The user's language and tone, not a corporate voice
朗读草稿。如果它听起来像模板、新闻稿或励志海报，就重写。
删除以下内容：
  • “好问题！”或“我很乐意帮忙！”之类的开场白
  • Emoji 项目符号、全大写式炒作，以及“颠覆性”“改变游戏规则”“全新升级”“终极”之类的词语，除非用户原本就使用了这些词
  • 编造的统计数据、用户评价或“研究表明”
  • 背后没有具体内容支撑的泛泛赞美，如“惊艳”“不可思议”“完美”
  • 不提供任何新信息的泛泛共情，如“我理解这一定非常令人沮丧……”
  • 用自信语气掩盖失败。直接说明哪里失败了。
保留以下内容：
  • 读者可以核查的具体数字、名称和日期
  • 每句话只表达一件事的短句
  • 不知道时坦率地说“我不知道”
  • 用户的语言和语气，而不是企业式的腔调

5. Verify before delivering

5. 交付前核查

  • Re-read every number, date, name, and quote against its source. One wrong digit is worse than a missing sentence.
  • Check the length: if the user asked for short, cut it in half and check it still answers the question.
  • Check the audience: would this reader understand every word? If a term needs explaining, explain it in one clause or drop it.
  • 对照来源重新检查每一个数字、日期、名称和引文。错一个数字比少写一句话更糟。
  • 检查篇幅：如果用户要求简短内容，就把篇幅减半，再确认它仍然回答了问题。
  • 检查受众：这位读者能理解每一个词吗？如果某个术语需要解释，就用一个分句说清楚；否则删掉它。

Before / after

修改前 / 修改后

Before (slop — a README intro for a small skill repo):
"🚀 Welcome to the ultimate Super-Intelligence experience! Our revolutionary AI skill will transform your workflow by 10,000%! Unlock next-level productivity with cutting-edge technology loved by millions around the world!"
Why it fails: every claim is invented (no users, no measured improvement), it says nothing about what the skill does, and it reads like a template for any product.
After (human — same repo, same intro):
"This is v0.1. It does one thing: it turns a vague request into a short plan, checks each step, then rewrites the answer so it sounds like a person wrote it. It does not do everything yet. Install it with 
npx skills add Dardcor/Super-Intelligence
."
Why it passes: it says what the thing is, what it does, what it does not do, and how to install it — in four sentences, with nothing invented.
修改前（空洞文案——一个小型 skill 仓库的 README 简介）：
“🚀 欢迎体验终极 Super-Intelligence！ 我们的革命性 AI skill 将让你的工作流提升 10,000%！ 解锁由前沿技术带来的全新生产力，并深受全球数百万人的喜爱！”
失败原因：每一项说法都是编造的（没有用户数量，也没有可衡量的改进），它没有说明这个 skill 做什么，而且读起来像一份适用于任何产品的模板。
修改后（自然表达——同一个仓库，同一段简介）：
“这是 v0.1。它只做一件事：把模糊的请求变成简短计划，逐步检查，然后将答案改写得更像人写的。它目前还做不到所有事情。使用 
npx skills add Dardcor/Super-Intelligence
安装。”
通过原因：它说明了这个东西是什么、能做什么、不能做什么，以及如何安装——总共四句话，没有任何编造内容。

Delivery Gate

交付检查

Before you deliver the text, pass ALL of these:
  • It answers what was actually asked, not a nearby topic
  • Every number, date, name, and quote was copied exactly from its source
  • Unverified items are labelled unverified, not hidden
  • No hype, no emoji bullets, no invented statistics, praise, or testimonials
  • It reads out loud like one person wrote it for one reader — no template voice
  • It is in the user's language, and short enough to read in the time the user has
  • Nothing in it claims a human identity, history, or experience the writer does not have
If a check fails, fix it or say so plainly. Do not ship a confident-sounding text with invented facts inside.
交付文本前，必须通过以下所有检查：
  • 它回答了用户实际提出的问题，而不是相近但不同的话题
  • 每个数字、日期、名称和引文都从来源中准确复制
  • 未核实的事项已明确标为未核实，而不是被隐藏
  • 没有炒作、Emoji 项目符号、编造的统计数据、赞美或用户评价
  • 朗读时像某个具体的人写给某个具体读者，而不像模板腔
  • 使用用户的语言，且篇幅适合用户可用的阅读时间
  • 其中没有任何内容声称作者具有并不存在的人类身份、经历或体验
如果某项检查未通过，就修正内容或直说。不要交付一篇语气自信、却夹带虚构事实的文本。

What this skill will never do

此 skill 永远不会做的事

  • Invent facts, prices, dates, citations, testimonials, or "studies".
  • Present a guess as a verified result.
  • Pretend to be a real human, or claim a human identity, history, feelings, or experience it does not have.
  • Write deceptive copy: hidden costs, fake urgency, fake social proof, or a claim the product cannot back up.
  • Do illegal, deceptive, or harmful work because the user said "by any means". Offer the lawful alternative instead.
  • Extract credentials, tokens, or quota from another system.
  • 编造事实、价格、日期、引用、用户评价或“研究”
  • 把猜测当作已经核实的结果
  • 假装自己是真实的人，或声称拥有并不存在的人类身份、经历、感受或体验
  • 编写欺骗性文案，例如隐瞒费用、制造虚假紧迫感、伪造社会认同，或作出产品无法证明的主张
  • 因为用户说“不惜一切手段”就从事违法、欺骗或有害的工作。应当改为提供合法可行的方案
  • 提取其他系统中的 credentials、tokens 或 quota

Example

示例

See 
examples/readme-rewrite.md
for a full input → output example: a slop README intro rewritten as human text, with each change explained.
完整示例请参阅 
examples/readme-rewrite.md
：它展示了一个空洞的 README 简介如何被改写成自然文字，并解释了每项改动的原因。