agentleFS
Sign inStart free
anchildress1anchildress1/awesome-github-copilot/skills/eslint-plugin-configuring/SKILL.md

eslint-plugin-configuring

Skill67 starsChanged 59 days agoMITView on GitHub

Generate or update an ESLint plugin that exports rule configs compatible with ESLint v8 (eslintrc) and ESLint v9 (flat config).

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. anchildress1/awesome-ai★ 67100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository7 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    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:

    Never claim a plugin can force its own config to be used.

    line 31
  2. Distinctive:

    Never invent config-resolution behavior that isn't documented.

    line 32
  3. Distinctive:

    Never mix flat and legacy shapes: no flat object exported as legacy, no legacy config exported as an array.

    line 33
  4. Distinctive:

    Never emit colliding or ambiguous config names.

    line 35
  5. Distinctive:

    Never silently rename or remove a published config key — breaking for every consumer.

    line 36
  6. Very specific:

    Create plugin with configs empty.

    line 77
  7. Distinctive:

    All must hold before reporting done:

    line 109
  8. Distinctive:

    No claim that the plugin forces config usage

    line 116

≈ “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

Stale target. Rules below cover ESLint v8 and v9. v9 reached end-of-life 2026-08-06; v10 has been current since February 2026 and dropped Node < 20.19. Confirm the consumer's ESLint major and check https://eslint.org/docs/latest/extend/plugins for v10 plugin-shape changes before applying anything. Never assume the v9 shapes still hold.

Scope: author or modify an ESLint plugin package exporting rules, configs (flat and/or legacy), optional processors, and meta (name, version, namespace). Deliverable is plugin source plus working consumer examples.

FileUse for
references/eslint-plugin-configs.mdPlugin skeleton and config-assignment code
examples/consumers.mdFlat and legacy consumer configs for each naming strategy

Version semantics — state these correctly or not at all

VersionDefaultOther mode
v9Flat config.eslintrc* deprecated; applies only with ESLINT_USE_FLAT_CONFIG=false
v8.eslintrc*Flat opt-in via eslint.config.js or ESLINT_USE_FLAT_CONFIG=true

Hard constraints

  • Never claim a plugin can force its own config to be used. It cannot.
  • Never invent config-resolution behavior that isn't documented.
  • Never mix flat and legacy shapes: no flat object exported as legacy, no legacy config exported as an array.
  • Never emit colliding or ambiguous config names.
  • Never silently rename or remove a published config key — breaking for every consumer.

Inputs (assume derivable)

PACKAGE_NAME · NAMESPACE (rule/config prefix) · RULES (ruleId → implementation) · desired config set (recommended, strict, …).

Plugin shape

Single object, ESM default export:

  • meta — name, version, namespace
  • rules
  • configs
  • processors (optional)

meta.namespace is the canonical prefix for rules, configs, and registration. Rule IDs inside the plugin never contain /. Every rule reference in a config is "<namespace>/<ruleId>".

Naming strategy — pick one, apply throughout

StrategyWhenKeys
A (default)New plugin, or you own the public APIFlat flat/<configName> · Legacy legacy-<configName>
BLegacy <configName> already publishedKeep <configName> exactly; add flat/<configName>

Config requirements

Flat (v9 primary) — array of config objects · plugin registered in object form plugins: { [namespace]: plugin } · namespaced rule keys · languageOptions optional. configs["flat/recommended"] → Array<FlatConfigObject>

Legacy (v8) — plain eslintrc object · plugins: ["<namespace>"] · namespaced rule keys · globals/parserOptions optional. configs["legacy-recommended"] → EslintrcObject

Self-reference

A config that references the plugin object must not read plugin before it exists:

  1. Create plugin with configs empty.
  2. Assign configs afterward (Object.assign).

Consumer mapping

The flat/ prefix is an export key, never a consumer string.

Export keyConsumer extends
configs["flat/recommended"]"namespace/recommended"
configs["legacy-recommended"]"namespace/legacy-recommended"
configs["recommended"] (Strategy B)"namespace/recommended"

Required output

Unless the user excludes them, emit both, matching the chosen naming strategy exactly:

  1. Flat — eslint.config.js, using defineConfig, registering the plugin, using extends.
  2. Legacy — .eslintrc (JSON/YAML/JS), using plugins + extends.

Plus plugin source or diffs, and the validation result below.

Migration

  • Legacy only, dual support wanted → add flat/<name>
  • Flat only, v8 support wanted → add legacy-<name>
  • meta.namespace missing → add it and realign every rule prefix
  • Consumer examples disagree with config keys → regenerate the examples, not the keys

Validation gate

All must hold before reporting done:

  • meta.name, meta.version, meta.namespace present; namespace matches every rule prefix
  • Flat configs are arrays and register via object form
  • Legacy configs are eslintrc-shaped and register via array form
  • One naming strategy applied throughout; no config key collisions
  • Version behavior stated correctly per the table above
  • No claim that the plugin forces config usage

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.

Check your setup, free