Stats
Actions
Tags
From vgv-wingspan
Creates conventional commit messages for staged git changes following the Conventional Commits spec and VGV workflow. Stages unstaged files interactively when needed.
How this skill is triggered — by the user, by Claude, or both
Slash command
/vgv-wingspan:create-commit [optional: single-commit | ticket/issue number e.g. VGV-123]When to use
Use when user says "commit this", "create a commit", "write a commit message", or "commit my changes".
[optional: single-commit | ticket/issue number e.g. VGV-123]This skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Produce a clean, conventional commit message for staged changes and commit them.
Produce a clean, conventional commit message for staged changes and commit them.
.env, *.key, *.pem, *secret*, *credential*, *.p12, *.jks.docs/plan/ and extract the type (feat, fix, refactor, etc.) from the plan title or metadata. If no plan is found, infer from the diff.Use this skill when:
$ARGUMENTS
This may include single-commit, a ticket number (e.g. VGV-123), a short description, or be empty.
Check whether the argument contains single-commit. Store as SINGLE_COMMIT (boolean).
Extract the ticket number or short description from the remaining argument text (if any).
Run these commands in parallel:
git diff --cached
git diff
git log main..HEAD --oneline
git branch --show-current
Check git diff and git status --short for unstaged modifications, deletions, and untracked files.
If there are unstaged or untracked changes, use AskUserQuestion to present them grouped by type (modified, deleted, untracked) and ask which to stage:
git add -A)Stage the confirmed files, then continue to Step 2.
If there are no changes at all, inform the user and stop.
Follow Conventional Commits. Consult references/conventional-commits.md for the full spec.
Extract the ticket number from the branch name (e.g. feat/VGV-59-... → VGV-59) or from the argument passed to the skill.
SINGLE_COMMIT is trueAlways produce a single commit covering all staged changes.
If the diff contains changes that are clearly independent (i.e., each could be reverted without affecting the other), note this and suggest the user consider splitting the work into multiple PRs rather than multiple commits.
SINGLE_COMMIT is falseDefault to a single commit. Propose multiple commits only when changes are clearly independent — i.e., each could be reverted without affecting the other:
feat and an unrelated choreDo not split just because multiple files or packages are touched — cohesive changes belong in one commit.
Output the proposed commit(s):
## Proposed commit(s)
### Commit 1
```
type(scope): subject line
Optional body explaining the why.
Refs: TICKET-000
```
### Commit 2 (if applicable)
```
type(scope): subject line
```
Use the AskUserQuestion tool to ask:
Question: "Do you want me to create this commit?"
Options:
Create each commit with HEREDOC to preserve formatting:
git commit -m "$(cat <<'EOF'
type(scope): subject line
Optional body.
Refs: TICKET-000
EOF
)"
After each commit, show git log --oneline -1.
npx claudepluginhub verygoodopensource/very-good-claude-code-marketplace --plugin vgv-wingspanDrafts Conventional Commits messages for staged git changes. Proposes a type-scoped subject line, waits for user approval, then commits.
Stages files safely avoiding sensitive ones, infers conventional commit type from git diff, drafts message with scope, and executes after confirmation. Use anytime like post-planning or mid-TDD.
Stages intended git changes avoiding secrets and creates clear Conventional Commits like feat(scope): subject. Useful for clean, semantic commit history.