agentleFS
darellchua2darellchua2/civiltekk-opencode-claude-skills/skills/linting-workflow-skill/SKILL.md

linting-workflow-skill

Skill7 starsChanged 56 days agoApache-2.0View on GitHub

Lint execution workflow — detect configs, run linters, auto-fix, resolve errors across languages. Triggers: lint, auto-fix lint. Per-language rules and configs: language-linting-skill; executor agent: linting-subagent. Gate sequence and pass semantics: verification-loop-skill.

  • Reads credentials
  • Deletes or force-pushes
  • Installs packages
  • Commits and pushes

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 8 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run linting and apply auto-fix when available

    line 15
  2. Distinctive:

    Verify fixes and commit changes

    line 17
  3. Distinctive:

    Use error messages for guidance

    line 95
  4. Distinctive:

    Run linting before committing

    line 114
  5. Distinctive:

    Don't disable rules as workaround

    line 117
  6. Distinctive:

    Use pre-commit hooks (Husky, pre-commit)

    line 120
  7. Distinctive:

    Check if rule supports auto-fix

    line 144
  8. Distinctive:

    Auto-detection: if this skill is invoked on a task that looks iterative (multiple cycles expected), prompt ONCE per session: "This looks …

    line 153
  9. Very specific:

    Git-as-memory: commit before each verify.

    line 159

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

What I do

I provide a generic linting workflow for multiple languages:

  • Detect project language and linter configuration
  • Run linting and apply auto-fix when available
  • Guide resolution of linting errors
  • Verify fixes and commit changes

When to use me

Use when:

  • Linting code before committing or PRs
  • Building workflow skills with code quality checks
  • Need consistent linting across multiple languages

This is a framework skill - provides linting logic that other skills extend.

Steps

Step 1: Detect Language and Linter

Detection:

  • package.json + tsconfig.json → TypeScript (ESLint)
  • package.json → JavaScript (ESLint)
  • pyproject.toml / requirements.txt → Python (Ruff)
  • go.mod → Go (golint/golangci-lint)
  • Gemfile → Ruby (RuboCop)

Configuration files:

  • ESLint: eslint.config.ts/js/mjs, .eslintrc.json/js/yaml
  • Ruff: pyproject.toml, .ruff.toml, ruff.toml

Step 2: Detect Package Manager

LanguageManagerLock FileCommand
JS/TSnpmpackage-lock.jsonnpm run <script>
JS/TSyarnyarn.lockyarn <script>
JS/TSpnpmpnpm-lock.yamlpnpm run <script>
PythonPoetrypyproject.tomlpoetry run <script>
Pythonpiprequirements.txtDirect command

Step 3: Run Linting

Commands:

# JavaScript/TypeScript (ESLint)
npm run lint              # npm
yarn lint                 # yarn
pnpm run lint            # pnpm
npx eslint .             # direct

# Python (Ruff)
ruff check .             # direct
poetry run ruff check .  # poetry

Step 4: Apply Auto-Fix

Auto-fix commands:

  • ESLint: npm run lint -- --fix
  • Prettier: npx prettier --write .
  • Ruff: ruff check . --fix
  • Black: black .

Auto-fix capabilities:

  • Style violations, unused variables, simple syntax issues
  • Formatting, indentation, quotes
  • Unused imports, simple refactorings

Step 5: Fix Remaining Errors

Error categories:

  • Syntax errors (prevents code from running)
  • Style violations (code style guidelines)
  • Potential bugs (risky code patterns)
  • Deprecation warnings (deprecated features)
  • Type errors (TypeScript type mismatches)
  • Missing docstrings (public functions/classes)

Resolution workflow:

  1. Run auto-fix first
  2. Fix remaining errors incrementally
  3. Re-run linting after each batch
  4. Use error messages for guidance

Step 6: Verify and Commit

Re-run linting:

# Re-check after manual fixes
npm run lint      # or
ruff check .

Commit fixes:

git add .
git commit -m "fix(lint): resolve linting errors"

Best Practices

  • Run linting before committing
  • Apply auto-fix before manual fixes
  • Fix errors incrementally, re-run between batches
  • Don't disable rules as workaround
  • Configure editor to lint on save
  • Integrate into CI/CD pipelines
  • Use pre-commit hooks (Husky, pre-commit)

Common Issues

Linter Not Found

Install linter:

npm install --save-dev eslint  # ESLint
pip install ruff                # Ruff

Config File Missing

Create default config:

  • ESLint: .eslintrc.json with {"extends": "eslint:recommended"}
  • Ruff: pyproject.toml with [tool.ruff] line-length = 88

Too Many Errors

  • Focus on one category at a time
  • Fix incrementally
  • Re-run after each batch

Auto-Fix Doesn't Work

  • Some errors require manual intervention
  • Review error messages
  • Check if rule supports auto-fix

Iteration Protocol (opt-in)

DO NOT execute any of the following unless AUTORESEARCH_PROTOCOL=1 is set in your environment. When unset, this skill behaves exactly as documented in all sections above; the Iteration Protocol block is descriptive only.

When AUTORESEARCH_PROTOCOL=1:

  1. Gate check: confirm env var is set; if unset, follow default behavior above.
  2. Auto-detection: if this skill is invoked on a task that looks iterative (multiple cycles expected), prompt ONCE per session: "This looks iterative. Enable autoresearch protocol? (y/n)". On "y", continue; on "n", default behavior. Cache the answer for the session.
  3. 5-stage loop: cycle Understand → Hypothesize → Experiment → Evaluate → Log & Iterate. See autoresearch-skill/SKILL.md.
  4. Evaluator contract: emit {"pass":bool,"score":N} JSON from a mechanical evaluator. Pass determines keep/revert; score logged to linting-results.tsv. See autoresearch-skill/references/evaluator-contract.md.
  5. Stuck detection: 3 consecutive non-improving iterations → strategy pivot; 5 consecutive → paradigm shift. See autoresearch-skill/references/stuck-detection.md.
  6. Audit trail: append every iteration to linting-results.tsv (8-column: iteration, commit, metric, delta, status, description, timestamp, evaluator_output). See autoresearch-skill/references/audit-trail.md.
  7. Crash recovery: syntax errors → fix immediately (don't count); runtime → max 3 fix attempts then skip; timeout → revert + log; OOM → smaller variant. See autoresearch-skill/references/crash-recovery.md.
  8. Git-as-memory: commit before each verify; auto-revert (git reset --hard HEAD~1) on pass:false.
  9. Iteration safety: bounded-by-default (Iterations: 25); safety blocks .env, node_modules/, rm -rf, git push --force. See autoresearch-skill/references/iteration-safety.md.

Skill-specific override

Stuck detection + crash recovery. 3 consecutive iterations without reducing lint-error-count → pivot to a different rule category (e.g., from E to W, or from style to type). Crash recovery: syntax errors introduced by auto-fix → revert immediately (don't count as iteration); rule conflicts → skip rule, log to linting-results.tsv.

Max iterations

  • Default: 25 iterations
  • Hard cap: 100 (explicit Iterations: unlimited overrides)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.