// This skill should be used when the user asks to 'commit', 'create a commit', or 'git commit'. It creates conventional commits with FQCN scopes for Ansible collection content (roles, modules, plugins).
| name | commit |
| description | This skill should be used when the user asks to 'commit', 'create a commit', or 'git commit'. It creates conventional commits with FQCN scopes for Ansible collection content (roles, modules, plugins). |
You are executing the commit skill. Follow these steps precisely.
Identify the model you are currently running as from your system context.
Format it as Assisted-by: <Model> <Version> — e.g. Assisted-by: Claude Sonnet 4.6, Assisted-by: GPT 5.3 Codex.
This trailer will be appended to every commit created in this session.
Follow the Conventional Commits 1.0.0 standard.
Infer a commit type based on either a changelog fragment for the changes if present or on the nature of the changes made.
If the type is ambiguous, use AskUserQuestion to ask:
"What type of change is this for <component>? (feat/fix/docs/chore/refactor/ci/deprecate/remove/breaking)"
Follow conventional commits format:
<type>(<component>): <imperative short description><type>: <imperative short description>Rules:
BREAKING CHANGE: <explanation> in the bodyAssisted-by: <AI tool/mode and its version> (from Step 1) at the end of every messageExamples:
feat: add support for custom agent port to postgresql_info module
Assisted-by: Claude Sonnet 4.6
feat!: drop support for ansible-core <= 2.16
BREAKING CHANGE: ansible-core 2.16 and earlier are no longer supported.
Assisted-by: Claude Sonnet 4.6
Use AskUserQuestion to present the proposed commit message and ask for approval:
"Proposed commit \n<message>\n\n\nApprove, or provide an edited message?"
If the user provides an edited message, use their version exactly.
Run git add <relevant files> and commit.
Guides the release of an Ansible collection following the upstream process (without release branches). Automatically determines the next version from changelog fragments. Outputs step-by-step instructions with commands for changelog generation, release PR, tagging, Galaxy publication, version bump, and GitHub release. Use when asked to release, publish, or tag a new collection version.
Reviews pull requests and code changes in the community.clickhouse Ansible collection against project standards and the Ansible Collection Review Checklist. Use when asked to review a PR, patch, diff, or set of code changes. Do not use for GitHub Issues or general Q&A.
Runs and writes tests (sanity, unit, integration) for the community.clickhouse Ansible collection using ansible-test. Use when asked to run, check, or write tests for a module or utility. Do not use for PR reviews or questions unrelated to testing.