Command
ai-governance
Generate and enforce policy gates for AI coding agents (Copilot, Claude Code) — real-time session hooks that deny protected-path edits and dangerous commands,…
@nitinjain999View CommandDevelopment
Command
/commit
Analyze git diffs or staged changes and generate conventional commit messages that explain WHY a change was made. Supports auto-detecting type and scope, intelligent file staging, and interactive overrides. Use when asked to "write a commit message", "generate a commit",
Install
> /plugin marketplace add nitinjain999/platform-skills > /plugin install platform-skills@platform-skills
How it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/commit
Context preview
What this command does when you run it.
Analyze git diffs or staged changes and generate conventional commit messages that explain WHY a change was made. Supports auto-detecting type and scope, intelligent file staging, and interactive overrides. Use when asked to "write a commit message", "generate a commit",
Command definition
commit.mdname: commit
description: Analyze git diffs or staged changes and generate conventional commit messages that explain WHY a change was made. Supports auto-detecting type and scope, intelligent file staging, and interactive overrides. Use when asked to "write a commit message", "generate a commit", "describe my changes", "commit this", "summarize my diff", or "/commit".
argument-hint: "[analyze|generate|stage|validate] [optional: type/scope override or description]"
title: "Commit Command"
sidebar_label: "commit"
custom_edit_url: null
Analyze changes and generate a Conventional Commits message explaining the motivation behind the change.
Mode: analyze
Inspect staged or unstaged changes and classify the commit type and scope.
Steps: 1. Run `git diff --staged` — if empty, run `git diff HEAD` to capture unstaged changes 2. Group changed files by logical concern (feature, fix, refactor, docs, config, tests, ci) 3. Identify the type from the change pattern:
- `feat` — new capability or behavior added
- `fix` — corrects broken or incorrect behavior
- `refactor` — restructures code without changing behavior
- `perf` — measurably improves performance
- `test` — adds or corrects tests only
- `docs` — documentation only
- `chore` — build tooling, dependency updates, config changes with no production effect
- `ci` — changes to CI/CD pipelines or workflow files
- `revert` — reverting a prior commit
4. Infer scope from the most specific common ancestor: module name, service name, directory, or filename 5. Check for breaking changes: API removals, signature changes, config renames, behavior inversions — flag with `!` and add `BREAKING CHANGE:` footer 6. Report: detected type, scope, whether breaking, and a one-line WHY summary
Reference: `references/conventional-commits.md` → Type Classification, Scope Rules
Mode: generate
Generate a complete conventional commit message from diff or description.
Steps: 1. Run `analyze` mode first to determine type, scope, and breaking status 2. Write the subject line:
- Format: `<type>(<scope>): <imperative verb> <what and why>`
- Max 72 characters
- Imperative mood: "add", "fix", "remove", "update", "extract" — not "added", "fixes"
- Focus on the WHY, not just the what: "fix(auth): validate token expiry before redirect" not "fix(auth): update token check"
3. Write the body (when the subject line is insufficient):
- Wrap at 72 characters
- Explain the problem being solved and the approach chosen
- One blank line between subject and body
4. Write footers:
- `BREAKING CHANGE: <description>` for breaking changes (also add `!` to subject)
- `Fixes #<issue>` or `Closes #<issue>` for linked issues
- `Co-authored-by:` if applicable
5. Output the full message in a code block ready to copy
Message structure:
<type>(<scope>): <subject>
<body — optional, explains motivation and approach>
<footers — optional>
Reference: `references/conventional-commits.md` → Message Structure, Body and Footer Rules
Mode: stage
Intelligently stage files for a logical, atomic commit.
Steps: 1. Run `git status` to list all modified, added, and deleted files 2. Group files by logical change:
- Source files that implement a single feature or fix together
- Test files that cover those source changes
- Documentation that describes those changes
- Config or build changes that support those changes
3. Separate unrelated changes into distinct groups — each group should be a separate commit 4. If multiple logical groups exist: present the groupings and ask which to stage first 5. Stage the chosen group: `git add <files>` 6. Confirm staged set with `git diff --staged --stat` 7. Run `generate` mode to produce the commit message for the staged group
Reference: `references/conventional-commits.md` → Atomic Commits
Mode: validate
Validate an existing commit message against the Conventional Commits specification.
Steps: 1. Accept the message as input (or read from `git log -1 --format=%B`) 2. Check subject line:
- Has valid type from the allowed list
- Scope (if present) uses lowercase, no spaces
- `!` before `:` only when `BREAKING CHANGE` footer is also present
- Subject after `:` starts with lowercase, no period at end, ≤ 72 chars
3. Check body (if present):
- Separated from subject by exactly one blank line
- Lines wrap at 72 characters
4. Check footers (if present):
- `BREAKING CHANGE:` value is non-empty
- Issue references use correct format (`Fixes #N`, `Closes #N`)
5. Report: PASS or list of violations with the exact rule broken and the corrected line
Reference: `references/conventional-commits.md` → Validation Rules
Read more
name: commit description: Analyze git diffs or staged changes and generate conventional commit messages that explain WHY a change was made. Supports auto-detecting type and scope, intelligent file staging, and interactive overrides. Use when asked to "write a commit message", "generate a commit", "describe my changes", "commit this", "summarize my diff", or "/commit". argument-hint: "[analyze|generate|stage|validate] [optional: type/scope override or description]" title: "Commit Command" sidebar_label: "commit" custom_edit_url: null
Analyze changes and generate a Conventional Commits message explaining the motivation behind the change.
Mode: analyze
Inspect staged or unstaged changes and classify the commit type and scope.
Steps: 1. Run `git diff --staged` — if empty, run `git diff HEAD` to capture unstaged changes 2. Group changed files by logical concern (feature, fix, refactor, docs, config, tests, ci) 3. Identify the type from the change pattern:
- `feat` — new capability or behavior added
- `fix` — corrects broken or incorrect behavior
- `refactor` — restructures code without changing behavior
- `perf` — measurably improves performance
- `test` — adds or corrects tests only
- `docs` — documentation only
- `chore` — build tooling, dependency updates, config changes with no production effect
- `ci` — changes to CI/CD pipelines or workflow files
- `revert` — reverting a prior commit
4. Infer scope from the most specific common ancestor: module name, service name, directory, or filename 5. Check for breaking changes: API removals, signature changes, config renames, behavior inversions — flag with `!` and add `BREAKING CHANGE:` footer 6. Report: detected type, scope, whether breaking, and a one-line WHY summary
Reference: `references/conventional-commits.md` → Type Classification, Scope Rules
Mode: generate
Generate a complete conventional commit message from diff or description.
Steps: 1. Run `analyze` mode first to determine type, scope, and breaking status 2. Write the subject line:
- Format: `<type>(<scope>): <imperative verb> <what and why>`
- Max 72 characters
- Imperative mood: "add", "fix", "remove", "update", "extract" — not "added", "fixes"
- Focus on the WHY, not just the what: "fix(auth): validate token expiry before redirect" not "fix(auth): update token check"
3. Write the body (when the subject line is insufficient):
- Wrap at 72 characters
- Explain the problem being solved and the approach chosen
- One blank line between subject and body
4. Write footers:
- `BREAKING CHANGE: <description>` for breaking changes (also add `!` to subject)
- `Fixes #<issue>` or `Closes #<issue>` for linked issues
- `Co-authored-by:` if applicable
5. Output the full message in a code block ready to copy
Message structure:
<type>(<scope>): <subject> <body — optional, explains motivation and approach> <footers — optional>
Reference: `references/conventional-commits.md` → Message Structure, Body and Footer Rules
Mode: stage
Intelligently stage files for a logical, atomic commit.
Steps: 1. Run `git status` to list all modified, added, and deleted files 2. Group files by logical change:
- Source files that implement a single feature or fix together
- Test files that cover those source changes
- Documentation that describes those changes
- Config or build changes that support those changes
3. Separate unrelated changes into distinct groups — each group should be a separate commit 4. If multiple logical groups exist: present the groupings and ask which to stage first 5. Stage the chosen group: `git add <files>` 6. Confirm staged set with `git diff --staged --stat` 7. Run `generate` mode to produce the commit message for the staged group
Reference: `references/conventional-commits.md` → Atomic Commits
Mode: validate
Validate an existing commit message against the Conventional Commits specification.
Steps: 1. Accept the message as input (or read from `git log -1 --format=%B`) 2. Check subject line:
- Has valid type from the allowed list
- Scope (if present) uses lowercase, no spaces
- `!` before `:` only when `BREAKING CHANGE` footer is also present
- Subject after `:` starts with lowercase, no period at end, ≤ 72 chars
3. Check body (if present):
- Separated from subject by exactly one blank line
- Lines wrap at 72 characters
4. Check footers (if present):
- `BREAKING CHANGE:` value is non-empty
- Issue references use correct format (`Fixes #N`, `Closes #N`)
5. Report: PASS or list of violations with the exact rule broken and the corrected line
Reference: `references/conventional-commits.md` → Validation Rules
Ships withplatform-skills
A production-grade field handbook for platform, DevOps, SRE, and cloud engineers covering Kubernetes, Flux CD, Terraform, GitHub Actions, AWS, OPA/Rego, KEDA, Karpenter, supply chain security, Falco, observability, and more.
Get the whole plugin
Stats
42
Stars
10
Forks
Active
Maintenance
Shell
Language
Apache-2.0
License
3d ago
Last commit
5mo ago
Created
Repo: nitinjain999/platform-skills
Other commands on platform-skills.
@nitinjain999View CommandCommand
awesome-docs
Generate, convert, and maintain animated GitHub-safe Markdown documents with animated SVG diagrams. Covers four SVG patterns (architecture flow, lifecycle…
@nitinjain999View CommandCommand
aws-profile
AWS profile management for MCP servers — discover profiles across SSO, Granted, and assumed-role chains, check credential TTL, switch profiles across VS Code…
@nitinjain999View CommandCommand
aws
Structured guidance for AWS CloudFront distributions, WAF web ACLs, Lambda@Edge, CloudFront Functions, Firewall Manager multi-account enforcement, and IAM/IRSA…
@nitinjain999View CommandCommand
azure
Azure identity (Workload Identity, OIDC, Entra ID), resource tagging, AKS platform patterns, RBAC scoping, and production-readiness review — with Terraform…
@nitinjain999View CommandCommand
chaos
Design, run, and debug Chaos Engineering experiments on Kubernetes using Litmus Chaos v3 and Chaos Mesh v2. Covers fault injection (pod-delete, network-loss,…
@nitinjain999View Command