Skip to content
cccskills
FreePublished on GitHub

markuplint-setup

Set up Markuplint in a project from scratch. Detects framework, creates config, runs initial lint, and guides the user through rule adoption with Bulk Suppressions support.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630 stars(GitHub 630 + cccskills 0)

Run score Not tested

See how to install

Files included (1)

  • SKILL.md4.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

markuplint-setup

Set up Markuplint in a project from scratch.

When to Use

  • "Set up markuplint" / "Add markuplint to this project"
  • "I want to lint my HTML"
  • "Install markuplint"

Steps

1. Check Existing Installation

  • Check package.json for markuplint and @markuplint/* packages
  • Check for config files (.markuplintrc*, markuplint.config.*)
  • If already installed, tell the user and suggest /markuplint-configure instead

2. Detect Project Type

Scan the project:

  • Package manager: check for package-lock.json / yarn.lock / pnpm-lock.yaml
  • Framework: check package.json dependencies for react, vue, svelte, astro, @alpinejs/csp, etc. Also check file extensions (.jsx, .tsx, .vue, .svelte, .astro, .pug, .php)
  • Monorepo: check for workspaces in package.json or lerna.json / nx.json / turbo.json

3. Choose Preset and Packages

Use WebFetch to get the latest supported syntaxes and preset information:

If installing a prerelease version (alpha / beta / rc), use https://next.markuplint.dev as the doc base instead — the stable site does not document prerelease behavior.

Use AskUserQuestion to confirm:

  1. Detected framework — is it correct?
  2. Which preset to use? (recommend based on framework)

4. Install Packages

Install using the detected package manager. Example:

npm install -D markuplint @markuplint/jsx-parser @markuplint/react-spec

Do NOT use npx markuplint --init — it requires interactive terminal input.

5. Create Configuration File

Write .markuplintrc directly. Keep it minimal — only include what's needed for the detected framework.

Static HTML needs no parser or specs:

{
  "extends": ["markuplint:recommended"]
}

Framework projects need parser and spec:

{
  "extends": ["markuplint:recommended-react"],
  "parser": {
    "\\.[jt]sx$": "@markuplint/jsx-parser"
  },
  "specs": {
    "\\.[jt]sx$": "@markuplint/react-spec"
  }
}

Refer to https://markuplint.dev/docs/guides/beyond-html for the exact parser/spec package names and file patterns for each framework.

When to use JavaScript/TypeScript config

If the project uses external config plugins or shared configs that require fine-grained merging, recommend markuplint.config.ts (or .js) with spread syntax — similar to ESLint's flat config pattern:

import type { Config } from '@markuplint/ml-config';
import reactConfig from '@example/markuplint-config-react';

const config: Config = {
  ...reactConfig,
  rules: {
    ...reactConfig.rules,
    'class-naming': '/^[a-z][a-z0-9-]*$/',
  },
};

export default config;

This gives full control over merge order and avoids the limitations of JSON extends (which uses a fixed merge strategy). Use JSON for simple setups; use JS/TS when composing multiple configs.

6. Run Initial Lint

Run Markuplint and capture the results:

npx markuplint "$ARGUMENTS" --format JSON

If $ARGUMENTS is empty, ask the user for the target glob (e.g., "src/**/*.html").

Summarize:

  • Total violation count
  • Breakdown by rule (which rules have the most violations)
  • Whether violations are concentrated in specific files/directories

7. Rule-by-Rule Adoption Decision

Use AskUserQuestion for each rule that has violations. Present rules one at a time (or batch related rules).

