Smart commit
Setup público e sanitizado de um Claude Code full-stack: 8 sub-agents com roteamento por modelo, 792 skills, hooks de segurança, MCP servers e metodologia opinativa. Desenhado para um agente de IA se auto-configurar.
npx -y skills add henriquescastilho/my-claude --skill smart-commitAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Run quality gates, review staged changes for issues, and create a well-crafted conventional commit. Use when saying "commit", "git commit", "save my changes", or ready to commit after making changes.
SKILL.md
1.8 KB, 390 tokens by cl100k_base, as published. Nobody here has run it
Smart Commit
Trigger
Use when saying "commit", "save changes", or ready to commit after making changes.
Workflow
- Check current state and identify what to commit.
- Run quality gates (lint, typecheck, tests on affected files).
- Scan staged changes for issues.
- Draft a conventional commit message from the diff.
- Stage specific files, create the commit.
- Prompt for learnings from this change.
Commands
git status
git diff --stat
npm run lint 2>&1 | tail -5
npm run typecheck 2>&1 | tail -5
npm test -- --changed --passWithNoTests 2>&1 | tail -10
git add <specific files>
git commit -m "<type>(<scope>): <summary>"
Code Review Scan
Before committing, check staged changes for:
console.log/debuggerstatements- TODO/FIXME/HACK comments without ticket references
- Hardcoded secrets or API keys
- Leftover test-only code
Flag any issues before proceeding.
Commit Message Format
<type>(<scope>): <short summary>
<body - what changed and why>
Types: feat, fix, refactor, test, docs, chore, perf, ci, style
Guardrails
- Never skip quality gates unless user explicitly says to.
- Stage specific files by name. Never
git add -Aorgit add .. - Summary under 72 characters. Body explains why, not what.
- No generic messages ("fix bug", "update code").
- Reference issue numbers when applicable.
Output
- Quality gate results (pass/fail)
- Issues found in staged changes
- Suggested commit message
- Commit hash after committing
- Prompt: any learnings to capture?