跳到正文
cccskills
免费在 GitHub 公开

ce-commit

Save working changes as local Git commits with messages that explain the outcome. Follow the project's commit style, select files explicitly, and split clearly separate changes into a few logical commits when appropriate.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

Create a git commit with a clear, value-communicating message. Use when the user asks to commit/save staged or unstaged changes with a repo-appropriate message.

查看安装方法

适用场景

  • Saving completed work as a local commit
  • Writing messages that explain the outcome
  • Separating unrelated changes into commits
  • Committing selected files while excluding others

包含的文件(1)

  • SKILL.md4.7 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Git Commit

Create well-crafted local commit(s) from the current working tree. No push, no PR — use ce-commit-push-pr for the full ship flow.

Done when: each logical change is committed with an explicit file list and a message that states the outcome, and git status is clean of those changes. Stop when: the tree is clean (nothing to commit).

Context

Gather context with each command as its own shell tool call (program + args only). Do not join with ;, &&, ||, pipes, $(...), or redirects — that syntax fails under Windows PowerShell. A non-zero exit is a normal state to interpret, not a failure to suppress.

CommandPurposeNon-zero / empty means
git statusWorking-tree stateNot a git repo — stop
git diff HEADUncommitted changesUnborn repo / no commits yet
git branch --show-currentCurrent branchEmpty = detached HEAD
git log --oneline -10Recent message styleUnborn repo — no history
git rev-parse --abbrev-ref origin/HEADRemote default branchNo origin/HEAD / bare HEAD — try gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name', else main

Treat this as a snapshot. Re-read branch and staged set immediately before committing if anything may have changed.

Default branch name: strip a leading origin/ from origin/HEAD (so origin/trunk → trunk). Use that bare name for all “on the default branch?” checks — never compare against origin/<name>.

Workflow

  1. Gather — run every Context command above (own shell call each), then continue.

  2. Nothing to commit — if git status shows no staged, modified, or untracked files, report that and stop. Do not use git diff HEAD alone as cleanliness (it misses untracked files).

  3. Branch first — if detached HEAD, or on the default branch (main / master / the bare default name above), create a feature branch from the change content (git checkout -b <name>), then re-read git branch --show-current. Do not ask — commit-only still must not leave work only on a detached HEAD or the default branch. If the derived name exists, pick a non-conflicting suffix.

  4. Convention — match project commit conventions already in context; else match the recent log pattern; else conventional commits (type(scope): description). When using conventional commits and fix/feat both fit, default to fix: (remedying broken or missing behavior); reserve feat: for new capabilities. User override wins.

  5. Logical commits — if changed files clearly split into distinct concerns, make separate commits (file level only, 2–3 max, no git add -p). If ambiguous, one commit.

  6. Message — subject is imperative and names the outcome (what is now possible or fixed), not the file list. Body only when motivation or trade-offs are not obvious from the subject. When a plan Implementation Unit ID is already in hand for this commit (conversation, caller, or the files belong to one unit), append that unit's U-ID in parentheses — (U3) means unit 3. Do not hunt for a plan. Omit when the commit spans units, the unit is unclear, or no plan is in hand.

    • Bad: Update checkout.rb / Add tests and fix stuff
    • Good: Fix double-submit on checkout
    • Good: Add per-subscription mute (U3)
  7. Stage and commit — stage named files only (never git add -A or git add .). Honor exclude:<paths> when the invocation carries it: those files stay uncommitted no matter what else changed; say in the report that they were left out. Write the full message — subject line, blank line, optional body — to a file outside the repo with your file-write tool, then stage and commit as two calls per commit group:

git add file1 file2 file3
git commit -F <message-file> -- file1 file2 file3

No shell parses the message with -F: a $, quotes, backticks, or a multi-line body pass through literally under any shell, with no quoting rules to satisfy. Git's normal whitespace cleanup still applies (trailing spaces trimmed, blank-line runs collapsed), which is fine for a commit message.

The trailing path list on git commit is required: a bare git commit takes the whole index, so anything already staged before this run (a caller's exclude: paths, or work the user staged and did not name) would ride into the commit. Naming the paths commits exactly the group and leaves other index entries alone.

  1. Confirm — git status; report hash(es) and subject(s).

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Monitor an open GitHub pull request over time, respond to review feedback, and address automated check failures. Apply and push fixes, then report whether it appears ready to merge or what still blocks progress.

中文简介正在准备中。当前显示英语简介。

  • Monitoring a pull request until it appears ready to merge
  • Addressing review feedback as it arrives
  • Handling automated check failures during review
EveryInc/compound-engineering-plugin2.6万2026年10月17日 更新

Develop independent solutions to a defined problem, compare them against shared requirements, and combine useful contributions into a coherent recommendation. An independent assessment and evidence checks support the selection, while unresolved tradeoffs and verification needs remain explicit.

中文简介正在准备中。当前显示英语简介。

  • Comparing concrete solutions to a defined problem
  • Developing rough options before choosing an approach
  • Comparing architectural or product proposals
EveryInc/compound-engineering-plugin2.6万2026年10月17日 更新

Turn a vague feature idea into clear requirements through dialogue. Define what to build, its scope, and success criteria, then capture the result in a short chat summary or a requirements document ready for implementation planning.

中文简介正在准备中。当前显示英语简介。

  • Clarifying a vague feature idea
  • Narrowing the scope of an ambitious improvement
  • Documenting requirements before implementation planning
EveryInc/compound-engineering-plugin2.6万2026年10月17日 更新

Review code changes or a pull request for bugs, effects on existing behavior, test gaps, and project standards. Receive findings supported by the code and a clear account of review coverage, with local fixes available when explicitly requested.

中文简介正在准备中。当前显示英语简介。

  • Reviewing a pull request before release
  • Checking changes for bugs and test gaps
  • Applying review findings locally
EveryInc/compound-engineering-plugin2.6万2026年10月17日 更新

Commit and push code changes, then open a pull request with a clear title and description. You can also draft or update PR descriptions and hand published requests to the follow-up monitoring workflow.

中文简介正在准备中。当前显示英语简介。

  • Committing changes and opening a pull request
  • Drafting only a PR title and description
  • Updating an existing PR description
EveryInc/compound-engineering-plugin2.6万2026年10月17日 更新

Document a solved and verified problem when its reasoning is missing from code, tests, and existing documentation. Save one durable lesson in the repository so future agents can find it and avoid repeating substantial investigation.

中文简介正在准备中。当前显示英语简介。

  • Recording reasoning behind a verified fix
  • Preserving lessons to prevent recurring mistakes
  • Updating a lesson that has become inaccurate
EveryInc/compound-engineering-plugin2.6万2026年10月17日 更新

查看 EveryInc 的全部技能

报告此技能的问题