con un clic
commit
Generate git commit messages from staged changes
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.
Menú
Generate git commit messages from staged changes
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
Use when adding or reviewing tests for Reborn behavior — choosing a test tier, covering a bug fix, testing model/tool-choice behavior, touching tests/integration or tests/fixtures/llm_traces, or when a test needs Postgres, Docker, or a live LLM.
Navigate building a user-facing feature in the Reborn stack (a capability that crosses product_workflow → composition → webui_v2 → runtime/serve → frontend). Use when planning or implementing any new Reborn settings page, endpoint, facade method, or runtime-backed capability — especially before writing code, to avoid rebuilding what already exists and to wire it in one pass instead of layer-by-layer.
Use when asked to "review the open PRs", review a batch or stack of pull requests, or run a recurring PR-review pass on a repo — especially with many PRs, stacked branches, conflicts, or security-sensitive changes. Covers grouping, fan-out to review subagents, verdict synthesis, and posting.
Generate or update the IronClaw architecture overview video using Remotion. Use when asked to update, regenerate, or modify the architecture video, add/remove scenes, or reflect codebase changes in the video.
Use when writing or reviewing a change in crates/ that adds a trait, a crate, a dependency edge, a re-export, or code in ironclaw_reborn_composition — or when deciding whether an abstraction, layer, or crate boundary is justified in the IronClaw Reborn stack.
Use when starting work in the IronClaw repo, deciding where a feature/fix/prompt/doc belongs, tracing how a request flows, looking up which crate owns a subsystem, or when repo docs, the knowledge graph, or component names seem stale, missing, or contradictory.
| name | commit |
| version | 1.0.0 |
| description | Generate git commit messages from staged changes |
| activation | {"keywords":["commit","git commit"],"patterns":["(?i)(create|make|write|generate)\\s.*commit","(?i)commit\\s.*(message|changes|staged)"],"tags":["git","version-control"],"max_context_tokens":1000} |
When the user asks to create a commit:
shell with git status to see what files are staged and unstaged.shell with git diff --cached to see the exact changes that will be committed.shell with git log --oneline -5 to understand the repo's commit message style..env, credentials.json, API keys). Warn the user if such files are staged.git commit.git add <specific files> (never use git add -A or git add .).If the repo doesn't have a clear style, use:
<type>: <concise description>
<optional body explaining why>
Where type is: fix, feat, refactor, test, docs, chore.