mcpField
C
code-quality

code-quality

github.com/zernieDevelopment15391 installsUpdated 1d ago
Repository

About code-quality

A type-driven code-quality skill for developers writing or refactoring code. It maps code smells to focused references and emphasizes incremental changes, green tests, and avoiding unnecessary abstractions.

Key features

  1. 01Choose techniques by code smell
  2. 02Parse inputs instead of repeated validation
  3. 03Use types to rule out illegal states
  4. 04Check exhaustive matching for unions
  5. 05Separate pure logic from I/O
  6. 06Keep the public API small

Use cases

  1. 01Refactor code that repeatedly validates primitives
  2. 02Improve types with flag combinations or sentinel values
  3. 03Untangle I/O-heavy logic that is hard to test
  4. 04Design a new module, type, or public export

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/zernie/vigiles --skill code-quality

After installing, type/code-qualityin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

references/
exhaustive-matching.md
make-illegal-states-irrepresentable.md
parse-dont-validate.md
public-api-quality.md
pure-functions.md

Details

From the project README

Apply a small set of type-driven quality techniques when writing or refactoring code. Each technique has its own reference — the principle, a real before/after from this repo, and the smells to grep for. Read the reference(s) that match the code in front of you; don't apply all five blindly.

When this fires

A request to refactor / clean up / improve / harden / tighten code or an API — or when you're about to write a new module/type/public export and want it right the first time. Not a bug hunt (use /code-review).

The techniques — read the matching reference

Smell in front of youTechniqueReference
a magic 0 / "" / -1; the same primitive re-validated at many sites; "x" in obj repeatedParse, don't validatereferences/parse-dont-validate.md
a field that's always ""; boolean-flag soup; a sentinel standing in for "absent"; an impossible combo that still compilesMake illegal states irrepresentablereferences/make-illegal-states-irrepresentable.md
a switch/if-chain on a union with no exhaustiveness guardExhaustive matchingreferences/exhaustive-matching.md
logic tangled with IO (spawn/fetch/fs); a function that's hard to testPure functions + injected seamsreferences/pure-functions.md
a public export with a fuzzy shape; a string that means an enum; a leaked internal helperPublic-API qualityreferences/public-api-quality.md

How to apply

  1. Name the decision out loud before you change the shape — what illegal state it forbids, where the parse boundary sits (the surface-architecture-decisions reflex). A quality change the reviewer can't see is churn.
  2. One technique at a time, tests stay green. Change the type, let tsc show you every call site, fix them, run the tests. Never batch five refactors into one unreviewable diff.
  3. Don't over-abstract (rule-of-three / YAGNI). A tagged union for 3 real variants is good; an abstraction for a difference that doesn't exist yet is the bug this skill is supposed to prevent.
  4. Prefer the strongest option the DECIDABILITY allows — a type that can't express the bad state beats a runtime check that hopes to catch it; but a runtime guard at a boundary beats nothing when the input is genuinely dynamic.

Guardrails

  • Quality only, not correctness. This skill improves shape/design; it does not hunt for bugs — that's /code-review.
  • Every change removes a real failure mode. If you can't name the bug the new shape prevents, don't make the change.
  • Keep the public surface small. A new export is a contract (see the public-API reference); don't widen it to make a refactor convenient.

Comments

Markdown supported