{ "schemaVersion": "1.0", "item": { "slug": "academic-writing-refiner", "name": "academic-writing-refiner", "source": "tencent", "type": "skill", "category": "开发工具", "sourceUrl": "https://clawhub.ai/Zihan-Zhu/academic-writing-refiner", "canonicalUrl": "https://clawhub.ai/Zihan-Zhu/academic-writing-refiner", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/academic-writing-refiner", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=academic-writing-refiner", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md", "references/rebuttal-guide.md", "references/section-guide.md", "references/word-choice.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-05-07T17:22:31.273Z", "expiresAt": "2026-05-14T17:22:31.273Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-annual-report", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=afrexai-annual-report", "contentDisposition": "attachment; filename=\"afrexai-annual-report-1.0.0.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/academic-writing-refiner" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/academic-writing-refiner", "agentPageUrl": "https://openagent3.xyz/skills/academic-writing-refiner/agent", "manifestUrl": "https://openagent3.xyz/skills/academic-writing-refiner/agent.json", "briefUrl": "https://openagent3.xyz/skills/academic-writing-refiner/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "Academic Writing Refiner", "body": "This skill transforms rough or intermediate academic drafts into polished, publication-ready prose for top-tier CS conferences. The goal is writing that is clear, precise, and accessible to a broad technical audience — the kind of writing that reviewers at venues like NeurIPS, ICML, or ACL appreciate because it respects their time and communicates ideas efficiently." }, { "title": "Core Philosophy", "body": "Top CS conferences share a common expectation: writing should be a transparent window into the ideas, not a display of vocabulary. The best papers at NeurIPS, ACL, or KDD succeed not because they use impressive words, but because every sentence earns its place and every paragraph advances the reader's understanding.\n\nThis means:\n\nClarity over cleverness: Use the simplest word that precisely conveys the meaning. \"Use\" instead of \"utilize\", \"show\" instead of \"demonstrate\" (unless you mean a formal proof/demonstration), \"many\" instead of \"a plethora of\".\nPrecision over vagueness: Replace hedging language with specific claims. Instead of \"our method performs quite well\", say \"our method achieves 94.3% accuracy, outperforming the strongest baseline by 2.1 points\".\nEconomy over verbosity: Every sentence should do work. If removing a sentence doesn't lose information, remove it.\nFlow over fragmentation: Guide the reader from one idea to the next with logical connectives, not abrupt jumps." }, { "title": "How to Refine", "body": "When a user provides text to refine, follow this process:" }, { "title": "1. Understand the Context", "body": "Before editing, figure out:\n\nWhat section is this? (abstract, introduction, related work, methodology, experiments, conclusion) — each has different conventions.\nWhat venue? If stated, tailor to that venue's style norms. ML venues (NeurIPS, ICML, ICLR) tend toward concise, equation-heavy writing. NLP venues (ACL, EMNLP, NAACL) often expect more linguistic precision and thorough related work. IR/Web venues (SIGIR, WWW, KDD, CIKM) often need clear problem motivation tied to practical impact.\nWhat stage? A first draft needs structural help; a camera-ready needs polish.\n\nIf the user doesn't specify, infer from content and ask only if genuinely ambiguous." }, { "title": "2. Apply Section-Specific Conventions", "body": "Read references/section-guide.md for detailed conventions per section type. The key principles:\n\nAbstract: Should be self-contained, state the problem, approach, key result (with numbers), and significance — all in ~150–250 words. No citations, no undefined acronyms.\n\nIntroduction: Problem → gap → contribution → brief results → paper outline. The reader should understand what you did and why it matters within the first page.\n\nRelated Work: Group by theme, not by paper. Each paragraph should end by distinguishing the current work from what was just discussed. Avoid \"laundry list\" style (X did A. Y did B. Z did C.).\n\nMethodology: Present the approach in logical order. Define notation before using it. Use equations for precision but always provide intuition in words alongside them.\n\nExperiments: Lead with research questions or hypotheses, then describe setup, then results. Tables and figures should be self-contained with descriptive captions.\n\nConclusion: Summarize contributions (not the whole paper), acknowledge limitations honestly, suggest concrete future directions." }, { "title": "3. Sentence-Level Refinement", "body": "Consult references/word-choice.md for a quick-reference table of common substitutions (fancy → simple, filler → delete, hedging calibration, and transition connectives). Apply these transformations systematically:\n\nTighten prose:\n\nRemove filler phrases: \"it is worth noting that\", \"it should be mentioned that\", \"in order to\" → \"to\"\nEliminate redundancy: \"completely eliminate\" → \"eliminate\", \"future plans\" → \"plans\"\nConvert passive to active where it improves clarity: \"the model was trained by us\" → \"we trained the model\"\nBut keep passive voice when the agent is unimportant: \"the dataset was collected from public sources\" is fine\n\nFix common academic writing issues:\n\nDangling modifiers: \"Using gradient descent, the loss decreases\" → \"Using gradient descent, we minimize the loss\"\nNoun pile-ups: \"multi-task learning based pre-trained language model fine-tuning approach\" → break it up with prepositions\nVague referents: \"This shows that...\" — what does \"this\" refer to? Make it explicit\nOrphan claims: every claim about performance needs a citation or experimental reference\n\nStrengthen transitions:\n\nBetween sentences: use logical connectives that signal the relationship (however, therefore, specifically, in contrast, building on this)\nBetween paragraphs: the first sentence of each paragraph should connect to the previous paragraph's conclusion\nBetween sections: the last paragraph of a section should preview what comes next" }, { "title": "4. LaTeX-Specific Handling", "body": "When the input contains LaTeX:\n\nPreserve all \\cite{}, \\ref{}, \\label{}, equation environments, and custom macros exactly as written\nFix only the prose — do not modify mathematical content unless there is a clear notational inconsistency\nMaintain \\textbf{}, \\textit{}, \\emph{} formatting choices\nEnsure consistent notation: if the user writes $\\mathbf{x}$ in one place and $\\boldsymbol{x}$ in another for the same quantity, flag it\nKeep ~ (non-breaking spaces) before \\cite and \\ref\nPreserve % comments\nDo not add or remove \\paragraph{}, \\subsubsection{} etc. unless the user asks for structural changes" }, { "title": "5. What NOT to Do", "body": "These are equally important as what to do:\n\nDo not insert fancy vocabulary. \"Leverage\" is almost never better than \"use\". \"Elucidate\" is almost never better than \"explain\". If the original uses a simple word correctly, keep it.\nDo not over-hedge. Academic writing needs appropriate qualification (\"may\", \"suggests\"), but excessive hedging (\"it could potentially be argued that this might possibly indicate\") undermines confidence in the work.\nDo not add content. Refine what is there. If something is missing (e.g., no related work comparison, no baseline), flag it as a suggestion but do not invent claims or results.\nDo not homogenize voice. If the author has a distinct (but correct) style, preserve it. The goal is to polish, not to flatten.\nDo not use em-dashes excessively. Parentheses or restructured sentences are usually cleaner in academic writing. One em-dash pair per paragraph at most.\nDo not introduce semicolons liberally. Prefer shorter sentences joined by appropriate connectives over long semicolon-connected chains." }, { "title": "Output Format", "body": "When presenting refined text:\n\nProvide the refined version as the primary output, clearly separated from commentary\nAdd brief marginal notes for substantive changes — explain why you changed something when the reason isn't obvious (e.g., \"Restructured to lead with the contribution rather than the gap\" or \"Made the comparison to X explicit\")\nFlag issues you cannot fix — missing citations, unclear experimental details, potential factual concerns — as a separate list at the end\nIf the input is LaTeX, output LaTeX. If the input is plain text, output plain text. Match the format." }, { "title": "Interaction Patterns", "body": "Full paper refinement: If the user provides an entire paper (or most of one), work section by section. Start with whichever section the user indicates, or begin with the abstract and introduction since those set the tone.\n\nSingle section: Apply the full refinement process to that section.\n\nQuick polish: If the user says \"just fix the grammar\" or \"light edit only\", respect that — fix spelling, grammar, and punctuation without restructuring or rewriting.\n\nIterative refinement: After providing a refined version, be ready for feedback like \"too formal\", \"I want to keep the original structure of paragraph 2\", or \"make the motivation stronger\". Apply changes surgically without re-editing the rest.\n\nRebuttal writing: When the user mentions a rebuttal or reviewer response, read references/rebuttal-guide.md for specific advice on crafting effective rebuttals." }, { "title": "Common Venue-Specific Notes", "body": "Venue GroupStyle TendenciesNeurIPS, ICML, ICLRConcise, equation-centric. Theoretical rigor valued. Anonymous review — remove self-identifying references.AAAI, IJCAIBroader AI scope. Motivation and real-world relevance important. Slightly more expository than ML-focused venues.ACL, EMNLP, NAACLThorough related work expected. Linguistic precision in terminology. Error analysis and ablation studies valued.CVPRVisual results critical. Qualitative examples alongside quantitative. Clear figure descriptions.WWW, KDD, SIGIR, CIKMProblem-driven motivation. Scalability and practical impact often expected. Dataset descriptions need care.\n\nThese are tendencies, not rigid rules — good writing is good writing regardless of venue." } ], "body": "Academic Writing Refiner\n\nThis skill transforms rough or intermediate academic drafts into polished, publication-ready prose for top-tier CS conferences. The goal is writing that is clear, precise, and accessible to a broad technical audience — the kind of writing that reviewers at venues like NeurIPS, ICML, or ACL appreciate because it respects their time and communicates ideas efficiently.\n\nCore Philosophy\n\nTop CS conferences share a common expectation: writing should be a transparent window into the ideas, not a display of vocabulary. The best papers at NeurIPS, ACL, or KDD succeed not because they use impressive words, but because every sentence earns its place and every paragraph advances the reader's understanding.\n\nThis means:\n\nClarity over cleverness: Use the simplest word that precisely conveys the meaning. \"Use\" instead of \"utilize\", \"show\" instead of \"demonstrate\" (unless you mean a formal proof/demonstration), \"many\" instead of \"a plethora of\".\nPrecision over vagueness: Replace hedging language with specific claims. Instead of \"our method performs quite well\", say \"our method achieves 94.3% accuracy, outperforming the strongest baseline by 2.1 points\".\nEconomy over verbosity: Every sentence should do work. If removing a sentence doesn't lose information, remove it.\nFlow over fragmentation: Guide the reader from one idea to the next with logical connectives, not abrupt jumps.\nHow to Refine\n\nWhen a user provides text to refine, follow this process:\n\n1. Understand the Context\n\nBefore editing, figure out:\n\nWhat section is this? (abstract, introduction, related work, methodology, experiments, conclusion) — each has different conventions.\nWhat venue? If stated, tailor to that venue's style norms. ML venues (NeurIPS, ICML, ICLR) tend toward concise, equation-heavy writing. NLP venues (ACL, EMNLP, NAACL) often expect more linguistic precision and thorough related work. IR/Web venues (SIGIR, WWW, KDD, CIKM) often need clear problem motivation tied to practical impact.\nWhat stage? A first draft needs structural help; a camera-ready needs polish.\n\nIf the user doesn't specify, infer from content and ask only if genuinely ambiguous.\n\n2. Apply Section-Specific Conventions\n\nRead references/section-guide.md for detailed conventions per section type. The key principles:\n\nAbstract: Should be self-contained, state the problem, approach, key result (with numbers), and significance — all in ~150–250 words. No citations, no undefined acronyms.\n\nIntroduction: Problem → gap → contribution → brief results → paper outline. The reader should understand what you did and why it matters within the first page.\n\nRelated Work: Group by theme, not by paper. Each paragraph should end by distinguishing the current work from what was just discussed. Avoid \"laundry list\" style (X did A. Y did B. Z did C.).\n\nMethodology: Present the approach in logical order. Define notation before using it. Use equations for precision but always provide intuition in words alongside them.\n\nExperiments: Lead with research questions or hypotheses, then describe setup, then results. Tables and figures should be self-contained with descriptive captions.\n\nConclusion: Summarize contributions (not the whole paper), acknowledge limitations honestly, suggest concrete future directions.\n\n3. Sentence-Level Refinement\n\nConsult references/word-choice.md for a quick-reference table of common substitutions (fancy → simple, filler → delete, hedging calibration, and transition connectives). Apply these transformations systematically:\n\nTighten prose:\n\nRemove filler phrases: \"it is worth noting that\", \"it should be mentioned that\", \"in order to\" → \"to\"\nEliminate redundancy: \"completely eliminate\" → \"eliminate\", \"future plans\" → \"plans\"\nConvert passive to active where it improves clarity: \"the model was trained by us\" → \"we trained the model\"\nBut keep passive voice when the agent is unimportant: \"the dataset was collected from public sources\" is fine\n\nFix common academic writing issues:\n\nDangling modifiers: \"Using gradient descent, the loss decreases\" → \"Using gradient descent, we minimize the loss\"\nNoun pile-ups: \"multi-task learning based pre-trained language model fine-tuning approach\" → break it up with prepositions\nVague referents: \"This shows that...\" — what does \"this\" refer to? Make it explicit\nOrphan claims: every claim about performance needs a citation or experimental reference\n\nStrengthen transitions:\n\nBetween sentences: use logical connectives that signal the relationship (however, therefore, specifically, in contrast, building on this)\nBetween paragraphs: the first sentence of each paragraph should connect to the previous paragraph's conclusion\nBetween sections: the last paragraph of a section should preview what comes next\n4. LaTeX-Specific Handling\n\nWhen the input contains LaTeX:\n\nPreserve all \\cite{}, \\ref{}, \\label{}, equation environments, and custom macros exactly as written\nFix only the prose — do not modify mathematical content unless there is a clear notational inconsistency\nMaintain \\textbf{}, \\textit{}, \\emph{} formatting choices\nEnsure consistent notation: if the user writes $\\mathbf{x}$ in one place and $\\boldsymbol{x}$ in another for the same quantity, flag it\nKeep ~ (non-breaking spaces) before \\cite and \\ref\nPreserve % comments\nDo not add or remove \\paragraph{}, \\subsubsection{} etc. unless the user asks for structural changes\n5. What NOT to Do\n\nThese are equally important as what to do:\n\nDo not insert fancy vocabulary. \"Leverage\" is almost never better than \"use\". \"Elucidate\" is almost never better than \"explain\". If the original uses a simple word correctly, keep it.\nDo not over-hedge. Academic writing needs appropriate qualification (\"may\", \"suggests\"), but excessive hedging (\"it could potentially be argued that this might possibly indicate\") undermines confidence in the work.\nDo not add content. Refine what is there. If something is missing (e.g., no related work comparison, no baseline), flag it as a suggestion but do not invent claims or results.\nDo not homogenize voice. If the author has a distinct (but correct) style, preserve it. The goal is to polish, not to flatten.\nDo not use em-dashes excessively. Parentheses or restructured sentences are usually cleaner in academic writing. One em-dash pair per paragraph at most.\nDo not introduce semicolons liberally. Prefer shorter sentences joined by appropriate connectives over long semicolon-connected chains.\nOutput Format\n\nWhen presenting refined text:\n\nProvide the refined version as the primary output, clearly separated from commentary\nAdd brief marginal notes for substantive changes — explain why you changed something when the reason isn't obvious (e.g., \"Restructured to lead with the contribution rather than the gap\" or \"Made the comparison to X explicit\")\nFlag issues you cannot fix — missing citations, unclear experimental details, potential factual concerns — as a separate list at the end\nIf the input is LaTeX, output LaTeX. If the input is plain text, output plain text. Match the format.\nInteraction Patterns\n\nFull paper refinement: If the user provides an entire paper (or most of one), work section by section. Start with whichever section the user indicates, or begin with the abstract and introduction since those set the tone.\n\nSingle section: Apply the full refinement process to that section.\n\nQuick polish: If the user says \"just fix the grammar\" or \"light edit only\", respect that — fix spelling, grammar, and punctuation without restructuring or rewriting.\n\nIterative refinement: After providing a refined version, be ready for feedback like \"too formal\", \"I want to keep the original structure of paragraph 2\", or \"make the motivation stronger\". Apply changes surgically without re-editing the rest.\n\nRebuttal writing: When the user mentions a rebuttal or reviewer response, read references/rebuttal-guide.md for specific advice on crafting effective rebuttals.\n\nCommon Venue-Specific Notes\nVenue Group\tStyle Tendencies\nNeurIPS, ICML, ICLR\tConcise, equation-centric. Theoretical rigor valued. Anonymous review — remove self-identifying references.\nAAAI, IJCAI\tBroader AI scope. Motivation and real-world relevance important. Slightly more expository than ML-focused venues.\nACL, EMNLP, NAACL\tThorough related work expected. Linguistic precision in terminology. Error analysis and ablation studies valued.\nCVPR\tVisual results critical. Qualitative examples alongside quantitative. Clear figure descriptions.\nWWW, KDD, SIGIR, CIKM\tProblem-driven motivation. Scalability and practical impact often expected. Dataset descriptions need care.\n\nThese are tendencies, not rigid rules — good writing is good writing regardless of venue." }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/Zihan-Zhu/academic-writing-refiner", "publisherUrl": "https://clawhub.ai/Zihan-Zhu/academic-writing-refiner", "owner": "Zihan-Zhu", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/academic-writing-refiner", "downloadUrl": "https://openagent3.xyz/downloads/academic-writing-refiner", "agentUrl": "https://openagent3.xyz/skills/academic-writing-refiner/agent", "manifestUrl": "https://openagent3.xyz/skills/academic-writing-refiner/agent.json", "briefUrl": "https://openagent3.xyz/skills/academic-writing-refiner/agent.md" } }