commit-changes
Stage, commit, and amend changes with conventional commit messages. Covers reviewing changes, selective staging, writing descriptive commit messages using HEREDOC format, and verifying commit history. Use when saving a logical unit of work to version control, creating a commit with a conventional message, amending the most recent commit, or reviewing staged changes before committing.
Best use case
commit-changes is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Stage, commit, and amend changes with conventional commit messages. Covers reviewing changes, selective staging, writing descriptive commit messages using HEREDOC format, and verifying commit history. Use when saving a logical unit of work to version control, creating a commit with a conventional message, amending the most recent commit, or reviewing staged changes before committing.
Teams using commit-changes should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/commit-changes/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How commit-changes Compares
| Feature / Agent | commit-changes | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Stage, commit, and amend changes with conventional commit messages. Covers reviewing changes, selective staging, writing descriptive commit messages using HEREDOC format, and verifying commit history. Use when saving a logical unit of work to version control, creating a commit with a conventional message, amending the most recent commit, or reviewing staged changes before committing.
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.
SKILL.md Source
# Commit Changes Stage files selectively, write clear commit messages, and verify commit history. ## When to Use - Saving a logical unit of work to version control - Creating a commit with a descriptive, conventional message - Amending the most recent commit (message or content) - Reviewing what will be committed before committing ## Inputs - **Required**: One or more changed files to commit - **Optional**: Commit message (will be drafted if not provided) - **Optional**: Whether to amend the previous commit - **Optional**: Co-author attribution ## Procedure ### Step 1: Review Current Changes Check working tree status and inspect diffs: ```bash # See which files are modified, staged, or untracked git status # See unstaged changes git diff # See staged changes git diff --staged ``` **Got:** A clear picture of all modified, staged, and untracked files. **If fail:** If `git status` fails, verify you are inside a git repository (`git rev-parse --is-inside-work-tree`). ### Step 2: Stage Files Selectively Stage specific files rather than using `git add .` or `git add -A` to avoid accidentally including sensitive files or unrelated changes: ```bash # Stage specific files by name git add src/feature.R tests/test-feature.R # Stage all changes in a specific directory git add src/ # Stage parts of a file interactively (not supported in non-interactive contexts) # git add -p filename ``` Review what is staged before committing: ```bash git diff --staged ``` **Got:** Only the intended files and changes are staged. No `.env`, credentials, or large binaries. **If fail:** Unstage accidentally added files with `git reset HEAD <file>`. If sensitive data was staged, unstage before committing. ### Step 3: Write a Commit Message Use conventional commits format. Always pass the message via HEREDOC for proper formatting: ```bash git commit -m "$(cat <<'EOF' feat: add weighted mean calculation Implements weighted_mean() with support for NA handling and zero-weight filtering. Includes input validation for mismatched vector lengths. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> EOF )" ``` Conventional commit types: | Type | When to use | |------|-------------| | `feat` | New feature | | `fix` | Bug fix | | `docs` | Documentation only | | `test` | Adding or updating tests | | `refactor` | Code change that neither fixes nor adds | | `chore` | Build, CI, dependency updates | | `style` | Formatting, whitespace (no logic change) | **Got:** Commit created with a descriptive message that explains *why*, not *what*. **If fail:** If a pre-commit hook fails, fix the issue, re-stage with `git add`, and create a **new** commit (do not use `--amend` since the failed commit was never created). ### Step 4: Amend the Last Commit (Optional) Only amend if the commit has **not** been pushed to a shared remote: ```bash # Amend message only git commit --amend -m "$(cat <<'EOF' fix: correct weighted mean edge case for empty vectors EOF )" # Amend with additional staged changes git add forgotten-file.R git commit --amend --no-edit ``` **Got:** The previous commit is updated in-place. `git log -1` shows the amended content. **If fail:** If the commit was already pushed, do not amend. Create a new commit instead. Force-pushing amended commits to shared branches causes history divergence. ### Step 5: Verify the Commit ```bash # View the last commit git log -1 --stat # View recent commit history git log --oneline -5 # Verify the commit content git show HEAD ``` **Got:** The commit appears in history with the correct message, author, and file changes. **If fail:** If the commit contains wrong files, use `git reset --soft HEAD~1` to undo the commit while keeping changes staged, then re-commit correctly. ## Validation - [ ] Only intended files are included in the commit - [ ] No sensitive data (tokens, passwords, `.env` files) committed - [ ] Commit message follows conventional commits format - [ ] Message body explains *why* the change was made - [ ] `git log` shows the commit with correct metadata - [ ] Pre-commit hooks (if any) passed ## Pitfalls - **Committing too much at once**: Each commit should represent one logical change. Split unrelated changes into separate commits. - **Using `git add .` blindly**: Always review `git status` first. Prefer staging specific files by name. - **Amending pushed commits**: Never amend commits that have been pushed to a shared branch. This rewrites history and causes problems for collaborators. - **Vague commit messages**: "fix bug" or "update" tells nothing. Describe what changed and why. - **Forgetting `--no-edit` on content amends**: When adding forgotten files to the last commit, use `--no-edit` to keep the existing message. - **Hook failure leading to `--amend`**: When a pre-commit hook fails, the commit was never created. Using `--amend` would modify the *previous* commit. Always create a new commit after fixing hook issues. ## Related Skills - `manage-git-branches` - branch workflow before committing - `create-pull-request` - next step after committing - `resolve-git-conflicts` - handling conflicts during merge/rebase - `configure-git-repository` - repository setup and conventions
Related Skills
skill-name-here
One to three sentences describing what this skill accomplishes, followed by key activation triggers. This field is the primary mechanism agents use to decide whether to activate the skill — it is read during discovery before the full body is loaded. Start with a verb. Include the most important "when to use" conditions inline. Max 1024 characters.
write-vignette
Create R package vignettes using R Markdown or Quarto. Covers vignette setup, YAML configuration, code chunk options, building and testing, and CRAN requirements for vignettes. Use when adding a Getting Started tutorial, documenting complex workflows spanning multiple functions, creating domain-specific guides, or when CRAN submission requires user-facing documentation beyond function help pages.
write-validation-documentation
Write IQ/OQ/PQ validation documentation for computerized systems in regulated environments. Covers protocols, reports, test scripts, deviation handling, and approval workflows. Use when validating R or other software for regulated use, preparing for a regulatory audit, documenting qualification of computing environments, or creating and updating validation protocols and reports for new or re-qualified systems.
write-testthat-tests
Write comprehensive testthat (edition 3) tests for R package functions. Covers test organization, expectations, fixtures, mocking, snapshot tests, parameterized tests, and achieving high coverage. Use when adding tests for new package functions, increasing test coverage for existing code, writing regression tests for bug fixes, or setting up test infrastructure for a package that lacks it.
write-standard-operating-procedure
Write a GxP-compliant Standard Operating Procedure (SOP). Covers regulatory SOP template structure (purpose, scope, definitions, responsibilities, procedure, references, revision history), approval workflow design, periodic review scheduling, and operational procedures for system use. Use when a new validated system requires operational procedures, when existing informal procedures need formalisation, when an audit finding cites missing procedures, when a change control triggers SOP updates, or when periodic review identifies outdated procedural content.
write-roxygen-docs
Write roxygen2 documentation for R package functions, datasets, and classes. Covers all standard tags, cross-references, examples, and generating NAMESPACE entries. Follows tidyverse documentation style. Use when adding documentation to new exported functions, documenting internal helpers or datasets, documenting S3/S4/R6 classes and methods, or fixing documentation-related R CMD check notes.
write-incident-runbook
Create structured incident runbooks with diagnostic steps, resolution procedures, escalation paths, and communication templates for effective incident response. Use when documenting response procedures for recurring alerts, standardizing incident response across an on-call rotation, reducing MTTR with clear diagnostic steps, creating training materials for new team members, or linking alert annotations directly to resolution procedures.
write-helm-chart
Create production-ready Helm charts for Kubernetes application deployment with templating, values management, chart dependencies, hooks, and testing. Covers chart structure, Go template syntax, values.yaml design, chart repositories, versioning, and best practices for maintainable and reusable charts. Use when packaging a Kubernetes application for repeatable deployments, parameterizing manifests for multiple environments, managing complex multi-component applications with dependencies, or standardizing deployment practices with versioned rollback capability across teams.
write-continue-here
Write a CONTINUE_HERE.md file capturing current session state so a fresh Claude Code session can pick up where this one left off. Covers assessing recent work, structuring the continuation file with objective, completed, in-progress, next-steps, and context sections, and verifying the file is actionable. Use when ending a session with unfinished work, handing off context between sessions, or preserving task state that git alone cannot capture.
write-claude-md
Create an effective CLAUDE.md file that provides project-specific instructions to AI coding assistants. Covers structure, common sections, do/don't patterns, and integration with MCP servers and agent definitions. Use when starting a new project where AI assistants will be used, improving AI behavior on an existing project, documenting project conventions and constraints, or integrating MCP servers or agent definitions into a project workflow.
vishnu-bhaga
Preservation and sustenance — maintaining working state under perturbation, memory anchoring, consistency enforcement, and protective stabilization. Maps Vishnu's sustaining presence to AI reasoning: holding what works steady, anchoring verified knowledge against drift, and ensuring continuity through change. Use when a working approach is at risk from scope creep, when context drift threatens verified knowledge, after shiva-bhaga dissolution to protect what survived, when a long session risks losing earlier decisions through context compression, or before making changes to a currently functioning system.
version-ml-data
Version machine learning datasets using DVC (Data Version Control) with remote storage backends, build reproducible data pipelines with dependency tracking, integrate with Git workflows, and ensure data lineage for model reproducibility. Use when versioning large datasets that do not fit in Git, tracking data changes alongside code changes, ensuring ML experiment reproducibility, sharing datasets across team members, or auditing data lineage for compliance requirements.