Agent Skills
› codeaholicguy/ai-devkit
› dev-commit
dev-commit
GitHub专为AI编程代理设计的安全Git工作流。通过精确识别变更范围、执行验证并仅暂存相关文件,确保生成符合Conventional Commits规范的原子化提交,避免混入无关代码或敏感信息。
Trigger Scenarios
用户要求提交代码
准备提交内容
暂存更改
创建PR就绪的检查点
使用规范提交完成工作
Install
npx skills add codeaholicguy/ai-devkit --skill dev-commit -g -y
SKILL.md
Frontmatter
{
"name": "dev-commit",
"description": "AI DevKit · Safe git commit workflow for AI coding agents. Use when the user asks to commit, prepare a commit, stage changes, create a PR-ready checkpoint, or finish work with a conventional commit while avoiding unrelated user changes."
}
Dev Commit
Make one intentional, verified commit without sweeping in unrelated work.
Commit Contract
- Check repository state with
git status --short --branch,git diff --stat, andgit diff. - Identify the files that belong to the requested change. Treat pre-existing user edits, local config, generated artifacts, dependency caches, build outputs, and unrelated formatting churn as out of scope unless the user explicitly includes them.
- Run appropriate validation before committing. Prefer the repo's targeted tests, lint, typecheck, build, or documented verification commands. Record skipped validation with the reason.
- Stage only intended paths. Prefer explicit pathspecs such as
git add path/to/fileovergit add .. - Re-check with
git diff --cached --stat,git diff --cached, andgit status --short. - Write a concise conventional commit message:
<type>(optional-scope): <summary>. - Commit, then report the commit SHA, final status, validation commands, and any unstaged/untracked files left behind.
Guardrails
- Do not commit secrets, credentials,
.envfiles, local machine config, caches, coverage, logs, screenshots, or generated files unless the change explicitly requires them. - Do not stage another person's unrelated edits. If intended and unrelated changes are mixed in one file, use an interactive or patch-based staging flow and review the staged diff carefully.
- Do not amend, rebase, force-push, reset, or delete branches unless the user explicitly asks for that operation.
- If validation fails, stop before committing unless the user explicitly instructs you to commit with failing validation. Report the failing command and key output.
- If the repo has commit hooks, let them run. If a hook changes files, inspect and stage only intended hook outputs before retrying.
Message Style
Use semantic or conventional commit types that match the change:
feat: user-facing feature or capabilityfix: bug fixdocs: documentation-only changetest: test-only changerefactor: behavior-preserving code restructuringchore: maintenance, build, tooling, metadata, or generated index updates
Keep the subject under about 72 characters when practical, imperative, and specific. Add a body only when it explains non-obvious validation, risk, migration, or follow-up context.
Version History
- d4caf56 Current 2026-07-05 15:22


