Code Quality Tooling — Edho Ferdian Mode

You are setting up the mechanical gate that catches style and lint violations before they land in a commit or a push, not writing the style rules themselves and not reviewing already-written code for quality.

Boundary with neighbouring skills — read this first

This is a genuine gap this ecosystem didn't cover until now (there was no skill for hook/formatter/linter setup itself), so the boundary with what already exists matters more than usual:

	This skill	Neighbour
Git hook enforces "no commit without passing lint"	This skill	—
Commit message format, branch strategy, PR triage	git-and-release-ops-edho-ferdian	Different concern: message/workflow shape, not gate tooling. Both can fire together (a pre-commit hook can also check commit message format via commitlint) — when it does, this skill covers wiring the hook, git-and-release-ops-edho-ferdian covers what the format rule should be.
A build/lint step is already configured but now fails	build-fix-edho-ferdian	This skill sets up a working gate for the first time or reconfigures it; a config that used to pass and now doesn't is a build-fix diagnosis, not a fresh setup.
What code pattern to write in a given language/framework	frontend-engineering-edho-ferdian, backend-engineering-edho-ferdian, language-code-review-edho-ferdian	This skill's linter/formatter rules should reflect those patterns, but this skill doesn't author the patterns themselves.
Reviewing a diff for quality issues a human should catch (naming, complexity, duplication)	code-review-edho-ferdian	This skill's gate catches only what a linter/formatter can catch mechanically — style, common bug patterns, import order. It is not a substitute for the review skill's judgment-based findings.
Detecting whether an already-configured gate was tampered with (a rule quietly loosened to make a failing check pass)	config-hygiene-edho-ferdian's "Config tamper guard" and "Language/tool gate table"	This skill sets up or intentionally reconfigures the gate; config-hygiene-edho-ferdian scans an existing config for unexplained narrowing during its periodic ~/.claude-environment hygiene pass. Its language/tool table is a fast fact-check reference for that scan, not competing setup guidance — see references/javascript-typescript.md §1 for how the two tables' Biome/ESLint framing reconciles.

When to use this skill

• A project has no linter/formatter/git-hooks yet and the user wants one set up.
• The user wants to add Husky pre-commit or pre-push enforcement to an existing project.
• ESLint/Prettier configs conflict with each other, or a no-unused-vars style false-positive needs a config-level fix (not a code-level one).
• Deciding what should run in a local hook vs. only in CI (a common question with no obvious default — see below).

Core recommendation for a new JS/TS project

1. Biome by default — one Rust-based tool doing both linting and formatting, no ESLint/Prettier config-conflict class of bug to manage, and it's this ecosystem's existing default per config-hygiene-edho-ferdian's language/tool gate table (Biome-first for .ts/.tsx/.js/.jsx) — this skill now matches that rather than contradicting it. Fall back to ESLint + Prettier when the project needs plugin coverage Biome doesn't have yet (framework-specific rule sets like eslint-plugin-jsx-a11y, a custom rule, or an existing large ESLint config not worth migrating). See references/ javascript-typescript.md §1 for the full decision guide.
2. Husky (v9+, npx husky init) to install Git hooks that are versioned in the repo (.husky/) so every contributor gets them automatically on npm install — not a personal ~/.gitconfig hook that only exists on one machine.
3. lint-staged to run the chosen linter/formatter only on staged files inside the pre-commit hook — running a full-repo lint on every commit doesn't scale past a small project and trains people to skip the hook out of impatience.

See references/javascript-typescript.md for exact config files for both paths, the ESLint flat-config migration note, and the hook script contents.

What goes in pre-commit vs. pre-push vs. CI-only

A hook that's too slow gets bypassed (git commit --no-verify becomes a habit); a gate that's too weak lets broken code land. Split by cost:

• pre-commit: lint + format on staged files only (lint-staged). Should finish in well under a second for a typical commit.
• pre-push: the type-checker and the test suite (or a fast subset of it) — expensive enough to be wrong for every commit, cheap enough to be worth blocking a push.
• CI-only: the full test suite, build, and any slow static analysis. Never make a contributor wait for the full suite locally before every push — CI is where the authoritative, complete gate lives; local hooks are a fast approximation that catches most problems earlier.

Full rationale and the cross-stack equivalents (Python, Go, Rust) are in references/other-stacks.md.

Language routing (fixed — see skill-authoring-edho-ferdian's canonical contract)

Communication to the user in Bahasa Indonesia; config files, hook scripts, and commit-adjacent output in English — fixed, never ask. Full contract: skill-authoring-edho-ferdian §7.

External docs (fixed — see skill-authoring-edho-ferdian's canonical contract)

ESLint's flat-config API, Husky's hook script format, and lint-staged's config surface have all changed across major versions in ways a memorized answer can get wrong. Resolve current setup steps live via Context7 before writing config into a project. Full contract: skill-authoring-edho-ferdian §9.

Provenance

Native skill, added 2026-09-16 per D-048, at the user's request after confirming this ecosystem had no coverage for linter/formatter/git-hook setup (checked git-and-release-ops-edho-ferdian, which covers commit format and PR workflow but not the enforcement tooling itself). Not adapted from an external source.