القائمة
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).
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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.
Use this skill when you need to check backport and patchback workflow blockers for Ansible collection stable branches. Detects open backport PRs and patchback failures that must be resolved before creating a release prep PR. Complements version analysis skills by focusing on process blockers. By default, checks the two most recent stable branches.
Triage bug reports, CI failures, and GitHub issues across Ansible network collections (cisco.ios, cisco.iosxr, cisco.nxos, arista.eos, ansible.netcommon, ansible.utils, etc.). Two modes: scan mode for bulk weekly triage across all repos, and direct mode for deep triage of a single issue. Network-specific: uses cross-collection cascade detection for shared dependencies (netcommon, utils) and known network CI failure patterns. Outputs structured JSON and markdown. Use when asked to triage network issues, scan network issues, weekly triage, triage CI failure, or triage collection issue. Do not use for non-network collections or general Ansible questions.
Fetch Ansible documentation from docs.ansible.com as Markdown. Use when the user asks about an Ansible topic, references a docs.ansible.com URL, or when the agent needs to look up official Ansible documentation to complete a task or verify information.
Adds SonarCloud (SonarQube Cloud) static analysis to an Ansible collection repo: sonar-project.properties, GitHub Actions scanner workflow, XML coverage for Sonar, and contributor-facing docs; includes fork/secret and assistant-safe patterns (see Security section). Use when onboarding SonarCloud, wiring CI secrets, producing coverage.xml, or mirroring ansible-collections setups like amazon.aws.
Configures CI coverage reporting for SonarCloud on Ansible collections. Use this skill when Sonar already runs but coverage is missing and you need to wire XML reports, aggregator workflows, and scanner report paths.
| 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). |
| user-invocable | true |
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.