HunkBB/academic-writing-humanizer

Academic Writing Humanizer

Produce specific, readable research writing that the author can explain and support. Use modules A–I by default; scale their depth to the task. Preserve meaning, facts, technical precision, and actual authorship contributions. Assess fidelity, readability, and appropriate register separately; improvement in one does not establish improvement in the others.

Set the register before drafting or editing

• For formal proposals, policy papers and other academic documents, default to formal, analytical, precise and restrained prose. Develop the reasoning, use established disciplinary terminology, and retain useful sentence complexity. For outreach emails, use professional directness and appropriate personal address. Distinguish the email from any attached proposal; a professor as recipient does not make every document conversational.
• Apply the explicit preferences in intake-and-voice.md. This edition defaults to avoid_would_will: true in newly authored formal academic prose, including negative and contracted forms. This is a project style preference, not a universal academic prohibition. Rewrite with accurate purpose, proposed-design or conditional constructions; preserve uncertainty and proposed/completed status. Protect exact quotations, titles and reference text. Do not extend this preference to every modal verb or mechanically replace modals with present tense. A user's explicit task-specific preference can override this default.
• Treat factual and semantic fidelity as constraints. Resolve style choices using explicit task/institutional requirements, confirmed user preferences, genre, and then general editorial suggestions. Wikipedia observations do not override these. If requirements genuinely conflict, surface the specific conflict instead of silently dropping meaning.
• In editing, preserve passages that already meet the requested register and purpose. In drafting, establish the register before composing; do not first produce a conversational draft and then decorate it with academic vocabulary.

Establish the inputs

1. Identify audience, genre, target programme/professor, language, length, deadline, output format, and source draft. Record register, reader expertise and confirmed language preferences. Distinguish outreach email, research-interest note, formal application and protocol.
2. Read the supplied CV, sources, and genuine author samples. Use intake-and-voice.md and intake-template.md to record facts, provenance, conflicts and voice status. Distinguish CV-reported from independently verified facts.
3. Check exact programme/material requirements when available. Consult process-and-review.md. Do not infer a national rule from a department's policy. Unknown policy means unknown.
4. Continue useful work despite nonessential gaps. Ask one bundled set of material questions only when answers materially affect the proposal. Without authentic prose samples, follow the recorded genre/register preferences and mark voice calibration incomplete. Confirmed preferences do not authenticate personal voice. Propose alternatives or mark missing author decisions rather than inventing them.

Apply all nine modules

Module	Action	Completion evidence
A — Voice	Match supported tendencies in actual author samples; adapt to genre.	Sample provenance and observed preferences, or explicit uncalibrated status.
B — Background	Reconcile experiences, skills, outcomes and access claims.	Fact ledger with unresolved conflicts excluded or flagged.
C — Question	Specify question, mechanism, population and modest contribution.	Answerable question and literature-grounded contribution.
D — Methods	Align data, units, measures, design, assumptions and limitations.	Feasibility check and descriptive/causal distinction.
E — Fit	Read the scholar's relevant primary work and connect an actual design choice.	Specific connection without invented relationship or availability.
F — Language	Revise weak passages using the complete contextual style check and recorded register.	Clear argument, appropriate academic diction and stable register, with protected meaning intact; retain effective passages.
G — Sources	Verify source identity and support for each central claim.	Claim-to-source ledger with access level and limits.
H — Decisions	Preserve real inputs, decisions, revisions and AI roles.	Actual change record, author decisions and appropriate disclosure.
I — Review	Review independently where possible and ask research questions.	Evidence-based critique and questions the author must answer.

Draft and revise in three passes

Pass 1: research content

Read research-checks.md for B, C, D, E and G.

• For new writing, formulate a focused working question with explicit assumptions, then draft from the ledgers. Label AI-proposed topics as proposed, not as established personal motivations.
• For an existing draft, preserve a copy and distinguish language edits from substantive changes. If a method/scope must change, explain why and mark author review required; never silently replace the author's project.
• Check sources before claiming a literature gap. Never invent citations, data access, sample sizes, effects, collaborations or experiences. A real DOI does not establish support for a claim.
• Prefer a feasible core study over a list of techniques. Provide a usable fallback for unavailable data. Mark proposed research choices pending author confirmation.
• Use supplied evidence when browsing is unavailable and state the verification limit. Never describe retrieval as performed when it was not.

Pass 2: expression

Read language-editing.md, rewrite-examples.md, and wikipedia-coverage.md. The coverage reference includes every substantive heading in the dated Wikipedia source and its Style/Markup pages, with scope-specific actions. It is an editorial resource, not a classifier.

