--- name: lint-init description: > Initialize any repository with comprehensive lint rules and code quality tooling. Covers cyclomatic complexity, function/file length limits, parameter counts, type safety, code duplication, test coverage, and folder file-count limits. Supports TypeScript, Go, Python, Rust, and Java. Use this skill whenever the user asks to set up lint rules, initialize code quality checks, configure a linter, or bootstrap a new repo with quality gates — even if they don't say "lint" explicitly (e.g., "set up this repo", "add quality checks", "configure eslint/golangci-lint/ruff"). Also trigger when the user says /lint-init. --- # Lint Init Set up a complete code-quality gate system for a repository. The skill walks through an interactive interview, picks the right tools for the language, generates all config files, installs dependencies, and verifies everything passes. ## Workflow ``` Interview → Read language reference → Generate configs → Install deps → Verify → (Commit) ``` ## Step 1 — Interview Ask only what you don't already know. If the conversation already provides answers, skip ahead. ### Required questions 1. **Language** — TypeScript, Go, Python, Rust, Java, or other? 2. **Project type** — Library, CLI/application, monorepo, microservice? 3. **Package manager** — Language-specific (e.g., pnpm/npm/bun for TS, uv/poetry for Python). 4. **Formatter** — Prettier, gofmt, ruff format, rustfmt, etc. (suggest the standard for the language). 5. **Thresholds** — Use recommended defaults or customise? ### Optional (ask if relevant) - Runtime environment (Node.js vs Bun, CPython vs PyPy, etc.) - Existing configs to preserve - CI system (GitHub Actions, GitLab CI, etc.) — for later integration ## Step 2 — Rule Categories Every repo gets these 9 categories. Some may not apply to certain languages — the language reference files document which to skip and why. | # | Category | Default Threshold | Notes | |---|----------|-------------------|-------| | 1 | Cyclomatic complexity | ≤ 10 | Measures branching paths in a function | | 2 | Max function length | ≤ 120 lines | Skipping blanks and comments | | 3 | Max file length | ≤ 800 lines | Skipping blanks and comments | | 4 | Max parameters | ≤ 3 | Encourages use of option objects / structs | | 5 | Type safety | Strict | Language-dependent: TS→strict+explicit, Python→mypy strict, Go/Rust→built-in (skip) | | 6 | Code duplication | ≤ 5% (jscpd) + linter rules | jscpd for cross-file, linter for in-file duplicates | | 7 | Test coverage | ≥ 80% all metrics | Statements, branches, functions, lines | | 8 | Max files per directory | ≤ 10 code files | Custom script, code files only (not configs/tests) | | 9 | Best practices | Per language | Naming conventions, import ordering, no-any, etc. | If the user chose "use recommended defaults", apply the thresholds above. Otherwise, ask for each value individually. ## Step 3 — Read Language Reference Based on the language chosen in Step 1, read the corresponding reference file: - TypeScript / JavaScript → `references/typescript.md` - Go → `references/golang.md` - Python → `references/python.md` - Rust → `references/rust.md` - Java / Kotlin → `references/java.md` The reference file contains: - Which tools to install and how - Config file templates adapted to the rule categories - Which rules to skip for that language - Verification commands Follow the reference file closely for tool-specific details. ## Step 4 — Generate the Folder-Size Check Every language gets a **folder-size check script** that enforces "max code files per directory." The script should: 1. Walk the source directory recursively 2. Count only code files (by extension, per language) 3. Skip `node_modules`, `dist`, `build`, `.git`, `vendor`, `__pycache__`, `target` 4. Report violations and exit non-zero if any directory exceeds the limit 5. Accept `--max ` and `--path ` arguments Write the script in the project's primary language when practical (e.g., `.ts` for TypeScript, `.py` for Python). For languages where scripting is less natural (Go, Rust, Java), use a shell script or the language's test framework to run the check. Add it as a package script (e.g., `"check:folder-size"` in package.json, or a Makefile target). ## Step 5 — Pre-commit Hooks Set up pre-commit hooks so quality checks run automatically on `git commit`. | Language | Tool | Config | |----------|------|--------| | TypeScript | husky + lint-staged | `.husky/pre-commit` + `.lintstagedrc.json` | | Go | pre-commit framework or lefthook | `.pre-commit-config.yaml` or `lefthook.yml` | | Python | pre-commit framework | `.pre-commit-config.yaml` | | Rust | pre-commit framework or cargo-husky | `.pre-commit-config.yaml` | | Java | pre-commit framework or maven/gradle plugin | `.pre-commit-config.yaml` | The pre-commit should at minimum run: linter (fix mode) + formatter on staged files. Full test suites and coverage checks are better left to CI. ## Step 6 — Add Scripts / Targets Create a unified entry point for all checks. The naming convention varies by ecosystem: **package.json (TS/JS)**: - `lint`, `lint:fix`, `format`, `format:check`, `typecheck`, `test`, `test:coverage`, `check:duplication`, `check:folder-size`, `check:all` **Makefile (Go/Rust/Java)**: - `lint`, `fmt`, `test`, `coverage`, `check-duplication`, `check-folder-size`, `check-all` **pyproject.toml scripts or Makefile (Python)**: - Same as above, adapted for the tooling Always include a `check:all` / `check-all` target that runs every check in sequence. ## Step 7 — Verify After generating everything, run the full check suite to confirm zero errors: 1. Linter passes with no violations 2. Formatter reports no diffs 3. Type checker passes (if applicable) 4. Duplication check passes 5. Folder-size check passes If something fails, fix it before moving on. Common issues: - Config files themselves trigger lint rules → add appropriate ignores or adjust - Missing dependencies → re-run install - Threshold too strict for existing code → offer to relax or add inline suppressions ## Step 8 — Commit (Optional) If the user asks, commit the result with a message like: ``` chore: initialize lint rules and quality gates ``` ## Tips - **Monorepo**: Put shared lint config at the root. Each package extends it. Use workspace-aware tools (pnpm workspaces, Go workspaces, etc.) - **Existing code**: If the repo already has code, offer to run linter in "warn" mode first so the team can fix violations gradually. Provide a migration path. - **CI integration**: After local setup is verified, offer to generate a CI config (GitHub Actions, GitLab CI) that runs `check:all`.