Menu
Verify code changes by running the project's typecheck, build, lint, and targeted tests, then fix and re-run until clean. Use after editing any source file.
| name | verify-changes |
| description | Verify code changes by running the project's typecheck, build, lint, and targeted tests, then fix and re-run until clean. Use after editing any source file. |
Editing a file is only half a step. Always close the loop by verifying before you mark work done or open a PR. This is the manual equivalent of an IDE/LSP diagnostics loop.
package.json scripts (build, lint, typecheck), tsconfig.json -> npx tsc --noEmit, npx eslint <changed files>.ruff check <path>, mypy <path>, pytest <specific test file>.mvn -q -pl <module> compile, then the single relevant test class via -Dtest=<ClassName>../gradlew :<module>:compileJava / :<module>:test --tests <ClassName>.NO_COLOR=1, --no-color, or --no-colors.completed once its verification command passes.Use when the user asks for a summary, TL;DR, or condensed version of any content.
Four-layer skill composition, skill marketplaces, the self-learning loop
四层技能合成、技能市场、自学习闭环
Apply multi-file or tricky edits atomically with git apply instead of many fragile edit_file calls. Use when changing several files at once or when edit_file fails to match.
Search a codebase efficiently with ripgrep regular expressions, file globs, and git history search. Use to locate symbols, usages, and definitions instead of reading whole files.
Use git as a safety net - create a checkpoint commit before risky or large changes and roll back cleanly if a change makes things worse. Use before multi-file refactors.