Configures Husky, lint-staged, commitlint, and Python pre-commit
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
Paths: File paths (
shared/,references/,../ln-*) are relative to skills repo root. If not found at CWD, locate this SKILL.md directory and go up one level for repo root.
Type: L3 Worker Category: 7XX Project Bootstrap Parent: ln-740-quality-setup
Sets up Git hooks for automated code quality enforcement before commits.
Does:
Does NOT:
| Technology | Hook Manager | Staged Linting | Commit Validation |
|---|---|---|---|
| Node.js | Husky | lint-staged | commitlint |
| Python | pre-commit | pre-commit hooks | pre-commit hook |
| Mixed | Both (if needed) | Stack-specific | commitlint |
Before installing, check for existing hook configurations.
Files to Check:
| Tool | Indicators |
|---|---|
| Husky | .husky/ directory, husky in package.json |
| pre-commit | .pre-commit-config.yaml |
| lint-staged | lint-staged in package.json or .lintstagedrc* |
| commitlint | commitlint.config.*, .commitlintrc* |
Decision Logic:
npm install -D husky
npx husky init
This creates:
.husky/ directory.husky/pre-commit hook fileprepare script to package.jsonpip install pre-commit
# OR with uv:
uv add --dev pre-commit
pre-commit install
This creates:
.git/hooks/pre-commit (managed by pre-commit).pre-commit-config.yaml for configurationnpm install -D lint-staged
Create configuration (.lintstagedrc.mjs or in package.json):
Key Rules:
CRITICAL FIX: For .NET files, use correct syntax:
"*.cs": "dotnet format --include"is WRONG Use:"*.cs": "dotnet format whitespace --include"or run dotnet format separately
Configuration in .pre-commit-config.yaml:
repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: v0.8.0
hooks:
- id: ruff
args: [--fix]
- id: ruff-format
npm install -D @commitlint/cli @commitlint/config-conventional
Create commitlint.config.mjs with:
Add commit-msg hook:
echo 'npx --no -- commitlint --edit "$1"' > .husky/commit-msg
Add to .pre-commit-config.yaml:
- repo: https://github.com/compilerla/conventional-pre-commit
rev: v3.4.0
hooks:
- id: conventional-pre-commit
stages: [commit-msg]
Verify hooks work correctly.
Test 1: Lint-staged triggers
# Create a file with lint issues
echo "const x=1" > test-file.ts
git add test-file.ts
git commit -m "test: verify hooks"
# Expected: lint-staged runs, either fixes or blocks
Test 2: Commit message validation
git commit --allow-empty -m "bad message"
# Expected: commitlint rejects
git commit --allow-empty -m "test: valid message format"
# Expected: commit succeeds
Cleanup:
rm test-file.ts
git reset HEAD~1 # If test commit was made
RULE 1: Husky requires Git repository (
git initfirst).
RULE 2: lint-staged MUST have linters configured first (run ln-741 before ln-742).
RULE 3: Document
--no-verifyescape hatch for emergency commits.
RULE 4: pre-commit hooks should auto-fix when possible (
--fixflag).
git commit --no-verify)| File | Purpose |
|---|---|
| husky_precommit_template.sh | Husky pre-commit hook |
| husky_commitmsg_template.sh | Husky commit-msg hook |
| lintstaged_template.mjs | lint-staged configuration |
| commitlint_template.mjs | commitlint configuration |
| precommit_config_template.yaml | Python pre-commit config |
| hooks_guide.md | Detailed hooks guide |
| Error | Cause | Resolution |
|---|---|---|
| Husky not running | Missing prepare script | Run npx husky init again |
| lint-staged fails | Missing linter | Run ln-741 first |
| pre-commit not found | Not in PATH | pip install pre-commit |
| Hooks not triggering | Git hooks disabled | Check .git/hooks/ permissions |
| Windows path issues | Shell script format | Use cross-platform syntax |
Document for users:
# Skip all hooks (use sparingly!)
git commit --no-verify -m "emergency: bypass hooks"
# Skip only pre-commit (keeps commit-msg)
HUSKY=0 git commit -m "fix: urgent hotfix"
Version: 2.0.0 Last Updated: 2026-01-10
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
中文简介正在准备中。当前显示原文说明。
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.
中文简介正在准备中。当前显示原文说明。
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.
中文简介正在准备中。当前显示原文说明。
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.
中文简介正在准备中。当前显示原文说明。
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.
中文简介正在准备中。当前显示原文说明。
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.
中文简介正在准备中。当前显示原文说明。