deslop
Edit Ascribe's prose so it says what a thing does: the docs in docs/content/, the site's pages in site/home/content/, the README, and the packages' descriptions. Finds the patterns models write in pla
SKILL.md.claude/skills/deslop/SKILL.md
GitHubDeslop Ascribe's prose
The rule is the house style's: say what a thing does. Most of what reads as AI writing is a model saying something vaguer than the fact it had: "serves as" where "is" was true, "ensuring consistency" where a mechanism should be named, "robust" where a limit should be stated. In docs, those aren't matters of taste. They change what a reader believes about the software. Fix them because they're wrong or empty, not because they sound like a model.
The research behind this skill is AI writing tells in technical docs. Three of its findings shape everything below:
- Measurements support few tells. Evaluative words ("delve", "showcase", "crucial") and tacked-on "-ing" clauses are measured at several times the human rate. Most other tells, including "not X, but Y", have never been measured, and none has been measured in docs.
- Word lists go stale. Each model has its own favorite words, so this skill names kinds of word, not a list to grep for and forget.
- Over-correcting is its own tell, and it breaks docs. A pass that deletes every hedge, adverb, and contrast strips "usually", "unless", and "pass the path, not its contents", which are conditions the reader needs.
What not to touch
- Code blocks, code spans, commands, and output from
@snippet. - Frontmatter, directive lines,
{phrase}keys, link targets, and ids. - Anything under
docs/content/_generated/: fix its source instead. - The headline and the opening sentence in
design/words.toml, which every surface is tested against. Changing them is a decision forproject-docs/brand/story.md. - A fact you can't check. If a sentence is vague because the fact is missing, ask, or leave a note in your report; don't invent the specific.
The pass
Work through a page in this order. Facts come first, because a wrong flag costs a reader more than any phrase.
- Check what the toolchain can. Run
cargo run -q -p ascribe-cli -- check <file> --format concise. For every command, flag, key, and directive the page names, confirm it exists:--help,docs/content/_generated/, orcargo run -q -p ascribe-cli -- model docs. An example's output should come from a@snippetof a tested file, not be typed in. - Fix what hides meaning. These are always worth an edit. See Hides meaning.
- Fix what slows the reader. See Slows the reader.
- Fix formatting that breaks scanning. See Breaks scanning.
- On the site and the README, fix the rhetoric. See Site and README copy.
- Reread what you changed. Every condition and every fact the sentence had is still there. You haven't introduced a new pattern: a rewrite that turns three hedges into three short declaratives can be just as uniform. Run the check again, and
cargo run -q -p ascribe-cli -- check --config docs(or--config site/home) before you finish.
A single hit is rarely worth an edit on its own. Look for density: three evaluative words in a paragraph, a ", ensuring" on every other sentence, bold labels on every list.
Hides meaning
Fix each one by stating the fact it stands in for. If you don't know the fact, that's the finding.
| Pattern | Before | After |
|---|---|---|
| "Serves as", "acts as", "functions as" where "is" is true | The [consumer] table serves as the bridge to Astro. |
The [consumer] table is what @ascribed/astro reads: the site's address, base path, and profile. |
| A trailing "-ing" clause claiming a benefit | Ascribe reads the file each build, ensuring examples stay current. | Ascribe reads the file each build, so the example is whatever the file holds now. |
| "Associated with", "related to" where a relation exists | the addresses associated with a build | the addresses a build published |
| An evaluative word where a spec belongs: robust, seamless, powerful, comprehensive, flexible, efficient | a robust check for broken links | a check that reports a link to a missing file or heading |
| An unspecific caveat: "it's important to note", "keep in mind", "note that" | It's important to note that results may vary. | With two builds and neither named site, [editor] build is required. |
| Stacked or templated hedges over deterministic behavior | This may typically cause the check to fail. | The check fails. |
| One thing called by several names | workspace … project … environment | project, every time |
| A list padded to three | fast, reliable, and scalable | Name what's true, however many that is. |
Keep a word when it's the precise one: "ensure the port is free" is an instruction, "critical section" is a term. Keep a hedge that carries real uncertainty, once: "usually", "unless you pass --force". The fault is the templated or stacked one.
Slows the reader
| Pattern | Fix |
|---|---|
| Signposting and meta-commentary: "In this section, we'll…", "Here's what you need to know", "Let's" | Delete it and start with the content. The house style has no "let's". |
| A page that opens with a pointer: "Part of the [reference]…", "The commands that…" | Open with a sentence that says what the page covers; put the pointer second. |
| A first sentence that restates its heading: "## Caching" then "Caching is a feature that…" | Start with what the heading's thing does. |
| A summary closer: "In summary", "Overall", a recap paragraph | Delete it, or replace it with the next step. |
| Vague attribution: "teams report", "studies show", "developers love" | Cite the source, as a link, or state the claim without attribution, or cut it. project-docs/reports/ holds the research the site cites. |
| A paragraph that adds no fact | Ask what the reader learned. If nothing, cut it. |
| A sentence over about 40 words, chained with commas and "which"; one that lists more than three things, or has more than one "which"; a paragraph over 120 words | Make it a list, or two sentences. Outside contracts/, the docs have no sentence over 45 words and no paragraph over 120. |
Page type decides some of these. The content model declares each page's type:
- A tutorial may open with its goal ("This tutorial builds…") and may close with one sentence on what the reader built. Nothing else may.
- A how-to opens with the task and puts its procedure in
@steps. - A reference page is plain description: no goal sentence, no closer, no persuasion.
Breaks scanning
| Pattern | Fix |
|---|---|
| Bold scattered through prose | Bold only a UI label or a term at its definition. |
| A bold label on every list item, restating its own sentence | Drop the labels and let the sentences stand. A real term or option list keeps its **Term** labels, as Microsoft's guide prescribes. |
| A heading per paragraph, or headings that hold only headings | Merge the sections. |
| Several notes in a row, or a note that's ordinary prose | Keep the one that warns of something; fold the rest into the text. |
| Emoji in headings or lists | Remove them. |
| Title-case headings | Sentence case. |
| Em dashes | The house style uses none. Use a colon, a comma, parentheses, or a new sentence. |
Three items in a list is fine. A three-word adjective string in a sentence is the pattern.
Site and README copy
The landing page, Why Ascribe, Credits, the README, and the packages' descriptions persuade, so the essay rhetoric shows up there. A technical reader discounts all of it.
| Pattern | Before | After |
|---|---|---|
| "Not X, but Y" against a claim nobody made | Ascribe isn't just a linter, it's a toolchain. | Ascribe checks pages, builds them, and previews them. |
| An aphoristic closer | What it lowers is the cost of leaving, not the risk of depending. | Ascribe is still a young dependency. |
| A staged reveal or a self-answered question | The result? Faster reviews. | Reviewers read the rendered page. |
| A false range | from solo writers to enterprise teams | Say who it's for. |
| Puffery and stakes: unlock, elevate, game-changing, best-in-class, effortless | Unlock a seamless docs experience. | Say the feature. |
Strategy language from story.md leaking into copy |
What leads changes with the reader. | Where to start depends on what you do. |
Two rules from project-docs/brand/story.md also apply: the site names no other tools, and every claim has something built behind it that a command's output can show.
A contrast that informs stays: "a link names the page's file, not its address" tells the reader what to write.
A quick scan
These find candidates, not faults. Read each hit in its sentence.
grep -rnEi --include='*.md' "serves as|acts as a|, ensuring|associated with|it's important to note|keep in mind|worth noting|in summary|in conclusion|let's|delve|seamless|robust|powerful|leverage|utilize|crucial|pivotal|comprehensive|unlock|—" docs/content site/home/content README.md | grep -v _generated
Vale can hold some of these permanently, and an Ascribe check could hold the page-structure ones; issue #1287 tracks that. Until a rule is tuned on these pages, treat a hit as a suggestion.
When asked to review rather than edit
Report findings by group, in the order of the pass, each with path:line, the sentence, and the rewrite. Say which ones you couldn't fix because a fact is missing. Don't report a single weak hit, such as one hedge or one three-item list, as a finding.