sciwrite turns a Stanford writing course into a five-pass manuscript audit

Five sequential audit passes target delivery rather than argument

sciwrite is a review skill for scientific and engineering manuscripts, and its scope is deliberately narrow. The project documentation states that the skill does not alter scientific content, data, or technical claims, and that it improves how those claims are delivered. That framing matters, because the usual failure mode of writing assistants is that they quietly change what a paper claims while claiming to improve its prose.

The audit runs as five passes over the text. The first extracts clutter, flagging dead-weight phrases, unnecessary jargon and filler, and supplying concise replacements. The second examines voice and verb vitality, identifying passive constructions, nominalized verbs and weak verb choices, then suggesting active alternatives. The third evaluates sentence architecture, including length, flow, run-on sentences, misplaced modifiers and paragraphs without a clear logical progression. The fourth checks keyword consistency so that technical terms do not drift between synonyms and create ambiguity. The fifth audits numbers, units and in-text citations for internal consistency, catching cases where the text reports 3.2 and a table reports 3.4.

The target reader is a researcher who writes mostly without editorial support. The documentation argues that most graduate students receive little formal training in scientific writing and that self-editing for clarity is hard precisely because you already know what you meant to say. The skill is meant to be the outside pair of eyes that catches what familiarity hides.

Four review modes cover whole papers, one section, one pass, or a paragraph walkthrough

The skill supports four ways of engaging with a draft, and they exist for different moments in a writing process. A full-manuscript review runs all five passes. A single-section review narrows the scope to one part of the paper. A targeted review runs only the pass you name, and the documentation gives the plain example of asking to fix passive voice. An interactive mode walks through the manuscript paragraph by paragraph and shows before and after examples.

This set of modes is the practical part of the design. Running all five passes over a 40 page draft produces a long list, and finding the three sentences worth your afternoon is harder than fixing them yourself. A targeted pass on one dimension gives you a checklist you can work through. The interactive mode suits co-author sessions or a supervisor who wants to walk a student through one paragraph at a time.

What comes back is described as a structured report with specific findings, concrete revisions and severity tags. Severity tags are what let you triage, since a passive construction in a methods section and an inconsistent reported value do not deserve the same hour. The documentation does not say how severity is assigned, so a reader should expect the tags to reflect the auditor's judgment rather than a computed rule, and should not treat them as a scoring system.

The repository ships two Markdown files, and the format is the deliverable

The repository root holds four entries: HOW-TO-USE.md, LICENSE, README.md and SKILL.md. There is no code, no package manifest and no build step. The entire product is a Markdown document with YAML frontmatter, which the documentation explains is an industry-standard format for giving AI tools reusable, domain-specific instructions.

The format has two parts. A short header tells the assistant when to use the skill, and the body tells it how to perform the task. The documentation describes the skill creator step as having checked the structural relationships, specifically the YAML frontmatter, the Markdown body, and the link between the description field and trigger behavior. That trigger behavior is why the description field in the frontmatter carries more weight than it looks like it should: it is what an assistant reads to decide whether a given request should load the skill.

The documentation also puts the format in a historical frame. Skills were introduced by Anthropic in October 2025 and published as an open standard in December 2025, and are described as supported across Claude, ChatGPT, GitHub Copilot, Cursor and other tools. The practical promise is portability: write a skill once, load it in several assistants. The counterpoint is that portability depends on each tool honouring the description trigger, so a tool with weak skill support will silently never load the file.

Installing in Claude.ai means uploading a ZIP that keeps the skill folder at the root

The documented starting point is claude.ai, because it needs no terminal. The account-wide route begins on the repository's main page, where the green Code button leads to Download ZIP. In the left sidebar of claude.ai, Customize opens the toolbox panel, and the Skills section there has a plus button that leads to Create skill, where the ZIP is uploaded. The skill then appears in the Skills list and its toggle has to be turned on.

After that, a normal conversation is enough to trigger it. The documentation gives this prompt as the example request.

   > Review the writing quality of my manuscript. Here is the Introduction section:
   >
   > [paste your text]

Claude matches the request against the skill description, loads SKILL.md, and returns the structured report. The documentation adds that a manuscript can also be supplied as a PDF or as individual pasted sections, so you are not restricted to copy and paste for a full draft.

There is a second documented route, adding the skill to a specific project rather than the whole account. The published walkthrough for that route ends at its heading, so the file layout it expects is not stated.

A ZIP with a loose SKILL.md will not load, and the folder level is the fix