1. Freeze a meaning ledger: facts, numbers, actors, work/access status, technical definitions, inferential strength, citations, and research decisions. Preserve these or explicitly record a substantive change.
2. For each applicable coverage row record revise, keep with reason, or not present; use not applicable for context-specific rows. Treat parent rows as routing checks. Consolidate repeated findings. Read historical/ineffective-indicator rows as safeguards, not deletion instructions. For a full audit, retain the disposition ledger as a sidecar; present only meaningful changes to the user.
3. Use a paragraph rewrite for passages whose argument, formulaic structure or register needs repair. Organize necessary propositions around the paragraph's analytical purpose; connect evidence, interpretation and qualification. Do not force question openings or personal-action narration. Use light edits or retain wording when a passage already works, including in a humanizing request.
4. Run distinct passes for argument flow, inflated/vague claims, syntax/wording, register, assistant residue/format, and citation hygiene. Separate submission prose from editorial notes; keep research limitations that affect interpretation in the text. Define measures precisely and explain unfamiliar concepts at the target reader's level. Do not turn every paragraph into a protocol checklist or lay explanation.
5. Read the whole draft for repeated openings, uniform paragraph scaffolds, needless summaries, stilted attribution and density. Preserve technical repetition, valid contrasts, uncertainty, functional complex sentences and author-supported idiosyncrasies. Check recorded lexical preferences contextually, including would/will when avoidance is active; review each exception. Do not add errors, invented experiences, forced short sentences, random vocabulary or punctuation rules.
6. Compare against the meaning ledger. Review fidelity, reader experience and register separately with style-review.md. If any fails, revise the affected passages and review them again. Do not accept formal wording that impairs clarity or changes research status. Stop when remaining edits are cosmetic; report unresolved issues.

Pass 3: verification and review

Read process-and-review.md for H and I; use review-template.md.

1. Check changed numbers, facts, causal statements and attributions against the ledgers.
2. Explain material changes as before → after → reason, and identify additions requiring author confirmation.
3. If available, give an independent agent the draft, requirements, facts and sources without the intended verdict or editing rationale. Assess fidelity, readability and register separately using style-review.md. Preserve raw reviews and disagreements. Otherwise label it self-review. For A/B comparisons, randomize neutral labels and use comparable scope/length; disclose any content moved to an annex.
4. Produce 5–8 questions on contribution, data, identification, measurement, feasibility and motivation. Do not claim generated answers prove the user's understanding; understanding is untested until the author responds.
5. Apply justified corrections and state remaining issues. One case does not validate country-wide, cross-platform or detector performance.

Use local helpers when useful

Run with Python 3, resolving scripts relative to this directory:

python3 scripts/review_text.py audit draft.md --output audit.json
python3 scripts/review_text.py diff before.md after.md --output changes.html
python3 scripts/style_audit.py draft.md --output style-audit.json

No third-party dependencies, network, API key or detector account is required. The helpers report mechanical candidates and a visual diff. style_audit.py is a limited local preflight, not the complete semantic Wikipedia review. Its triggers are editorial prompts, not validated classification thresholds; do not minimize their count as an objective. Manually inspect findings and preserve legitimate uses. The scripts do not verify references, assess research validity, infer authenticity or detect AI. Never convert counts into an AI percentage. Preserve input files. Do not send unpublished writing to third parties without authorization.

Report detector status accurately

Read evidence-and-detectors.md for dated evidence.

• Separate writing-quality review from detector measurement.
• Without an actual run, report: “Turnitin: not tested; corresponding percentage cannot be estimated.” Never substitute another vendor's score, a subjective percentage or language-model judgment.
• With a genuine report, record product, date, submitted version/hash, literal result, meaning and limits. Do not label it the author's actual AI contribution or guarantee acceptance.
• Never promise undetectability or fabricate draft histories, reports, backdated notes or minimized AI-use statements.

Deliver

Return revised text, concise changes and material author decisions. For full proposals also provide source ledger, A–I review, style dispositions, detector status and discussion questions. Show representative before/after passages and explain the reader-facing improvement, plus meaningful cases deliberately retained. Separate review notes from submission prose. Mark unresolved substantive decisions as a working draft, not ready to submit. Keep personal facts/samples in the user's project, outside this reusable skill.

Scale the visible editing record to the task. For a short passage, use a few concise bullets and material unresolved issues; do not attach the full-proposal review apparatus unless requested. Keep detailed audit records separate when useful.