GO — Healthy across all four use cases

• Last commit 1w ago
• 5 active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Single-maintainer risk — top contributor 82% of recent commits

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

typos is a fast, low-false-positive spell checker for source code written in Rust that finds and corrects spelling mistakes across monorepos. Unlike generic spell checkers, it's optimized for code—understanding identifiers, ignoring common acronyms and proper names—and runs fast enough to integrate into CI/CD pipelines and pre-commit hooks without blocking developers. Monorepo structure under .cargo/config.toml with workspace members in crates/ (inferred). Core library (typos crate) handles spell-checking logic, typos-cli wraps it for CLI usage (action.yml references CLI), and action/ subdirectory contains GitHub Action boilerplate (entrypoint.sh, format_gh.sh) for CI integration. Benchsuite/ contains comparative performance fixtures against codespell and misspell-go.

Developers maintaining large codebases (monorepos, open-source projects) who want automated spell checking on pull requests without the noise of false positives on technical terms and names. Platform maintainers integrating typos into CI systems (GitHub Actions, pre-commit) also use it heavily.

Production-ready and actively maintained. The codebase is substantial (~20MB Rust), has comprehensive CI workflows (.github/workflows/ includes audit.yml, ci.yml, maturin.yml for Python bindings), multiple distribution channels (cargo, Homebrew, Conda, Pacman), and active issue templates for false positives. Recent work includes GitHub Action support (action.yml, action/entrypoint.sh) and Python wheel builds (maturin.yml).

Standard open source risks apply.

Active development on GitHub Action integration (test-action.yml in workflows), Python bindings via maturin (maturin.yml), and pre-commit hook standardization (.pre-commit-hooks.yaml). Issue templates specifically track false positives (false-positive-word.yml, false-positive-data.yml), indicating ongoing dictionary refinement. Renovate.json5 suggests automated dependency updates are enabled.

Clone and build:

git clone https://github.com/crate-ci/typos.git
cd typos
cargo build --release
./target/release/typos-cli --help

Or install directly:

cargo install typos-cli --locked
typos

Daily commands: Development build and test:

cargo build
cargo test

Run spell checker on current directory:

cargo run --bin typos-cli -- .

With automatic fixes:

cargo run --bin typos-cli -- --write-changes .

• crates/typos-cli/src/bin/typos-cli/main.rs — Entry point for the CLI application; all contributors must understand the argument parsing, config loading, and main execution flow.
• crates/codespell-dict/src/lib.rs — Exposes the codespell dictionary used for spell checking; core data dependency for typo detection.
• crates/misspell-dict/src/lib.rs — Exposes the misspell dictionary; complementary spell checking data source alongside codespell.
• crates/dictgen/src/lib.rs — Dictionary generation and trie/automaton building logic; underpins efficient spell checking infrastructure.
• crates/typos-cli/src/config.rs — Configuration loading and schema handling; critical for understanding feature flags, exclusions, and customization.
• Cargo.toml — Workspace manifest defining all crates, dependencies, and lint rules; essential for build and dependency management.
• crates/typos-cli/src/bin/typos-cli/report.rs — Output formatting and reporting module; shapes how spell check results are presented to users.

Add a new dictionary source or spelling rule

1. Add new dictionary data to crates/codespell-dict/assets/dictionary.txt or crates/misspell-dict/assets/internal/gen/sources/main.json (crates/codespell-dict/assets/dictionary.txt or crates/misspell-dict/assets/internal/gen/sources/main.json)
2. Update or create dict_codegen.rs in the respective crate to process new dictionary entries (crates/codespell-dict/src/dict_codegen.rs or crates/misspell-dict/src/dict_codegen.rs)
3. Run cargo build to regenerate dictionary code and test via cargo test (Cargo.toml)

Add a new CLI flag or configuration option

1. Define the new argument in args.rs with derive(clap) attributes (crates/typos-cli/src/bin/typos-cli/args.rs)
2. Add corresponding field to Config struct and load logic in config.rs (crates/typos-cli/src/config.rs)
3. Update config.schema.json to document the new option (config.schema.json)
4. Use the option in main.rs or report.rs to drive behavior (crates/typos-cli/src/bin/typos-cli/main.rs)

Optimize pattern matching performance

1. Profile using benchmarks in crates/typos-cli/benches/, especially check_file.rs and tokenize.rs (crates/typos-cli/benches/check_file.rs)
2. Modify trie or Aho-Corasick logic in crates/dictgen/src/trie.rs or aho_corasick.rs (crates/dictgen/src/trie.rs or crates/dictgen/src/aho_corasick.rs)
3. Re-run benchmarks to measure improvement: cargo bench -p typos-cli (Cargo.toml)