For each rule, explain what it checks (fetch the rule page if needed: https://markuplint.dev/docs/rules/{rule-id}) and offer options:

  1. Keep as error — fix all violations now
  2. Downgrade to warning — keep but don't block CI
  3. Bulk suppress — record current violations, enforce only on new code
  4. Disable — turn off the rule

When to recommend Bulk Suppressions:

  • Many violations in legacy code that won't be touched soon
  • The rule is valuable for new code

When to recommend disabling:

  • The rule doesn't fit the project's architecture or conventions
  • The rule conflicts with a template engine being used

8. Apply Decisions

  • Update .markuplintrc with disabled/warning rules
  • If Bulk Suppressions were chosen, run: npx markuplint "$TARGET" --suppress
  • Tell the user to commit markuplint-suppressions.json

9. Add npm Script

Add a lint script to package.json:

{
  "scripts": {
    "lint:html": "markuplint \"src/**/*.html\""
  }
}

Adjust the glob to match the project's source files and framework extensions.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Maintenance of the nu-validator coverage benchmark: defend the invariants (nu-only = 0, xref audit green), follow up a nu-validator upstream update (submodule bump / Docker image drift), and regression-check after markuplint rule or spec changes. Use when updating the validator submodule, when a bench refresh surfaces new nu-only entries, when excluded-ids entries go stale, or for the periodic health check. Trigger keywords: bench maintain, bench maintenance, nu update, submodule bump, validator update, bench refresh, nu-only regression, stale excluded-ids, image digest.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

Enable an existing or newly-added markuplint rule on the nu-validator bench by editing tests/external/bench/config.ts. Covers the flat-rule case (rules: { '<name>': true }) and the severity override case (rules: { '<name>': { severity: 'error' } }) that bench-virtual-rule does not. Use when a rule exists in the registry but the relevant nu fixtures stay nu-only because the rule is not enabled in the bench config, or when a rule's default severity is warning but the spec text it mirrors is a MUST / MUST NOT. Trigger keywords: enable bench rule, bench config flat rule, severity override bench, rule not flagging on bench, warning vs error in bench, escalate severity bench, no-contradictory-aria-prop bench, bench coverage missing rule.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

Set up the nu-validator benchmark environment — initialise the validator submodule, ensure Docker is running, populate the gitignored raw snapshots via yarn bench:update. Also covers Docker / nu-runner troubleshooting. Use when bench commands fail with "no snapshots found", "Docker daemon not reachable", port 28888 conflicts, or healthcheck timeouts; or when refreshing the bench after a long break. Trigger keywords: bench setup, bench Docker, validator submodule, no snapshots found, Docker daemon not reachable, healthcheck times out, port 28888, yarn bench:update first time, bench install, fresh clone bench.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

Triage one nu-only fixture from tests/external/snapshots/diff/nu-only.json by reading the spec, then drive its verdict to match-error, match-clean, or nu-over by either fixing markuplint or recording an excluded-ids.json entry. The core per-fixture operation of the nu-validator coverage benchmark. Use when a bench refresh surfaces new nu-only entries, when checking a coverage-claim ("markuplint misses X" / "over-detects Y") against the bench, or when classifying a specific fixture. Trigger keywords: nu-only, ml-only, coverage gap, bench triage, verdict, match-error, match-clean, nu-over, excluded-ids, declare nu over-detection, claim audit, audit fixture, mark-up valid per spec, spec-cited exclusion.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

Mirror a preset virtual rule (selectors under `nodeRules` in preset.html-standard.jsonc and similar) into bench/config.ts so the benchmark exercises it. Use when a new disallowed-element / similar selector lands in a preset and the matching nu fixtures remain stuck at nu-only despite the new rule existing in markuplint. Trigger keywords: virtual rule, nodeRules, disallowed-element, preset html-standard, bench config mirror, rule does not fire on bench, preset rule not exercised.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

Sync benchmark cross-reference blocks onto GitHub Issue bodies via `yarn bench:xref`, manage `tests/external/bench/issue-xref.config.ts` mappings, and run the pre-release checklist. Use when adding / removing / updating a primary or secondary mapping, when an issue closes upstream, when the xref CLI's output disagrees with what's on the issue body, or before cutting a release that touches a rule the benchmark covers. Trigger keywords: bench-xref, issue-xref, xref CLI, GitHub issue body, primary mapping, secondary mapping, umbrella block, pre-release checklist, bench-xref-audit workflow, marker version.

The English summary is being prepared. Showing the original description.

markuplint/markuplint630Updated Oct 26, 2026

See all skills by markuplint

Report a problem with this skill