Smithery is now a part of Arcade.dev! Read more in our announcement here
Write quality content for HTML documents. Use when writing text content, prose, descriptions, or any human-readable content in HTML files. Ensures spelling and style quality.
This skill ensures all written content meets quality standards for spelling, grammar, and style.
This project uses cspell for spell checking with a custom dictionary.
These terms are in project-words.txt and won't trigger spell errors:
Technical:
Custom Elements:
HTML Terms:
Check project-words.txt for the full list.
When using a new product name or technical term:
/add-word TermNameproject-words.txt (one word per line)<!-- Passive (avoid) -->
The form was submitted by the user.
Errors were found in the document.
<!-- Active (prefer) -->
The user submitted the form.
The validator found errors in the document.
Remove vague qualifiers:
| Avoid | Use Instead |
|---|---|
| various | (be specific) |
| many | (give number) |
| very | (remove or be specific) |
| somewhat | (remove) |
| fairly | (remove) |
| quite | (remove) |
Use descriptive link text:
<!-- Bad -->
<a href="/docs">Click here</a>
<a href="/pricing">Learn more</a>
<a href="/features">Read more</a>
<!-- Good -->
<a href="/docs">Read the documentation</a>
<a href="/pricing">View pricing plans</a>
<a href="/features">Explore all features</a>
Follow logical hierarchy:
<h1>Page Title</h1> <!-- One per page -->
<h2>Major Section</h2>
<h3>Subsection</h3>
<h4>Detail</h4>
<h2>Another Section</h2>
This project enforces reading level thresholds using Flesch-Kincaid scoring.
| Content Type | Max Grade Level | Audience |
|---|---|---|
| General | 8 | General public |
| Technical | 12 | Technical audience |
For technical documentation, add one of these:
<!-- In <head> -->
<meta name="content-style" content="technical"/>
<!-- Or on html/body -->
<html lang="en" data-content-style="technical">
<body data-content-style="technical">
Available content styles:
technical - Technical documentation, API references (threshold: grade 12)Use shorter sentences:
<!-- Hard to read (grade 12+) -->
The implementation of the aforementioned functionality requires
consideration of various architectural constraints that may
impact the overall system performance.
<!-- Easier to read (grade 8) -->
This feature needs careful planning. We must consider how it
affects system speed.
Use simpler words:
| Complex Word | Simpler Alternative |
|---|---|
| utilize | use |
| implement | build, create |
| functionality | feature |
| subsequently | then, later |
| facilitate | help, enable |
| approximately | about |
| demonstrate | show |
| modification | change |
Break up long paragraphs: Aim for 3-4 sentences per paragraph.
Use lists: Convert complex sentences into bullet points when possible.
# Check readability
npm run lint:readability
# Check all content quality
npm run lint:content
Before finalizing content:
npm run lint:spelling)npm run lint:readability)# Check spelling
npm run lint:spelling
# Check grammar/style (advisory)
npm run lint:grammar
# Check reading level
npm run lint:readability
# Run all content checks
npm run lint:content
Wrap code in appropriate elements:
<code>const x = 1</code> <!-- Inline code -->
<pre><code> <!-- Code block -->
function example() {
return true;
}
</code></pre>
<kbd>Ctrl+S</kbd> <!-- Keyboard input -->
<samp>Output text</samp> <!-- Sample output -->
Define abbreviations on first use:
<abbr title="HyperText Markup Language">HTML</abbr>
<abbr title="Web Content Accessibility Guidelines">WCAG</abbr>
Use semantic time element:
<time datetime="2024-01-15">January 15, 2024</time>
<time datetime="14:30">2:30 PM</time>
