Menú
"Create conventional commits. Use when: committing staged changes. Triggers on: '/commit', 'conventional commit'."
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | commit |
| description | "Create conventional commits. Use when: committing staged changes. Triggers on: '/commit', 'conventional commit'." |
I'll help you create a commit following the Conventional Commits 1.0.0 specification.
!git status --short
!git diff --cached --stat
Based on the changes, I'll create a commit message following this structure:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
IMPORTANT: This command will NEVER execute git add. It only creates commits from already staged changes.
Based on the staged changes and any specific requirements in "$ARGUMENTS", I'll:
Then execute the commit with:
git commit -m "$(cat <<'EOF'
[generated commit message here]
EOF
)"
Important: The commit message will be clean and professional, containing:
The commit will follow all Conventional Commits 1.0.0 rules:
Create git branches named by conventional-commit type: <type>/<kebab-description>. Use when: creating any new git branch, starting work that needs a branch, or naming a branch. Triggers on: 'create branch', 'new branch', 'branch off', 'checkout -b', '/branch'.
Code quality standards. Defines complexity management, modular design, code smell detection, comment standards. Applied automatically when writing or reviewing code. Invoke directly to clean up comments in a file. Triggers on: 'clean up comments', 'comment cleanup', '/code-quality'.
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Self-review of code changes (branch diff, staged, or uncommitted). Use when: reviewing code before pushing, checking diff quality, self-reviewing a PR, creating a PR (always use --peer), reviewing uncommitted work. Triggers on: '/self-review', 'review my changes', 'review this branch', 'self-review', 'pre-push review', 'review uncommitted', 'review staged', 'create PR', 'open PR', 'submit PR'.