MCP-OpenProject/.claude/commands/speckit.commit.md

description
Commit staged and unstaged changes following Conventional Commits, splitting big changes into smaller logical commits.

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Outline

1. Resolve remote URL: Run git remote get-url origin to get the remote URL. All commit references produced by this skill MUST use the remote URL format (e.g., <remote-url>/commit/<hash>). Never output bare hashes without the full remote link.
2. Run git status to see all changed and untracked files.
3. Run git diff and git diff --staged to understand the changes.
4. Run git log --oneline -5 to see recent commit style.
5. Analyze and group changes into logical commits. Review all changed files and determine if they can be separated into smaller, focused commits. Group by:
   • Purpose: Bug fix vs feature vs docs vs config — never mix these in one commit.
   • Scope: Changes to different modules (frontend, backend, specs, config) should be separate commits unless they are tightly coupled and meaningless without each other.
   • Independence: If a subset of changes can stand on its own and still make sense, it should be its own commit.
   • Present the proposed commit grouping to the user for approval before proceeding.
6. For each logical group, stage only the relevant files using git add <file> (never use git add -A or git add .) and commit them individually.
7. Write a commit message following the Conventional Commits specification.
8. After each successful commit, report the commit hash as a full remote link: <remote-url>/commit/<hash> (using the URL resolved in step 1).

Commit Message Format

<type>(<scope>): <short summary>

<optional body>

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Types

• feat: A new feature
• fix: A bug fix
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting)
• refactor: A code change that neither fixes a bug nor adds a feature
• perf: A code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files. Claude config files can be categorized here. Example chore(claude)

Scope

Use the relevant module or area in parentheses:

• frontend — SvelteKit or other frontend changes
• backend — Spring Boot or other backend changes
• monitoring — Prometheus, or Grafana changes
• server — Docker, Docker Compose, Kubernetes changes
• Omit scope if the change spans multiple areas
• Append - with application name if available. Example backend-auth.

Rules

• The summary must be lowercase, imperative mood, no period at the end
• Keep the summary under 70 characters
• Use the body for additional context when the summary alone is not sufficient
• Always end with the Co-Authored-By trailer
• Use a HEREDOC to pass the commit message to git commit -m
• NEVER use --no-verify or skip pre-commit hooks
• NEVER amend a previous commit unless explicitly asked