• Rust — Memory-safe, fast execution, zero-cost abstractions for automaton matching; enables monorepo-scale performance.
• Aho-Corasick automaton (crates/dictgen) — Optimal O(n+m+z) complexity for simultaneous multi-pattern matching on large source trees.
• TOML configuration files — Human-readable, standardized format for exclusion rules, dictionary selection, and customization.
• Pre-commit hooks + GitHub Actions — Integrates spell checking into development workflows without requiring new tools or breaking existing pipelines.
• Dual dictionaries (codespell + misspell) — Comprehensive coverage by combining two independent spell-check sources; users can toggle between them.

• Compile dictionaries at build time rather than load at runtime

  • Why: Reduces startup overhead and enables static analysis; makes binary larger.
  • Consequence: Fast CLI startup but larger binary size (~10–20MB); no runtime dictionary reloading without recompile.

• Low false-positive design (conservative spell checking)

  • Why: Intended for PR integration; teams need confidence that flagged words are truly errors.
  • Consequence: May miss some real typos; trade-off favors precision over recall.

• Single-pass file traversal with in-memory automaton

  • Why: Maximizes throughput on monorepos; deterministic per-file latency.
  • Consequence: Higher memory footprint; not suitable for extremely constrained environments.

• Interactive spell-check UI or REPL
• Real-time monitoring / continuous background checking
• Custom language grammar or syntax-aware checking (treats all files as plain text)
• Multi-language support beyond English variants (US/UK)
• Network or cloud-based spell checking
• Plugin system for third-party checkers

MSRV is 1.91 (defined in Cargo.toml workspace.package) — older Rust toolchains will fail. The --locked flag in install instructions (cargo install typos-cli --locked) is mandatory; Cargo.lock is committed and must be respected. Config file is _typos.toml (underscore prefix, not typos.toml); many users may name it wrong. False positives require TOML config edits with specific sections ([default.extend-identifiers], [default.extend-words], extend-ignore-identifiers-re); there's no CLI override for quick suppression. GitHub Action (action.yml) may have unreleased features not reflected in releases; check action branch vs. tag versions.

• Identifier vs. Word Tokenization — typos distinguishes camelCase/snake_case identifiers from free-form words, enabling separate ignore rules (extend-ignore-identifiers-re vs. extend-words); core to low false-positive design
• Dictionary Trie or FSM — typos embeds a compiled spell-check dictionary for O(1) lookups; understanding how dictionary is built and updated (via GitHub issues) is key to contributing corrections
• Regex-based Ignore Patterns — extend-ignore-identifiers-re allows regex whitelisting of entire identifier patterns (e.g., 'AttributeID.Supress.'); users must understand regex semantics to avoid false positives
• TOML Configuration Cascading — _typos.toml supports [default] and [type.*] sections for per-filetype rules; configuration inheritance is non-obvious and trips up new users
• Pre-commit Framework Integration — typos is distributed as a pre-commit hook (.pre-commit-hooks.yaml); developers integrating typos must understand how hooks, stages, and pass/fail logic work
• GitHub Action Artifact Formatting — action/format_gh.sh converts typos output to GitHub-annotation format for inline PR comments; understanding this flow is necessary for CI/CD contributions
• Monorepo Benchmarking — benchsuite/ compares typos against codespell and misspell on real codebases (Linux kernel, ripgrep, subtitles); understanding how performance claims are validated matters for optimization PRs

• codespell-project/codespell — Direct competitor; Python-based spell checker for code, benchmarked against typos in benchsuite/
• client9/misspell — Golang spell checker; typos benchmarks against misspell-go variant in benchsuite/fixtures
• pre-commit/pre-commit-hooks — Ecosystem companion; typos integrates via .pre-commit-hooks.yaml; users installing typos often use pre-commit framework
• crate-ci/committed — Same organization; complementary linter for commit message style; runs in parallel CI workflow (committed.yml)
• actions-rs/clippy-check — Rust CI ecosystem; typos GitHub Action follows similar patterns for artifact reporting and PR comments

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add integration tests for typos GitHub Action with real workflow scenarios

The repo has action.yml and .github/workflows/test-action.yml defined, but there are no documented integration tests validating the action against realistic monorepo scenarios (multiple file types, various false positives). This would increase confidence in the action.yml functionality and catch edge cases before releases.

• [ ] Review action.yml and action/entrypoint.sh to understand current implementation
• [ ] Create .github/workflows/integration-test.yml that tests the action against sample monorepo structures
• [ ] Add test fixtures in action/test-fixtures/ with intentional typos and false positives
• [ ] Document test results in docs/github-action.md with expected behavior

Add comprehensive CLI integration tests covering config.schema.json validation

The repo has config.schema.json but no visible test suite validating that all documented configuration options work end-to-end. This is critical for a tool focused on configuration (typos config), especially given the committed.toml and Cargo.toml examples.

• [ ] Create crates/typos-cli/tests/config_integration.rs for testing all config.schema.json fields
• [ ] Add test fixtures in crates/typos-cli/tests/fixtures/ with various .typos.toml configurations
• [ ] Test edge cases: empty config, all options set, conflicting settings, glob patterns
• [ ] Ensure tests validate both valid and invalid configurations against the schema

Document and add benchmarks for dictionary loading performance (crates/codespell-dict)

