cspell_skill

This skill helps you manage cspell unknown word warnings by guiding config bootstrap, text adjustments, and scoped directives.
  • Shell

0

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill vdustr/vp-claude-code-marketplace --skill cspell

  • SKILL.md4.6 KB

Overview

This skill helps diagnose and fix cspell unknown-word warnings and CI/lint failures caused by unrecognized words. It classifies flagged tokens, chooses the narrowest safe fix (text adjustment, inline directive, or project dictionary), and can guide bootstrapping a cspell config when a project is missing one.

How this skill works

First, it checks for an existing cspell configuration by searching the repository upward from the file location (package.json cspell field, .cspell.json, cspell.config.*, .vscode/cspell.json, etc.). If no config is found it offers a guided bootstrap flow instead of making changes. For each flagged word it applies a priority: adjust text when safe, add to project dictionary for recurring terms, or apply an inline directive for one-off occurrences.

When to use it

  • IDE diagnostic or CI output shows cspell unknown-word warnings
  • You want to add words to cspell dictionary or suppress specific cspell warnings
  • Setting up cspell in a repository that lacks a project config
  • Explaining why cspell flagged a word or how cspell decides matches
  • A pre-commit or lint pipeline fails due to unrecognized words

Best practices

  • Check for a project cspell config before making any edits or adding words
  • Prefer adjusting word form (hyphenate, camelCase) over adding to dictionaries
  • Use the narrowest scope possible: inline directive for one-offs, project dictionary for recurring terms
  • Place cspell:words at the top of a file for discoverability when using inline lists
  • Avoid altering runtime API identifiers, package names, or fixed external terms

Example use cases

  • A CI job fails because a library name is flagged: recommend adding to project dictionary if used across files
  • A README contains a compound word flagged once: suggest hyphenation or inline cspell:ignore for that file
  • A new repo lacks cspell config: offer an interactive bootstrap to create a project-level config
  • A developer sees many flags from a generated file: recommend adding the path to ignorePaths in config
  • A one-off acronym in a single source file: insert an inline cspell:words entry at file top

FAQ

Notify the user and offer a guided bootstrap flow; do not auto-fix or add dictionary entries until the config is created.

When should I add a word to the project dictionary vs use an inline directive?

If the word appears in two or more files or is expected to recur project-wide, add it to the project dictionary. For a single, one-off occurrence use an inline directive.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational