From vgv-wingspan
Proposes and creates conventional commit messages for staged Git changes. Handles staging unstaged files if needed, infers types from plans or diffs, follows Conventional Commits spec and VGV workflow.
npx claudepluginhub verygoodopensource/very_good_claude_code_marketplace --plugin vgv-wingspanThis skill is limited to using the following tools:
Produce a clean, conventional commit message for staged changes and commit them.
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.
Generates conventional commit messages from staged Git changes by reviewing diffs, categorizing as feat/fix/refactor/docs/test/chore, and formatting as type(scope): description. Use before committing.
Stages all changes, analyzes git diff to generate conventional commit message (feat, fix, etc.), and creates commit. Handles pre-commit hooks. Use when user says commit changes or save changes.
Share bugs, ideas, or general feedback.
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.