One packaging detail causes more failed installations than anything else in the setup, and the documentation calls it out explicitly. The ZIP must contain the skill folder at the root level. If the archive holds sciwrite/SKILL.md rather than a loose SKILL.md, the upload works. A ZIP containing only the bare file at the top does not satisfy the requirement.

The reason is mechanical: uploading a repository archive usually preserves the repository directory name as the top folder, so the skill ends up nested one level deeper than the loader expects. When the upload appears to succeed but the skill never triggers, check the archive contents before anything else.

The repository name also becomes part of the path inside the archive, so the skill is nested one level deeper than a bare file upload. That difference between a skill that loads and one that never triggers is the whole reason for the note.

The methodology is distilled from CC-BY lectures, and the repository licence is custom

The source of the review rules is stated plainly: the methodology comes from Dr. Kristin Sainani's Writing in the Sciences course at Stanford from 2012, distilled from 30 video lectures. The lecture recordings are posted as a YouTube playlist under a Creative Commons Attribution license, and the project used those videos as its input.

The repository itself is not under a standard open source license. The license field is recorded as a custom licence that GitHub cannot classify, with the actual terms in the LICENSE file. For an organisation deciding whether to adopt the skill internally, that distinction matters. A permissive MIT or Apache header tells you quickly what you may do, while an unclassified custom licence means you have to read the terms and confirm they cover internal use, modification and redistribution before you build anything on top of it. Nothing here is legal advice; the practical point is that the licence question needs an answer from the text of the file, not from the label on the repository.

The course material carries its own separate terms, a Creative Commons Attribution licence on the lecture videos. The skill encodes methods rather than reproducing lecture transcripts, which is the usual way these two layers stay distinct, but anyone republishing the methodology should check both licences rather than assume the more permissive one applies to everything.

The skill was assembled by a three-tool pipeline that is itself worth studying

How the skill was built is documented step by step, and the pipeline is unusual enough to matter for anyone producing a similar asset. The first step used an agentic browser, Comet from Perplexity, to extract the individual video URLs from the 30 lecture playlist with tracking parameters stripped, rather than clicking through a share menu 30 times by hand. The author describes this as a task that would have taken 15 to 20 minutes of manual work and took under a minute with the agent.

The second step fed those 30 URLs into Google NotebookLM, which ingested the video transcripts as sources and, through its Studio panel, produced a Writing Standards Manual, a narrative document distilling the principles from all the lectures. The limitation of that output is stated directly: it was formatted as a human-readable guideline rather than a machine-actionable skill file.

The third step pasted that manual into Claude along with instructions to produce a properly formatted SKILL.md and a How-To file, using the built-in skill creator capabilities. The result was the SKILL.md with its five sequential passes and four review modes, plus HOW-TO-USE.md.

The lesson for adopters is about workflow, not about the tool choices. The pipeline separates mechanical extraction, synthesis and format authoring into distinct steps, and it names the gap that had to be closed, human-readable guideline to machine-actionable file. A team reproducing this needs all three stages, and the middle stage is the one most likely to lose detail.

No releases, and the last push was on 2026-08-03

The repository is not archived and has no GitHub releases, so there is no versioned changelog to read and no upgrade path to follow. The last push was on 2026-08-03. For a project whose entire payload is two Markdown files, that is the whole upgrade story: you copy the current SKILL.md and HOW-TO-USE.md, and there is nothing to migrate.

That also means the artifact can change under you without a release marker. The skill content is the product, so a change in the five passes or in the trigger description reaches you the moment you re-download the ZIP, and your own copies can drift apart silently. Versioning the file inside your own repository, and noting which upstream commit you took it from, costs nothing and prevents the confusing case where two researchers produce reports from different rules and compare the results.

The repository carries a LICENSE file and a README.md alongside the two working files, and no tooling, tests or CI are present in the root listing. For a skill used by a writing group, that means review is manual: read the SKILL.md body, check the five passes and four modes are still present, and confirm the description field still triggers on the phrasing your group actually uses.

Editorial conclusion

sciwrite suits graduate students and engineering researchers who write papers without formal editing training and want a repeatable readability audit rather than a rewrite. It is the wrong tool for checking scientific validity, since it explicitly leaves data, claims and technical content untouched, and it is not a general style checker for non-technical documents. Before adopting it, read the LICENSE file yourself, because GitHub cannot classify the custom licence and the skill was distilled from course material published under CC-BY. Check that the SKILL.md you load contains the five passes and four review modes you expect, and confirm that your AI tool actually loads skills before you assume an audit ran.

Frequently asked questions

Official sources

1. Issues
2. labarba/sciwrite on GitHub
3. README