Skip to content
Skills Library
Programming · Building & coding

code-quality

/code-quality

Improve the quality and type-safety of TypeScript/JavaScript being written or refactored — parse-don't-validate, make-illegal-states-irrepresentable, exhaustive matching, pure-function/IO separation, and public-API hygiene. Use when asked to refactor, clean up, improve, harden, or review the design/quality of code or an API. NOT for hunting bugs (that's /code-review) and NOT for vigiles's own spec/lint rules.

Repository
vigiles ↗
Licence
MIT
Last repository change
14.10.2026

Assessment and security

100/ 100Class: good
Format25 / 25
Frontmatter with name and description, valid name, description up to 1,024 characters, name matching the folder.
Discoverability25 / 25
Description explains when to use the skill, has a reasonable length and uses third person.
Content35 / 35
At least 150 words and at most 500 lines, headings, step lists, examples or code.
Hygiene15 / 15
No placeholders such as TODO, no Windows paths, with a licence.
Riskno signals detected in the scan
Files in this package
6
Scripts
0
HTML comments
0
URLs in SKILL.md
0
Deprecation

No signals detected. Repository changed on 14.10.2026, without references to retired models or APIs.

Licence

MIT, open: use and modify while retaining author attribution.

What it does and when to use it

Improve the quality and type-safety of TypeScript/JavaScript being written or refactored — parse-don't-validate, make-illegal-states-irrepresentable, exhaustive matching, pure-function/IO separation, and public-API hygiene. Use when asked to refactor, clean up, improve, harden, or review the design/quality of code or an API. NOT for hunting bugs (that's /code-review) and NOT for vigiles's own spec/lint rules.

Triggers from the description

s /code-review) and NOT for vigiles
Original author description

Improve the quality and type-safety of TypeScript/JavaScript being written or refactored — parse-don't-validate, make-illegal-states-irrepresentable, exhaustive matching, pure-function/IO separation, and public-API hygiene. Use when asked to refactor, clean up, improve, harden, or review the design/quality of code or an API. NOT for hunting bugs (that's /code-review) and NOT for vigiles's own spec/lint rules.

How it works

  1. When this fires
  2. The techniques — read the matching reference
  3. How to apply
  4. Guardrails
Original SKILL.md headings · 30 lines, 446 words
SKILL.md preview
---
name: code-quality
description: Improve the quality and type-safety of TypeScript/JavaScript being written or refactored — parse-don't-validate, make-illegal-states-irrepresentable, exhaustive matching, pure-function/IO separation, and public-API hygiene. Use when asked to refactor, clean up, improve, harden, or review the design/quality of code or an API. NOT for hunting bugs (that's /code-review) and NOT for vigiles's own spec/lint rules.
---

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 you                                                                                                       | Technique                               | Reference                                                                                                |
| --------------------------------------------------------------------------------------------------------------------------- | --------------------------------------- | -------------------------------------------------------------------------------------------------------- |
| a magic `0` / `""` / `-1`; the same primitive re-validated at many sites; `"x" in obj` repeated                             | **Parse, don't validate**               | [`references/parse-dont-validate.md`](references/parse-dont-validate.md)                                 |
| a field that's always `""`; boolean-flag soup; a sentinel standing in for "absent"; an impossible combo that still compiles | **Make illegal states irrepresentable** | [`references/make-illegal-states-irrepresentable.md`](references/make-illegal-states-irrepresentable.md) |
| a `switch`/`if`-chain on a union with no exhaustiveness guard                                                               | **Exhaustive matching**                 | [`references/exhaustive-matching.md`](references/exhaustive-matching.md)                                 |
| logic tangled with IO (`spawn`/`fetch`/`fs`); a function that's hard to test                                                | **Pure functions + injected seams**     | [`references/pure-functions.md`](references/pure-functions.md)                                           |
| a public export with a fuzzy shape; a `string` that means an enum; a leaked internal helper                                 | **Public-API quality**                  | [`references/public-api-quality.md`](references/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.
Files in this package (6)
  • SKILL.md 4 KB
  • references/exhaustive-matching.md 2 KB
  • references/make-illegal-states-irrepresentable.md 2 KB
  • references/parse-dont-validate.md 2 KB
  • references/public-api-quality.md 2 KB
  • references/pure-functions.md 2 KB

Versions

RepositoryScoreLicence
This page · zernie/vigiles100MIT
nasrulhazim/claude100MIT
piomin/claude-ai-spring-boot100Apache-2.0
joris887/exosuit100MIT
BlackBeltTechnology/pi-agent-dashboard100MIT
wrongstack/wrongstack100MIT
microsoft/winappcli100MIT
ingvarch/skills100MIT
oborchers/fractional-cto100MIT

Identical content appears in 1 other GitHub folders. We show one copy with the highest score.

Database snapshot: 13.11.2026 · package version ad0ee69ee393 (SHA-256 digest of the entire package)

Downloads in the last 30 days: 0 · ranking

Report a problem with this skill: harmful content, incorrect descriptions or an author’s removal request.

Similar skills

  • 95typescript-quality-checker
    Validate TypeScript/JavaScript code quality with ESLint, Prettier, type checking, and security analysis. Use for TypeScript/JS codebases to ensure code quality and standards.
  • 100typescript-refactoring
    Systematically refactor TypeScript codebases for readability, type safety, and AI-friendliness. Use when asked to "refactor this", "clean up this code", "make this codebase better", "improve code quality", or when inheriting a messy TypeScript project. Covers assessment,…
  • 100typescript-quality
    TypeScript/JavaScript code quality with ESLint, Biome, and strict TypeScript. Covers linting, formatting, type safety, and best practices. USE WHEN: user works with "TypeScript", "JavaScript", "ESLint", "Biome", asks about "TS strict mode", "type safety", "linting rules", "code…
  • 100refactor
    Safe refactoring with test guard — improve code quality without changing behavior. Use when: refactor, cleanup, restructure, simplify, extract function, improve code quality.
  • 90typescript-rules
    React/TypeScript frontend development rules including type safety, component design, state management, and error handling. Use when implementing React components, TypeScript code, or frontend features.
  • 90check
    Validate code quality — auto-fix formatting/lint, verify types, run tests. Use when asked to "validate code", "check code", or validate before committing; also lint-only asks ("run linter", "fix lint errors"). Don't use for committing (/commit), pushing (/to-pr), or writing new tests (/tdd).

Feedback and reports

Your message goes to Bartosz Sokoliński. An email address is needed only for a reply. See the privacy policy.