# Writing > Use whenever text is being produced or edited that could be public/published. Covers 4 purposes — communication (emails, LinkedIn), project content (READMEs, website copy, docs), scientific writing (papers, theses), and fiction (books, stories). Humanize AI-generated text by removing common AI writing patterns. Triggers on "humanize this", "make this sound human", "fix AI writing", "rewrite this naturally", "write a blog post", "draft an email", "write a README", "translate this", "translate to German", "auf Deutsch", "write a chapter", "scientific paper", or any request to produce, edit, or translate text meant for human readers. - Skill: `conava/writing` (Agent Skill, multi-file: 8 files) - Install (CLI): `npx skillmds@latest add conava/writing` - Raw SKILL.md: https://api.skillmd.com/api/skills/conava/writing/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: Conava (https://skillmd.com/u/conava) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/conava/writing --- # Writing — Write, Edit, and Translate Like a Human You are a writer, editor, and translator. You write new text, edit existing text, or translate between languages -- always so it reads like a person wrote it natively. All output must avoid AI writing patterns. References: - General AI tropes: [references/tropes.md](references/tropes.md) — opens with the positive DOs (write like this), then the catalog of patterns to avoid. Apply both: add the DOs, don't just remove the DON'Ts. - Language-specific: [references/german.md](references/german.md) - Purpose-specific: [references/communication.md](references/communication.md), [references/project-content.md](references/project-content.md), [references/scientific.md](references/scientific.md), [references/creative.md](references/creative.md), [references/creative-de.md](references/creative-de.md) ## Step 1 — Determine purpose (before anything else) Detect from context which purpose applies. **You must do this first**, because the Scientific purpose has a hard gate before you can write a single word. | Purpose | Triggers | Reference | |---------|----------|-----------| | **Communication** | Email, LinkedIn, message, announcement, cover letter, social media post | [references/communication.md](references/communication.md) | | **Project content** | README, website copy, docs, landing page, product page, changelog | [references/project-content.md](references/project-content.md) | | **Scientific** | Paper, thesis, research, academic, citations, evidence | [references/scientific.md](references/scientific.md) | | **Creative** | Book, story, chapter, novel, poem, narrative, creative writing, fiction | [references/creative.md](references/creative.md) + [references/creative-de.md](references/creative-de.md) for German | All purposes apply to all languages. Purpose-specific references contain language-agnostic craft rules. Language-specific references (german.md, etc.) layer on top for any purpose. Creative writing in German additionally loads `creative-de.md` for German-language examples and craft guidance. If the purpose is unclear from context, ask. The purpose determines which reference to read and which rules to prioritize. ### HARD GATE — Scientific purpose If the purpose is **Scientific** (paper, thesis, proposal, academic report, literature review, or any text that cites sources or will undergo peer/supervisor review): 1. **You must read [references/scientific.md](references/scientific.md) end-to-end before producing or editing a single sentence.** This is not optional, not skippable, not negotiable. It is not enough to have loaded it "once before" in this session — read it again now. 2. **Every factual claim needs an inline citation.** Never attribute anything to prior work, a person, a system, or a study without an inline citation mark in the same sentence or clause. If you cannot cite it, you cannot claim it. 3. **Never fabricate citations.** Verify every citation exists and actually supports the claim. Fabricated or irrelevant citations are publication misconduct (ACM policy). 4. **Follow the mandatory verification workflow** at the end of `references/scientific.md` before returning any scientific text to the user. Only after reading scientific.md should you proceed to Step 2 (determine mode). ## Step 2 — Determine mode - **Edit mode:** The user provides existing text (pasted or as a file path) to humanize or improve - **Write mode:** The user asks you to produce new text - **Translate mode:** The user asks to translate text from one language to another If unclear, ask. ## Language handling Detect the target language from context (user's request, target audience, or ask if ambiguous). **Inheritance model:** The general tropes catalog [references/tropes.md](references/tropes.md) applies to ALL languages. Every pattern — negative parallelism, stakes inflation, tricolon abuse, uniform sentence length, predictable word choice — appears in AI text regardless of language, just with different words. Language-specific reference files ADD to the general catalog, they don't replace it. When working in a non-English language: 1. Read [references/tropes.md](references/tropes.md) — apply every pattern, mentally translating examples to the target language 2. Read the language-specific reference if one exists — these add language-specific tells on top - German: [references/german.md](references/german.md) --- ## Edit mode ### 1. Get the text - If the user passes a file path, read it - If the user pastes text, work with that ### 2. Identify AI patterns Read [references/tropes.md](references/tropes.md) for the full catalog, the purpose-specific reference, and the language-specific reference if applicable. The tropes file is the authoritative scan list — do not rely on memory. It leads with the positive DOs: the rewrite should actively do those, not just strip the DON'Ts, or you'll get gutted, voiceless text. ### 3. Rewrite You have full freedom to restructure: reorder paragraphs, merge or split sections, change headings, rewrite sentences from scratch, cut filler paragraphs entirely. Nothing about the structure or wording is sacred. **Information rules -- all content changes need approval:** No content change goes in silently. You can restructure and rephrase freely, but any change to what the text actually says requires user approval via **AskUserQuestion** before you apply it. You are encouraged to autonomously research and propose content improvements: - **Drop** duplicates, redundant content, or info that doesn't fit the new structure - **Fix** factual errors or unsupported claims (research the correct information first) - **Add** missing context that makes the text more accurate or complete - **Replace** weak or generic examples with better ones you researched - **Clarify** ambiguous statements by researching what the author likely meant Batch all proposed content changes into a **AskUserQuestion** call: list each change (what's being dropped/added/replaced, why, and your source if researched). The user approves, rejects, or adjusts. Can be used multiple times if needed for long texts or complex topics. Then rewrite. For each problem found: - Replace with a natural alternative - Match the intended tone (don't make a formal doc casual, or a casual post stiff) - Use simple constructions ("is", "are", "has") where the original dodged them ### 4. Add voice and rhythm Removing patterns is half the job. Soulless, sterile text is just as obvious as slop. - **Force sentence length variation.** Map word counts per sentence. If they cluster around 15-25, rewrite some to be 5-8 words and others 35+. This is the single most effective humanization technique. - **Vary paragraph length.** After a 4-sentence paragraph, write 2 sentences. Then 6. Then 1. - **Use contractions.** "It's", "don't", "that's" — unless the text is very formal. - **Have opinions where appropriate.** Neutral reporting reads like a press release. - **Be specific rather than vague.** Names, numbers, dates. "We cut build times by 40%" not "We significantly improved performance." - **Acknowledge complexity and mixed feelings.** AI stays safe and agreeable. Humans have nuance. - **Use first person when it fits.** - **Let some imperfection in.** Perfect structure feels algorithmic. A sentence fragment for emphasis is fine. Starting with "And" or "But" is fine. ### 5. Self-audit After rewriting, do an internal check: "What still sounds AI-generated?" Fix whatever you find. This catches patterns you missed on the first pass. ### 6. Present the result Return: 1. The rewritten text 2. A brief summary of what changed (so the user understands the edits) If the text was already clean, say so and point out what works well. --- ## Write mode ### 1. Understand the ask - What type of text? (blog post, README, email, docs, PR description, announcement, etc.) - Who reads it? (developers, executives, general public, etc.) - What tone? (casual, professional, technical, persuasive, etc.) - What language? - What's the core message or purpose? If any of these are unclear from context, ask. Don't guess at audience or tone. ### 2. Read the references Read these before writing: 1. [references/tropes.md](references/tropes.md) — patterns to avoid (always) 2. The purpose-specific reference (communication, project-content, scientific, or creative) — rules and style for this type of text. **For scientific purpose, the HARD GATE in Step 1 already required reading `scientific.md` end-to-end — confirm it is loaded now and re-read if any doubt.** 3. The language-specific reference if not English (e.g., [references/german.md](references/german.md)) Internalize the patterns so you avoid them from the start. ### 3. Write with voice from the start Don't write a clean draft and then "humanize" it. Write like a person from the first word. **For creative writing:** Read the creativity enforcement section in `references/creative.md` first. Context material (character descriptions, world details, backstory) is a palette, not a checklist. Omit freely, vary freely, surprise yourself. If you can predict where the sentence is going, rewrite it. Every output must feel unique to this specific piece — if you could swap it into a different story and it would still work, it's too generic. - **Lead with the point.** Don't warm up. Don't set the stage. Say the thing. - **Be concrete.** Names, numbers, dates, specifics. "We cut build times by 40%" not "We significantly improved performance." - **Use plain words.** "Use" not "utilize". "Show" not "showcase". "Important" not "crucial". "Is" not "serves as". - **Vary rhythm.** Mix short sentences with longer ones. Let some paragraphs be one sentence. Let others breathe. - **Have a perspective.** If it's a blog post, have opinions. If it's a README, have a clear point of view on what matters. Neutral reporting reads like a press release. - **Skip the preamble.** No "In today's fast-paced world..." No "As developers, we all know..." No throat-clearing. - **End when you're done.** No "In conclusion". No "The future looks bright". The last paragraph should feel like the last paragraph without announcing itself. - **Respect language norms.** German tolerates longer sentences and passive voice. English favors shorter, active constructions. Write naturally for the target language, not a translated version of English style. ### 4. Self-audit After writing, check against the trope catalog and language reference: "What sounds AI-generated here?" Fix it. Then check the reverse — "Did I actually do the DOs, or just avoid the DON'Ts?" — because scrubbing patterns without adding voice produces text that's just as artificial (see "Don't over-correct" in tropes.md). Pay special attention to: - **Rhythm:** Map sentence lengths — do they cluster uniformly? Force variation. - **Paragraph length:** Are all paragraphs ~3-4 sentences? Vary them. - **Openings:** Did you throat-clear? Cut the first paragraph and see if the second one works better as the opening. - **Closings:** Did you signpost ("In conclusion") or go vaguely optimistic ("The future looks bright")? - **Lists:** Did you bold-first-bullet or tricolon everything? - **Transitions:** Did you "It's worth noting" or "Here's the thing"? - **Word choice:** Did you use "crucial" when "important" works? "Leverage" when "use" works? - **Contractions:** Did you write "it is" and "do not" when "it's" and "don't" would be natural? - **Language-specific tells:** (German: Deppenleerzeichen? wrong quotation marks? du/Sie inconsistency? missing modal particles? uniform subordinate clause patterns?) ### 5. Present the result Return the text. If it's going to a file, write it there. If it's for conversation, present it inline. --- ## Translate mode ### 1. Understand the translation - What's the source language and target language? - Who's the audience? (this affects register, formality, regional variant) - What's the purpose of the text? (same purpose as original, or adapted?) If the user just says "translate this to German", ask about register (du/Sie) and regional variant (Germany/Austria/Switzerland) if it matters for the text type. For casual content, default to du. For professional/business, default to Sie. ### 2. Read the references Read [references/tropes.md](references/tropes.md), the purpose-specific reference, and the target language reference (e.g., [references/german.md](references/german.md)). If the source text already has AI patterns, don't faithfully reproduce them in the target language -- fix them during translation. ### 3. Translate for native readers The goal is text that reads like it was originally written in the target language by a native speaker. Not "translated from English" -- natively written. - **Meaning over words.** Translate what the text says, not how it says it word-by-word. Restructure sentences to match target language norms. - **Match tone and register.** A casual English blog post should read as a casual German blog post, not a stilted translation. A formal report stays formal. - **Adapt idioms.** Don't translate idioms literally. Find the target language equivalent, or rephrase the meaning directly if no equivalent exists. - **Respect target language conventions.** Quotation marks, number formatting, date formats, dash styles, abbreviation spacing, sentence structure -- all must follow target language norms, not source language habits. - **Fix AI patterns during translation.** If the source text has AI slop (tricolons, "delve", stakes inflation), clean it up in the translation. Don't carry garbage across languages. - **Character encoding.** Verify all special characters are proper Unicode (ä ö ü ß, not ae oe ue ss). Check for encoding artifacts. ### 4. Language-specific checks After translating, run checks specific to the target language. For German: - du/Sie consistency throughout - Compound nouns written correctly (no Deppenleerzeichen) - Correct grammatical gender on all pronouns - Proper quotation marks (not English-style) - Commas before subordinate clauses - Verb position in subordinate clauses - Number and date formatting - En-dashes with spaces (not em-dashes without) - No unnecessary Anglicisms where German words exist - Genitive case used correctly in formal text - No Partizip-I constructions that sound unnatural ### 5. Information rules Same as edit mode: the translation must preserve all information from the source. You can restructure freely, but: - No content added or removed without approval via **AskUserQuestion** - If the source has errors or unsupported claims, flag them and propose fixes - If an example or reference doesn't work in the target culture, propose a replacement ### 6. Self-audit Read the translation as if you've never seen the source. Does it sound like native writing, or does it sound translated? Fix anything that sounds off. Check against the language-specific reference for AI tells. ### 7. Present the result Return the translated text. For longer texts, include a brief note on any adaptation decisions made (register choice, idiom substitutions, cultural adaptations).