checking-changes
Validates all code changes before committing by running format, lint, type, and unit test checks. Use after making backend (Python) or frontend (TypeScript) changes, before committing or finishing a work session.
About this skill
The `checking-changes` skill streamlines your development workflow by automating crucial pre-commit validation steps. Designed for both backend (Python) and frontend (TypeScript) changes within the Streamlit project, this skill executes a comprehensive suite of checks including code formatting, linting, type verification, and unit tests on all uncommitted files (staged, unstaged, and untracked). It provides a clear workflow: run the `make check` command, identify and fix any reported errors, and repeat until all checks pass, ensuring high code quality and consistency before final commit or session completion.
Best use case
Ensuring code quality and consistency across a project by automatically validating changes against established standards (formatting, linting, typing, unit tests) before they are committed or a work session is finished.
Validates all code changes before committing by running format, lint, type, and unit test checks. Use after making backend (Python) or frontend (TypeScript) changes, before committing or finishing a work session.
All code changes pass format, lint, type, and unit tests, indicating that the code adheres to project quality standards and is ready for committing. The agent will confirm that 'make check' succeeded.
Practical example
Example input
Please check all my recent code changes for formatting, linting, type errors, and run unit tests. Let me know if everything passes.
Example output
Running 'make check' to validate uncommitted changes... Formatting checks passed. Linting checks passed. Type checks passed. Unit tests passed. All checks completed successfully. Your code changes meet the project's quality standards and are ready to be committed.
When to use this skill
- After completing a set of code changes (Python or TypeScript), before committing your work, or at the end of a development session to verify all modifications meet project standards.
When not to use this skill
- After every minor edit or small change; this skill is intended for validating a completed set of changes, not for real-time, granular feedback on individual keystrokes. It also does not include End-to-End (E2E) tests by default.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/checking-changes/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How checking-changes Compares
| Feature / Agent | checking-changes | Standard Approach |
|---|---|---|
| Platform Support | Claude | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | easy | N/A |
Frequently Asked Questions
What does this skill do?
Validates all code changes before committing by running format, lint, type, and unit test checks. Use after making backend (Python) or frontend (TypeScript) changes, before committing or finishing a work session.
Which AI agents support this skill?
This skill is designed for Claude.
How difficult is it to install?
The installation complexity is rated as easy. You can find the installation instructions above.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
Related Guides
AI Agents for Coding
Browse AI agent skills for coding, debugging, testing, refactoring, code review, and developer workflows across Claude, Cursor, and Codex.
Best AI Skills for Claude
Explore the best AI skills for Claude and Claude Code across coding, research, workflow automation, documentation, and agent operations.
ChatGPT vs Claude for Agent Skills
Compare ChatGPT and Claude for AI agent skills across coding, writing, research, and reusable workflow execution.
SKILL.md Source
# Checking Changes **Run at the end of a work session** or after completing a set of changes — not after every small edit. ```bash make check ``` This runs formatting, linting, type checking, and unit tests on all uncommitted files (staged, unstaged, and untracked). ## Workflow 1. Run `make check` 2. If issues are found: - Fix the reported errors - Re-run `make check` - Repeat until all checks pass 3. Only consider work complete when `make check` succeeds ## Notes - E2E tests are not included by default; use `E2E_CHECK=true make check` to also run changed e2e tests - E2E snapshot mismatches can be ignored (they require manual updates)
Related Skills
fixing-streamlit-ci
Analyze and fix failed GitHub Actions CI jobs for the current branch/PR. Use when CI checks fail, PR checks show failures, or you need to diagnose lint/type/test errors and verify fixes locally.
fixing-flaky-e2e-tests
Diagnose and fix flaky Playwright e2e tests. Use when tests fail intermittently, show timeout errors, have snapshot mismatches, or exhibit browser-specific failures.
finalizing-pr
Finalizes branch changes for merging by simplifying code, running checks, reviewing changes, and creating a PR if needed. Use when ready to merge changes into the target branch.
discovering-make-commands
Lists available make commands for Streamlit development. Use for build, test, lint, or format tasks.
debugging-streamlit
Debug Streamlit frontend and backend changes using make debug with hot-reload. Use when testing code changes, investigating bugs, checking UI behavior, or needing screenshots of the running app.
creating-pull-requests
Creates a draft pull request on GitHub with proper labels, branch naming, and description formatting. Use when changes are ready to be submitted as a PR to the streamlit/streamlit repository.
assessing-external-test-risk
Assesses whether branch or PR changes are high-risk for externally hosted or embedded Streamlit usage and recommends whether external e2e coverage with `@pytest.mark.external_test` is needed. Use during code review, PR triage, or test planning when changes touch routing, auth, websocket/session behavior, embedding, assets, cross-origin behavior, SiS/Snowflake runtime, storage, or security headers.
addressing-pr-review-comments
Address all valid review comments on a PR for the current branch in the streamlit/streamlit repo. Covers both inline review comments and general PR (issue) comments. Use when a PR has reviewer feedback to address, including code changes, style fixes, and documentation updates.
ui-demo
Record polished UI demo videos using Playwright. Use when the user asks to create a demo, walkthrough, screen recording, or tutorial video of a web application. Produces WebM videos with visible cursor, natural pacing, and professional feel.
microsoft-docs
Query official Microsoft documentation to find concepts, tutorials, and code examples across Azure, .NET, Agent Framework, Aspire, VS Code, GitHub, and more. Uses Microsoft Learn MCP as the default, with Context7 and Aspire MCP for content that lives outside learn.microsoft.com.
jupyter-notebook
Use when the user asks to create, scaffold, or edit Jupyter notebooks (`.ipynb`) for experiments, explorations, or tutorials; prefer the bundled templates and run the helper script `new_notebook.py` to generate a clean starting notebook.
n8n-expression-syntax
Validate n8n expression syntax and fix common errors. Use when writing n8n expressions, using {{}} syntax, accessing $json/$node variables, troubleshooting expression errors, or working with webhook data in workflows.