Skip to main content
AI/MLcoalesce-labs

validate-type-safety

Run the full 5-step TypeScript validation gate: type check, reward hacking scan, test inclusion, tests, and lint. This skill provides a structured multi-step pipeline that you cannot replicate on your own — it detects the project's package manager and linter automatically, checks tsconfig strictness, and invokes /scan-reward-hacking internally. **ALWAYS consult this skill when** the user mentions 'validate types', 'check type safety', 'type validation', 'type safety gate', wants to verify TypeScript changes before a PR, after completing a plan phase, or says anything about running type checks + tests + lint together. Even if you think you can run tsc yourself, use this skill — it catches issues you'd miss (tsconfig strictness, test exclusions, reward hacking patterns).

Stars
12
Source
coalesce-labs/catalyst
Updated
2026-05-31
Slug
coalesce-labs--catalyst--validate-type-safety
View on GitHubRaw SKILL.md

// install — copy + paste into any project

mkdir -p .claude/skills && curl -fsSL https://raw.githubusercontent.com/coalesce-labs/catalyst/HEAD/plugins/dev/skills/validate-type-safety/SKILL.md -o .claude/skills/validate-type-safety.md

Drops the SKILL.md into .claude/skills/validate-type-safety.md. Works with Claude Code, Cursor, and any agent that loads SKILL.md files from .claude/skills/.

Validate Type Safety

Final verification gate before marking any TypeScript work complete. Combines type checking with reward hacking detection, test verification, and linting. ALL 5 steps must pass.

Tooling Detection

Before running any commands, detect the project's package manager and linting tool. Do NOT hardcode bun, npm, or trunk — detect from what's available.

Package Manager

Check for lockfiles in the project root:

Lockfile Package Manager Run Command
bun.lockb or bun.lock bun bun run
pnpm-lock.yaml pnpm pnpm run
yarn.lock yarn yarn run
package-lock.json npm npm run

If multiple exist, prefer in the order listed above. Store as $PM_RUN (e.g., bun run).

Linter

Check for linting tools in this order:

Check Linter Command
.trunk/ directory exists Trunk trunk check --ci --upstream origin/main
biome.json or biome.jsonc exists Biome ${PM_RUN} biome check .
eslint.config.* or .eslintrc.* exists ESLint ${PM_RUN} eslint .

If none found, skip Step 5 and note it in the output.

Type Check Command

Look for a type-check or typecheck script in package.json:

  • If found: ${PM_RUN} type-check (or typecheck)
  • If not found: npx tsc --noEmit (fallback)

For monorepos, check if the root package.json has a workspace-level type-check script first.

Validation Steps

Step 0: tsconfig Strictness Check (Informational)

Read the project's tsconfig.json (or the tsconfig covering changed files in a monorepo). Verify:

  • "strict": true is set — WARN if missing
  • "noUncheckedIndexedAccess": trueINFO if missing (recommended)
  • "noImplicitReturns": trueINFO if missing (recommended)
  • "exactOptionalPropertyTypes": trueINFO if missing (recommended)

For monorepos: use the Glob tool to find tsconfig.json files, then identify which one covers the changed files (check include/exclude paths and references).

This step is informational only — it does not cause a FAIL verdict, but findings are reported.

Step 1: Run TypeScript Type Check

${PM_RUN} type-check  # or detected equivalent

Expected: Zero errors, exit code 0.

If errors exist, they MUST be fixed. Do not proceed to Step 2 until type-check passes.

Step 2: Run Reward Hacking Scan

Execute the /scan-reward-hacking skill on the changed files.

Expected: PASS verdict with no unfixed CRITICAL or HIGH severity patterns.

Step 3: Verify Test Inclusion

Check that test files are NOT excluded from type checking. Use Grep to search tsconfig files (in changed packages for monorepos):

  • Pattern: \.test\.ts or \.spec\.ts in exclude arrays of tsconfig files
  • Pattern: test directories in exclude arrays

Expected: No tsconfig files exclude test files from type checking.

Step 4: Run Tests

${PM_RUN} test

For monorepos with many packages, if the project has a --filter or --scope option, run tests only for affected packages when possible.

Expected: All tests pass. Type fixes should not break functionality.

Step 5: Lint Check

# Use detected linter command from Tooling Detection
trunk check --ci --upstream origin/main  # or biome/eslint equivalent

Expected: Zero lint errors.

If no linter was detected, skip this step and note it in the output.

Optional: Type Coverage Metric

If type-coverage is available (check with which type-coverage or npx type-coverage --help), report the numeric coverage score:

npx type-coverage --at-least 0

This is informational only — does not affect the verdict.

Output Format

Present results in this format:

## Type Safety Validation Results

### Tooling Detected
- Package manager: {bun|pnpm|yarn|npm}
- Linter: {trunk|biome|eslint|none}
- Type check command: {detected command}

### Step 0: tsconfig Strictness (Informational)
- strict: true — {YES / MISSING}
- noUncheckedIndexedAccess — {YES / missing (recommended)}
- noImplicitReturns — {YES / missing (recommended)}
- exactOptionalPropertyTypes — {YES / missing (recommended)}

### Step 1: TypeScript Type Check
- Status: PASS / FAIL
- Errors: {count} (list if any)

### Step 2: Reward Hacking Scan
- Status: PASS / FAIL
- Critical: {count}
- High: {count}
- (Details if any issues found)

### Step 3: Test File Inclusion
- Status: PASS / FAIL
- tsconfig files excluding tests: {count} (list if any)

### Step 4: Tests
- Status: PASS / FAIL
- Failed tests: {count} (list if any)

### Step 5: Lint Check
- Status: PASS / FAIL / SKIPPED (no linter detected)
- Errors: {count} (list if any)

### Type Coverage (if available)
- Coverage: {X}% ({Y}/{Z} types)

---

## Overall Verdict: PASS / FAIL

{If FAIL, list all items that must be fixed}

Verdict Criteria

PASS requires ALL of the following:

  • Type check exits with code 0
  • No CRITICAL or HIGH severity reward hacking patterns
  • No tsconfig files exclude test files (in changed packages)
  • All tests pass
  • Lint check passes (or no linter detected)

FAIL if ANY check fails.

If Validation Fails

Do NOT mark the work as complete. Instead:

  1. Fix all issues identified in the validation
  2. Re-run validation after fixes
  3. Only mark complete when validation passes

Fast-Fail Mode

For efficiency, stop on the first failing step. Report which step failed and what needs fixing. Re-run the full validation after fixes are applied.

Integration with Other Skills

  • Called by /implement-plan as part of quality gates
  • Called by /oneshot Phase 4 (Validate + Quality Gates)
  • Invokes /scan-reward-hacking internally for Step 2