Menú
Create well-structured git commits from analyzed changes. Use when the user asks to commit, save work, or create a 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
Write, refactor, restructure, edit, or audit technical documentation using the Diátaxis framework (tutorials, how-to guides, reference, explanation). Produces clear, concise, scannable docs and fights the default tendency toward bloated, over-explained AI prose. Use this skill for ANY documentation work — README and CONTRIBUTING files, API/reference docs, runbooks, guides, getting-started pages, conceptual write-ups, docs-site content, or doc reviews — even when the user just says "document this," "write docs for X," "clean up these docs," "explain how this works in the docs," or "what's missing from our documentation." If the deliverable is documentation, reach for this skill rather than writing prose freehand.
Retroactively create Linear tickets and PRs from untracked commits. Use for commits without tickets, "founder mode", or formalizing experimental work.
Find architectural friction and propose deep-module refactors as RFC issues. Use to improve architecture, find refactoring opportunities, or deepen shallow modules.
Initialize the AI Engineering Harness (AGENTS.md + thoughts/ structure). Use on /init_harness or when setting up the harness in a repo.
Interview the user relentlessly to stress-test a plan or design. Use to validate design decisions, "drill in", or "ask me questions" before implementation.
Observability Driven Development (ODD) — design the trace before the feature. Use for "ODD", "instrument first", "telemetry-driven", or a local OTel feedback loop with the Aspire dashboard.
| name | git-commit-helper |
| description | Create well-structured git commits from analyzed changes. Use when the user asks to commit, save work, or create a commit. |
| allowed-tools | Read, Bash, Grep, Glob |
Run in parallel to understand the changes:
git status # changed files
git diff # unstaged modifications
git diff --staged # staged changes
git log --oneline -n 5 # recent commit style
Show the user before executing, then wait for confirmation:
I plan to create [N] commit(s) with these changes:
Commit 1:
Files: [specific files]
Message: [proposed message in imperative mood]
[Commit 2, 3, ... if multiple]
Shall I proceed?
# Add files explicitly by path — NEVER use `git add -A`, `git add .`, or `git commit -a`
git add path/to/file1.ts path/to/file2.ts
git commit -m "Add social login support"
git log --oneline -n [number of commits created]
Format: [Imperative verb] [what] [optional: why] with an optional detailed body.
Add user authentication to API endpoints, Fix race condition in event processingUpdated stuff, Fixed bug, Changes, WIPUse imperative mood ("Add", not "Added"/"Adding"). When the "what" isn't obvious from the diff, explain the "why" — e.g. Use Redis for rate limiting to support distributed deployment.
Multi-change example:
git add src/feature.ts src/feature.test.ts docs/feature.md
git commit -m "Add user analytics feature
- Implement tracking service
- Add unit tests
- Update documentation"
NEVER add co-author info, Co-Authored-By lines, or "Generated with Claude"-style messages. Write commit messages as if the user wrote them — authored solely by the user with no AI attribution.
You have full context of this session — use it to write meaningful messages. The user asked you to commit, so trust your judgment and don't ask unnecessary questions.
git status clean): tell the user there is nothing to commit.This skill does not push. It creates clean, atomic commits with the user's approval, and all git operations are shown transparently.