Synthèse automatique
Réécrit une prose académique assistée par IA (articles, thèses, réponses aux relecteurs, propositions de financement) pour en améliorer la clarté et la voix tout en préservant les conventions scientifiques et les preuves.
Points forts
- Sépare explicitement l'audit (signalement des tournures IA et du statut de preuve de chaque affirmation) de la réécriture, ce qui rend les modifications vérifiables
- Interdit de toucher aux chiffres, résultats et citations, et impose d'aligner chaque affirmation sur sa preuve au lieu d'en rajouter
- Distingue le registre de l'article scientifique de celui de la proposition de financement (NSF, NIH), où le langage d'ambition reste légitime
- Fournit un journal des changements et exige une couverture identique au texte d'origine (autant de paragraphes)
Limites
- Le SKILL.md fourni est tronqué (les couches 2 et suivantes ne sont que partiellement visibles), donc l'étendue réelle du catalogue de tournures et des règles de réécriture reste à vérifier
- Suppose que l'auteur fournisse un échantillon de son style, sinon l'alignement sur sa voix reste approximatif
- Ne traite ni la vérification factuelle des sources ni la conformité aux règles de déclaration d'usage de l'IA, qu'il exclut explicitement
À utiliser pour nettoyer un manuscrit ou une proposition de financement rédigés avec une IA avant soumission, en gardant un ton neutre et lié aux preuves.
À éviter pour des blogs, du marketing, des essais personnels ou tout texte où l'on veut injecter de l'opinion et de la personnalité.
Analyse de sécurité
SûrThe allowed tools are limited to Read, Write, Edit, Grep, Glob, and AskUserQuestion — no Bash, no network, no credential access. Instructions are purely editorial: audit prose, remove AI-typical phrasing, soften over-claims, preserve all numbers/citations, and report changes. Nothing destructive, exfiltrating, or obfuscated; the only mild concern is the 'humanizer' framing, which is counterbalanced by repeated, explicit statements that it is not for evading AI-use disclosure.
- •Name 'humanizer' could attract users seeking AI-detection evasion, but the skill explicitly disclaims this in both description and body
Exemples
Audit and rewrite the 'Related Work' section in paper.tex: flag every AI tell with its location, then rewrite without changing any citation or claim strength. Give me the change log at the end.Edit my NSF Project Summary in summary.md for clarity and voice. It's a proposal, so keep the vision language, but make sure every feasibility claim is supported. Don't touch any numbers.Rewrite my NIH Specific Aims in aims.md to sound like my writing sample (sample.md), removing inflated significance and -ing tails, while preserving every claim and citation.name: academic-humanizer version: 0.3.3 description: | Improve the clarity and voice of AI-assisted academic writing (papers, theses, rebuttals) and funding proposals (NSF Project Summary/Description, NIH Specific Aims): preserve scholarly conventions, match claims to evidence (and, for proposals, claims to feasibility), and match the author's own voice. It never changes a number, result, or citation, and it is not for evading AI-use disclosure. Use when editing AI-assisted academic prose or grant proposals. license: MIT compatibility: claude-code codex morphmind opencode allowed-tools: [Read, Write, Edit, Grep, Glob, AskUserQuestion]
Academic Humanizer
Improve the clarity and voice of AI-assisted academic writing while keeping the precise, evidence-bound voice that scholarship requires and matching the author's own style. It preserves every number, result, and citation, and it is not a tool for evading AI-use disclosure.
When to use
Editing or reviewing academic prose: paper sections, abstracts, rebuttals, related work, and funding proposals (NSF Project Summary/Description, NIH Specific Aims, fellowship and foundation proposals; see Layer 6). Not for blogs, marketing, or personal essays, and never inject opinion, humor, or first-person "personality" into a manuscript. For technical writing, neutral and precise is the human voice. One caveat for proposals: their register is different from a paper's, since they are sold on vision and feasibility, so the ambition language a paper would trim is appropriate there; apply Layer 6, not the paper layers' stricter trimming, to vision statements.
Core principle
Academic writing already has a correct human voice: neutral, precise, third-person plural ("we"), every claim tied to its evidence. The job is to (1) strip the AI tells without casualizing, and (2) enforce the discipline a general humanizer misses: every claim earns its number, figure, or citation, and no verb is stronger than its evidence.
Process
- Read the manuscript and any author writing sample; note the document type (paper vs. funding proposal) and the target venue or funding agency. For proposals, also apply Layer 6 and preserve appropriate vision.
- Audit (do not edit yet): list each detected pattern with its location and proposed fix, and each empirical claim's evidence status.
- Rewrite: same structure and content, all claims and citations preserved, tells removed, over-claims matched to evidence, legitimate hedging kept.
- Report: cleaned text plus a short change log (patterns removed, claims softened or given evidence pointers, voice notes). Cover everything the original covered: if it had five paragraphs, so does the rewrite.
Layer 1: General AI-tell catalog
Scan for and fix the general patterns, subject to the academic exceptions in Layer 3: inflated significance ("marking a pivotal moment"); superficial "-ing" tails that fake depth ("..., highlighting..."); promotional/figurative language ("rich", "vibrant", "groundbreaking"); vague attributions ("experts argue" with no cite); AI vocabulary (delve, underscore, intricate, tapestry, testament, landscape (abstract), pivotal, showcase, foster, leverage (filler), realm, seamless); copula avoidance ("serves as" -> "is"); negative parallelisms ("not just X, but Y"); rule-of-three padding; elegant variation (cycling synonyms for one referent); filler ("it is worth noting that", "in order to"); overlong, clause-stacked sentences (split them; see 2.11); and em-dashes (remove entirely; recast with commas, colons, parentheses, or separate sentences).
Before: Additionally, an enduring testament to the method's value is its ability to delve into intricate dependencies, showcasing a seamless integration that underscores its pivotal role. After: The method also captures higher-order dependencies, which the baselines miss (Table 2).
Layer 2: Academic AI tells (remove or fix)
2.1 Over-claiming verbs
Empirical work shows and provides evidence; it does not prove or demonstrate universal truths. Watch: demonstrate, prove, establish, confirm, guarantee; "significantly" with no test/number. Before: We prove that our method significantly outperforms all prior approaches. After: Our method improves held-out accuracy by 4--7 points over the strongest prior approach (Table 3); the gain is significant at p < 0.01 by a paired test.
2.2 Significance hype
Watch: paves the way for, a crucial/pivotal step toward, has the potential to revolutionize, opens new avenues, sheds light on, of paramount importance, bridges the gap. Before: This work paves the way for a new paradigm and sheds light on a problem of paramount importance. After: This work addresses one failure mode of prior methods: error accumulation under long-horizon rollout (Section 4).
2.3 Empty intensifiers
Watch: extensive/comprehensive/thorough experiments, a wide range of, numerous, various. Before: We conduct extensive experiments on a wide range of datasets. After: We evaluate on three datasets (ImageNet, CIFAR-100, and iNaturalist).
2.4 Novelty padding
Watch: "novel" used more than once per section; "to the best of our knowledge"; "for the first time". Before: We propose a novel framework and, to the best of our knowledge, are the first to study this. After: We study online calibration under delayed labels, which prior calibration work (offline) does not address.
2.5 Formulaic openers
Watch: "In recent years, X has attracted increasing attention"; "With the rapid development of..."; "Despite recent advances,...". Before: In recent years, tabular deep learning has attracted increasing attention. After: Tabular deep learning has a structural limitation: most models discard feature-type metadata and must relearn it from data.
2.6 Connective overuse
Do not start consecutive sentences with Moreover/Furthermore/Additionally/In particular; let logic carry. Before: Moreover, the method is fast. Furthermore, it is simple. Additionally, it scales. After: The method is fast and simple, and it scales to one million rows (Section 5).
2.7 Contribution-list cliches
Each contribution names a specific result, not a restatement of the abstract. Before: Our contributions are: (1) a novel method; (2) extensive experiments; (3) strong results. After: We (1) introduce a metadata-aware encoder that reaches 0.91 AUROC vs 0.86 for the strongest baseline; (2) show it stays within 2 points under 20% label noise where the baseline drops 9; (3) release the benchmark.
2.8 Citation dumping
Cite the one or two works that matter and say why, not a bracketed list. Before: Many methods exist [3, 7, 9, 12, 15]. After: The closest prior method is TabNet [7], which encodes all features jointly; we instead condition on feature-type metadata.
2.9 Hedging-by-vagueness
Watch: somewhat, relatively, fairly, to some extent, quite. Quantify or cut. Before: Performance is somewhat better and relatively robust. After: Accuracy is 3 points higher and varies by less than 1 point across five seeds.
2.10 Boilerplate emphasis
Watch: "It is worth noting that", "It should be emphasized that", "Notably,", "Importantly,". If it matters, the sentence shows it. Before: It is worth noting that, importantly, the gain holds across scenarios. After: The gain holds across all three scenarios (Table 4).
2.11 Overlong, clause-stacked sentences
AI favors long sentences that chain three or four clauses with commas and "which", "that", "while", "with". Split them: one idea per sentence, and cut subordinate clauses that carry no weight. Watch: sentences past ~30 words, or with 3+ subordinate clauses. Before: Existing methods, though promising, are largely empirical, with unclear principles underpinning their behavior, which limits their reliability and further progress. After: Existing methods stay empirical. Their principles are unclear, which limits reliability and progress.
Layer 3: Preserve these (do NOT over-correct)
A general humanizer flattens legitimate scholarly constructs. Keep them.
- Evidence-tied hedging is correct and required. Keep "suggests", "is consistent with", "we hypothesize that", "may indicate", "appears to" when the claim is genuinely uncertain. Wrong fix: turning "the results suggest X" into "the results prove X": this manufactures over-claiming. Keep the calibrated verb.
- Passive voice is fine when the actor is irrelevant: "Samples were normalized to total protein."
- First-person plural "we" is standard; do not rewrite to avoid it.
- Semicolons and an occasional triple are fine in moderation. Em-dashes are the exception: remove them entirely (Layer 1), recasting with commas, colons, parentheses, or separate sentences.
- Formal definitions, named methods/metrics, technical terms, equations, and symbols stay verbatim.
- Never invent, drop, or alter a number, equation, or citation. Same content; preserve every cite key.
Layer 4: Claim-evidence discipline
For every empirical claim, check (a) is it backed by a number, figure, table, or citation in the text, and (b) does the verb match the strength of that evidence?
- Unbacked claim -> add the evidence pointer or soften. Before: Our method is more robust. After: Our method's accuracy drops by 2 points under distribution shift, versus 11 points for the baseline (Figure 3).
- Verb stronger than evidence -> downgrade. Before: This demonstrates that our method is universally superior. After: On these three datasets, our method matches or exceeds the strongest baseline (Table 2).
- Vague magnitude -> a number or RANGE, attributed. Before: a large improvement. After: a 2--6% improvement in balanced accuracy over the strongest baseline. Prefer ranges (e.g., "2--6%") over single averaged values unless the averaging method is stated, and attribute each number to its method, metric, and baseline. When comparing, lead with the comparison against the strongest competitor, not the trivial baseline.
Layer 5: Voice and venue matching
If the author supplies prior papers, read a sample first and note sentence rhythm, connective habits, level and placement of hedging, how they open sections, notation, and recurring phrasings, then match them. Match the venue's register too (e.g., ICLR/NeurIPS: terse, direct, results-forward; Nature/PNAS: more expository). Absent a sample, default to clean, precise, venue-appropriate prose, not the casual, opinionated voice of a general-purpose humanizer.
Layer 6: Funding-proposal mode (NSF, NIH)
A proposal is not a paper. It is sold on vision plus feasibility, not on finished results, and reviewers score it. The register shift matters: ambition language that the paper layers would trim ("long-term goal", "pioneer", "transformative", "establish a foundation") is appropriate and expected here, provided a credible plan and evidence back it. So in proposal mode, do not flatten the vision; enforce a different discipline instead: claim <-> feasibility.
6.1 Know the structure; the score lives in the first pages
Reviewers form a score from the opening, then skim the rest to confirm it. Put most editing effort there.
- NSF. A one-page Project Summary with the three review-criteria heads spelled out: Overview, Intellectual Merit, Broader Impacts, each self-contained. The Project Description then opens with long-term vision -> this proposal's goal -> the gap -> the specific thrusts/aims -> the payoff, ideally within the first 1--2 pages, with one overview figure. Broader Impacts must be substantive and integrated, never an afterthought.
- NIH (R01). The Specific Aims page is the whole proposal in one page, and is the most-read, most-decisive page. Standard arc: (1) opening: the problem, what is known, the gap / critical need; (2) the long-term goal and the central hypothesis with its rationale; (3) "The objective of this application is..." plus how the hypothesis was formed; (4) 2--3 Aims, each a one-line goal + a phrase on approach + the expected outcome; (5) a payoff paragraph: what changes if it succeeds. Then Significance, Innovation, Approach as separately scored sections.
6.2 First-3-pages primacy (edit these hardest)
By the end of page 1 (NIH Aims) or pages ~2--3 (NSF), the reader must already hold: the hook (why it matters, concretely), the gap (what is missing and the cost of the gap), the central idea (your approach in one sentence), the aims/thrusts (crisp and parallel), and the payoff. If any is missing or buried, fix that before touching later sections. A reviewer unconvinced by page 3 does not recover on page 10.
6.3 Proposal-specific weak moves to fix
- Vague importance. Watch: "this is an important/timely problem", "X has many applications". Before: Understanding this problem is critically important. After: Without bounds on how measurement noise propagates to diagnosis, clinical models are tuned by trial and error, the inefficiency this proposal removes.
- Method-as-aim (an aim naming a technique instead of a question or outcome). Before: Aim 2: Apply transfer learning to the dataset. After: Aim 2: Determine whether fusing wearable and lab signals improves early detection, and for which patient subgroups it helps or hurts.
- Dominoed aims (Aim 2/3 collapse if Aim 1 fails; reviewers flag this as fragile). Fix: phrase aims as parallel and independently valuable; where one depends on another, state the fallback.
- Ambition without feasibility. Every bold claim needs a footing: preliminary data, a prior result/publication, a classical theorem you build on, or a collaborator/letter. Fix: attach the evidence beside the claim ("our preliminary result in Fig. X shows...", "building on a classical minimax lower bound...").
- Boilerplate Broader Impacts / training plan. Watch: "we will mentor students and disseminate via talks and papers." Fix: make it concrete, enumerated, and tied to the research: specific programs, named courses or tools, measurable outreach.
- Hedged central hypothesis. The Aims-page hypothesis is a falsifiable commitment, not "we will explore whether possibly...". Calibrated hedging belongs in the Approach's interpretation, not the central claim.
6.4 Preserve and deploy (funded-proposal craft)
These read as strength; keep or add them rather than editing them out.
- Vision/ambition framing: a bold long-term goal up front, with this proposal as one principled step toward it.
- Run-in lead-ins for scannability: bold/italic Goal:, Motivation:, Innovation:, Thrust/Aim N (one-line mission):. Reviewers skim; visible structure earns time.
- A concrete running example or protagonist to make an abstract method vivid and consistent across aims.
- Sharp challenge/aim statements posed as questions: a crisp open question reads as a well-posed problem (a boxed or set-off question per aim works well).
- Anchoring novel work in deep, named classical results to signal rigor and lineage: a known inequality, capacity notion, or test that the new method generalizes.
- Foreground the team's standing as feasibility evidence: prior funded work, preliminary results, publications, collaborators, and demonstration partners belong early, as proof the plan is executable. A real track record is evidence, not boasting; place it where it de-risks the aims. (Use only the PI's own real, supplied record; never invent funding, results, partners, or letters.)
6.5 Claim <-> feasibility (the proposal analog of Layer 4)
For every aim and promised outcome, check: is the ambition matched by a credible means, such as preliminary data, a prior method, a classical foundation, a collaborator, or staged de-risking? If yes, keep the ambitious verb. If no, attach the missing evidence or scale the claim to what the plan supports. Never invent preliminary results, prior funding, partners, or letters; if the support does not exist, flag the gap for the author rather than papering over it.
Output
Return the cleaned text plus a short change report: patterns removed (by type), claims softened or given evidence pointers, and any voice/venue notes. Confirm that no number, equation, or citation was altered.
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/academic-humanizer-ms47voco/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/academic-humanizer-ms47voco' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/academic-humanizer-ms47voco/download' --output '.skill-downloads/academic-humanizer-ms47voco/SKILL.md.part' && mv '.skill-downloads/academic-humanizer-ms47voco/SKILL.md.part' '.skill-downloads/academic-humanizer-ms47voco/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Environnement déclaré par l’auteur : claude-code codex morphmind opencode
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/academic-humanizer-ms47voco/SKILL.md' && test -s '.skill-downloads/academic-humanizer-ms47voco/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/academic-humanizer' && cp -R '.skill-downloads/academic-humanizer-ms47voco' '.claude/skills/academic-humanizer'Codex
test -f '.skill-downloads/academic-humanizer-ms47voco/SKILL.md' && test -s '.skill-downloads/academic-humanizer-ms47voco/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/academic-humanizer' && cp -R '.skill-downloads/academic-humanizer-ms47voco' '.agents/skills/academic-humanizer'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/academic-humanizer-ms47voco'openskills read 'academic-humanizer-ms47voco'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/academic-humanizer-ms47voco/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Fragments d'écriture
Contenu
Extrayez des fragments d'écriture bruts via un entretien intensif, sans imposer de structure. Capturez idées, citations et mots porteurs pour une utilisation ultérieure.
Rédaction UI et audit
Contenu
Rédigez ou auditez les textes d'interface (boutons, erreurs, états vides, infobulles) dans le monorepo, en suivant la source de vérité du design system.
Extraction MIDI/score
Contenu
Extrait le MIDI ou la partition d'une production musicale existante via l'outil MCP CogMusic et confirme la disponibilité du fichier.