Stylelint Plugin Maintenance
Use this skill for Stylelint plugin authoring workflows where runtime shape, PostCSS traversal, metadata, docs, configs, tests, and package surfaces must stay coherent.
Bootstrap A New Plugin
- Treat the current repository as a structure and quality baseline, not as source rule content.
- Extract package name, namespace/rule prefix, short purpose, and requested initial rules from the user's message.
- Re-identify package metadata, README, docs site, URLs, Docusaurus branding, examples, generated tables, and release config.
- Remove unrelated template rule artifacts surgically while preserving shared infrastructure.
- Implement only requested rule behavior. If no rules are requested, produce a clean minimal plugin scaffold.
- Keep rule metadata and docs statically authored.
- Update Stylelint plugin exports, shareable configs, tests, docs, generated surfaces, and package exports.
Audit Best Practices
- Inspect package versions, runtime shape, rule naming, metadata, messages,
meta.url, fixability, PostCSS traversal strategy, custom syntax behavior, shareable configs, tests, docs, package exports, and publish readiness.
- Verify current official Stylelint documentation when behavior depends on recent tooling.
- Prefer deterministic fixer behavior and avoid generic CSS-lint advice that another established plugin already covers unless this repo has a clear domain-specific reason.
- Fix high-confidence issues directly.
Discover Rules
Research nearby Stylelint plugins and domain-specific CSS ecosystems. Choose rules that are useful, non-duplicative, and realistic to diagnose reliably. Implement typed rule modules, Stylelint/PostCSS-safe traversal, static metadata, docs, tests using real stylelint.lint(...), config wiring, and deterministic fixers only when safe.
Validation
Run the repository's lint, typecheck, tests, docs, sync, package checks, and publish dry run when available. Finish with ideas evaluated, changes made, gaps intentionally left, and validation results.
1---2name: stylelint-plugin-maintenance3description: Builds, audits, and maintains Stylelint plugin repos. Use when scaffolding plugins, auditing best practices, discovering/implementing domain-specific rules, or syncing docs, tests, configs, and package validation.4---56# Stylelint Plugin Maintenance78Use this skill for Stylelint plugin authoring workflows where runtime shape, PostCSS traversal, metadata, docs, configs, tests, and package surfaces must stay coherent.910## Bootstrap A New Plugin11121. Treat the current repository as a structure and quality baseline, not as source rule content.132. Extract package name, namespace/rule prefix, short purpose, and requested initial rules from the user's message.143. Re-identify package metadata, README, docs site, URLs, Docusaurus branding, examples, generated tables, and release config.154. Remove unrelated template rule artifacts surgically while preserving shared infrastructure.165. Implement only requested rule behavior. If no rules are requested, produce a clean minimal plugin scaffold.176. Keep rule metadata and docs statically authored.187. Update Stylelint plugin exports, shareable configs, tests, docs, generated surfaces, and package exports.1920## Audit Best Practices21221. Inspect package versions, runtime shape, rule naming, metadata, messages, `meta.url`, fixability, PostCSS traversal strategy, custom syntax behavior, shareable configs, tests, docs, package exports, and publish readiness.232. Verify current official Stylelint documentation when behavior depends on recent tooling.243. Prefer deterministic fixer behavior and avoid generic CSS-lint advice that another established plugin already covers unless this repo has a clear domain-specific reason.254. Fix high-confidence issues directly.2627## Discover Rules2829Research nearby Stylelint plugins and domain-specific CSS ecosystems. Choose rules that are useful, non-duplicative, and realistic to diagnose reliably. Implement typed rule modules, Stylelint/PostCSS-safe traversal, static metadata, docs, tests using real `stylelint.lint(...)`, config wiring, and deterministic fixers only when safe.3031## Validation3233Run the repository's lint, typecheck, tests, docs, sync, package checks, and publish dry run when available. Finish with ideas evaluated, changes made, gaps intentionally left, and validation results.
Nick2bad4u