AgentSkillsCN

Quality Tools

代码质量工具(ESLint、Prettier、tsc、linters)的工具定义和使用模式。代理引用此技能而非内联工具定义。

SKILL.md
--- frontmatter
name: Quality Tools
description: Tool definitions and usage patterns for code quality tools (ESLint, Prettier, tsc, linters). Agents reference this skill instead of inline tool definitions.
version: 1.0.0
<purpose> Provide standardized tool definitions and usage patterns for code quality verification. This skill centralizes tool knowledge that was previously duplicated across agents. </purpose> <tools> <tool name="ESLint"> <description>JavaScript/TypeScript linter for code quality and style</description> <commands> <command name="check">eslint [files]</command> <command name="fix">eslint --fix [files]</command> <command name="format">eslint --format=json [files]</command> </commands> <use_case>Check code style, find potential bugs, enforce coding standards</use_case> <output> Error/warning count, file locations, rule violations </output> </tool> <tool name="Prettier"> <description>Code formatter for consistent style</description> <commands> <command name="check">prettier --check [files]</command> <command name="fix">prettier --write [files]</command> </commands> <use_case>Ensure consistent code formatting</use_case> <output> List of files that need formatting (check mode) </output> </tool> <tool name="TypeScript_Compiler"> <description>TypeScript type checker</description> <commands> <command name="check">tsc --noEmit</command> <command name="check_project">tsc -p tsconfig.json --noEmit</command> </commands> <use_case>Type checking, finding type errors</use_case> <output> Type errors with file:line locations </output> </tool> <tool name="Go_Tools"> <description>Go language quality tools</description> <commands> <command name="fmt">go fmt ./...</command> <command name="vet">go vet ./...</command> <command name="lint">golangci-lint run</command> </commands> <use_case>Go code formatting and static analysis</use_case> </tool> <tool name="Rust_Tools"> <description>Rust language quality tools</description> <commands> <command name="fmt">cargo fmt --check</command> <command name="clippy">cargo clippy</command> <command name="check">cargo check</command> </commands> <use_case>Rust code formatting and linting</use_case> </tool> <tool name="Nix_Tools"> <description>Nix language quality tools</description> <commands> <command name="fmt">nixfmt [files]</command> <command name="check">nix flake check</command> <command name="lint">statix check</command> </commands> <use_case>Nix code formatting and validation</use_case> </tool> <tool name="Python_Tools"> <description>Python language quality tools</description> <commands> <command name="fmt">black [files]</command> <command name="lint">ruff check [files]</command> <command name="type">mypy [files]</command> </commands> <use_case>Python code formatting, linting, and type checking</use_case> </tool> </tools> <patterns> <pattern name="quality_check_workflow"> <description>Standard workflow for quality verification</description> <example> 1. Run type checker (tsc, mypy, etc.) 2. Run linter (eslint, clippy, etc.) 3. Run formatter check (prettier, black, etc.) 4. Report findings with locations </example> </pattern> <pattern name="auto_fix_workflow"> <description>Workflow for automatic fixes</description> <example> 1. Run formatter (prettier --write, cargo fmt) 2. Run linter with fix (eslint --fix) 3. Verify with check commands 4. Run tests to confirm no regressions </example> </pattern> <pattern name="incremental_check"> <description>Check only changed files</description> <example> 1. Get list of changed files (git diff --name-only) 2. Filter by file type 3. Run quality tools on filtered list </example> </pattern> </patterns> <concepts> <concept name="lint_categories"> <description>Types of lint rules and their purposes</description> <example> Error prevention: Catch potential bugs Best practices: Enforce coding standards Style: Consistent formatting Security: Detect vulnerable patterns </example> </concept> <concept name="fix_safety"> <description>Which fixes are safe to auto-apply</description> <example> Safe: Formatting, import sorting, simple style fixes Review needed: Complex refactors, logic changes Manual only: Security issues, breaking changes </example> </concept> <concept name="exit_codes"> <description>Standard exit codes for quality tools</description> <example> 0: Success, no issues 1: Issues found 2: Configuration or execution error </example> </concept> </concepts>

<best_practices> <practice priority="critical">Run type checker before linter for faster feedback</practice> <practice priority="critical">Verify with tests after auto-fixes</practice> <practice priority="high">Use project-specific configuration when available</practice> <practice priority="high">Report all issues with file:line locations</practice> <practice priority="medium">Run incremental checks for large codebases</practice> <practice priority="medium">Separate formatting from logic changes in commits</practice> </best_practices>

<anti_patterns> <avoid name="blind_auto_fix"> <description>Auto-fixing without reviewing changes</description> <instead>Review auto-fix changes, run tests after</instead> </avoid>

<avoid name="ignoring_warnings"> <description>Only addressing errors, ignoring warnings</description> <instead>Address warnings that indicate potential issues</instead> </avoid> <avoid name="skipping_type_check"> <description>Running linter without type checking first</description> <instead>Run type checker first for faster feedback loop</instead> </avoid> </anti_patterns>

<decision_tree name="tool_selection"> <question>What type of quality check is needed?</question> <branch condition="Type errors">Use language-specific type checker (tsc, mypy, cargo check)</branch> <branch condition="Code style and bugs">Use linter (eslint, clippy, ruff)</branch> <branch condition="Formatting only">Use formatter (prettier, black, cargo fmt)</branch> <branch condition="All of the above">Run in sequence: types → lint → format</branch> </decision_tree>

<constraints> <must>Run quality checks before marking implementation complete</must> <must>Report findings with file:line locations</must> <must>Use project configuration when available</must> <avoid>Auto-fixing without test verification</avoid> <avoid>Ignoring type errors</avoid> <avoid>Running only subset of quality tools</avoid> </constraints>

<related_skills> <skill name="testing-patterns">Run tests after quality fixes</skill> <skill name="execution-workflow">Integration with implementation workflow</skill> </related_skills>