The crates/codespell-dict contains assets/dictionary.txt and compatible.csv but benchsuite/ only has external tool comparisons. Adding dictionary-specific benchmarks would validate performance claims and prevent performance regressions when dictionary updates occur.

• [ ] Create benchsuite/uut/typos_dict_load.sh to benchmark dictionary loading time with various sizes
• [ ] Add benchsuite/fixtures/ tests comparing codespell-dict vs alternatives on large files
• [ ] Document findings in crates/codespell-dict/README.md with baseline performance metrics
• [ ] Add benchmark results to benchsuite/runs/ directory with timestamp and environment details

• Add integration test for _typos.toml extend-identifiers with non-ASCII characters; current test suite (inferred from CI) likely covers ASCII only, but real-world projects use Cyrillic/CJK identifiers.
• Extend .pre-commit-hooks.yaml with entry for checking filenames only (--files flag integration); currently docs mention this feature but pre-commit hook doesn't expose it as a separate stage.
• Document the regex syntax supported by extend-ignore-identifiers-re with concrete examples in docs/reference.md; users struggle with this feature based on issue template existence.

The typos codebase demonstrates good security practices overall with dual licensing, workspace lints for code quality, and automated audit workflows. However, there are minor improvements possible in Docker configuration (image selection, non-root user), Cargo.toml configuration (invalid edition), and supply chain security measures. No critical vulnerabilities related to hardcoded secrets, injection risks, or insecure dependencies were identified in the provided files. The tool itself is a security-focused spell checker, which indicates security-conscious development.

• Medium · Dockerfile uses rust image for build stage — Dockerfile, line 3. The Dockerfile uses 'rust:${DEBIAN_DIST}' as the base image for the builder stage. This image is larger and contains more tools than necessary, increasing the attack surface. It's recommended to use a minimal base image or rust-slim variant. Fix: Change 'FROM rust:${DEBIAN_DIST}' to 'FROM rust:${DEBIAN_DIST}-slim' or use a minimal base image to reduce image size and attack surface.
• Low · Cargo.toml references incorrect edition — Cargo.toml, workspace.package section. The workspace Cargo.toml specifies edition = '2024', but Rust 2024 edition does not exist as of the MSRV date. This should be '2021' or another valid edition. This is not a security vulnerability per se, but indicates a configuration error that could cause build failures. Fix: Change 'edition = "2024"' to 'edition = "2021"' or the appropriate valid Rust edition.
• Low · No explicit dependency security scanning configured — .github/workflows/audit.yml. While the repository has audit.yml workflow, there's no explicit SBOM generation or dependency lock file pinning strategy visible. For a security-focused tool like typos, additional supply chain security measures would be beneficial. Fix: Implement SBOM generation, enable dependabot or similar supply chain security tools, and ensure Cargo.lock is committed for reproducible builds.
• Low · Docker image lacks security metadata — Dockerfile, final stage (line 7-9). The Dockerfile does not specify a USER directive for the final stage, meaning the container runs as root by default. This violates the principle of least privilege. Fix: Add a non-root user and switch to it before the ENTRYPOINT. Example: RUN useradd -m appuser && USER appuser
• Low · No explicit security headers or configuration validation — config.schema.json (root). The config.schema.json file is present but schema validation for configuration files is not visible in the main codebase structure. This could allow invalid configurations that bypass security controls. Fix: Ensure schema validation is enforced at runtime and document security-critical configuration options.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/crate-ci/typos shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live crate-ci/typos repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/crate-ci/typos.

What it runs against: a local clone of crate-ci/typos — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in crate-ci/typos | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 37 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of crate-ci/typos. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/crate-ci/typos.git
#   cd typos
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of crate-ci/typos and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "crate-ci/typos(\\.git)?\\b" \\
  && ok "origin remote is crate-ci/typos" \\
  || miss "origin remote is not crate-ci/typos (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "crates/typos-cli/src/bin/typos-cli/main.rs" \\
  && ok "crates/typos-cli/src/bin/typos-cli/main.rs" \\
  || miss "missing critical file: crates/typos-cli/src/bin/typos-cli/main.rs"
test -f "crates/codespell-dict/src/lib.rs" \\
  && ok "crates/codespell-dict/src/lib.rs" \\
  || miss "missing critical file: crates/codespell-dict/src/lib.rs"
test -f "crates/misspell-dict/src/lib.rs" \\
  && ok "crates/misspell-dict/src/lib.rs" \\
  || miss "missing critical file: crates/misspell-dict/src/lib.rs"
test -f "crates/dictgen/src/lib.rs" \\
  && ok "crates/dictgen/src/lib.rs" \\
  || miss "missing critical file: crates/dictgen/src/lib.rs"
test -f "crates/typos-cli/src/config.rs" \\
  && ok "crates/typos-cli/src/config.rs" \\
  || miss "missing critical file: crates/typos-cli/src/config.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 37 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~7d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/crate-ci/typos"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.