jiantw83
4e04de1101
What： - 修正 skills/commit/SKILL.md frontmatter 裡 description 欄位的 YAML 語法錯誤。 - 整串 description 加上單引號，內部撇號改寫成兩個單引號，內容文字一個字都沒變。 - 同步更新 plugin.json、.claude-plugin/plugin.json、.codex-plugin/plugin.json 三個 manifest 版本號，從 0.1.3 進到 0.1.4。 Why： - description 內含「冒號加空白」，屬於未加引號的 YAML plain scalar，違反 YAML 語法規定。 - Antigravity 解析 frontmatter 時當場中斷，整支技能被靜默丟棄，沒有任何錯誤訊息；磁碟上 34 支技能，Antigravity 只認得 28 支。 - 準則要求 description 用英文撰寫，不能把「: 」改成全形冒號迴避語法問題，只能加引號修正。 How： - 整串 description 值加上單引號，內部撇號寫成兩個單引號跳脫，其餘字元不動。 - 用 git show HEAD: 取出改前的原始值，把改後的單引號純量還原後做字串相等比對，確認逐字相同、字元數一致。 - 執行 ste100-lint.sh、check-behaviors.sh、lint-frontmatter.sh 三支檢查腳本，退出碼皆為 0；git diff --numstat 顯示只動了 frontmatter 那一行。 Who： - 本次修到 git 技能組的 commit 技能，屬分組 commit 訊息並依 What/Why/How/Who 撰寫本文的功能。
55 lines
6.4 KiB
Markdown
55 lines
6.4 KiB
Markdown
---
|
|
name: commit
|
|
description: 'Group all pending file changes by conventional type and feature, then commit each group as {type}({scope}): {message}. Before committing, sweep the working tree with jsc-hooks/hooks/comment-scope.sh so no comment carrying document tracking information enters a commit. Message style is full (What/Why/How/Who), brief (one line from git diff), or custom, chosen via decision tree. Once the commits land, an open PR on the current branch gets its title, description, and prerequisite dependency calibrated through jsc-git:pr. Use whenever changes must be committed; not for push or PR creation.'
|
|
---
|
|
|
|
# commit — group and commit file changes
|
|
|
|
## Steps
|
|
|
|
1. Track every file change: inspect all changes with `git status --porcelain` first. That inventory is this step's own work; the `git add` that follows is group by group, one add per group as step 4 commits it, never one bulk add here. `git add -A` followed by one bulk commit is blocked in code by the `jsc-hooks` PreToolUse `Bash` guard, which rejects that command pair before it runs. Only claude has a PreToolUse stage; on codex, copilot, antigravity and kiro that guard never fires, so on those four CLIs this step is the only thing holding the rule — add group by group there as well. Done when `git status --porcelain` has run and its full path list is held. That list is what step 3 groups, so this step never waits on the grouping.
|
|
2. Sweep the comments about to be committed: run `jsc-hooks/hooks/comment-scope.sh sweep` over this working tree. Start the sweep at the same time as step 1's inventory: both only read the working tree, and neither needs the other's result. Step 3's grouping is not part of that pair — it needs step 1's path list — but it may run while this sweep is still going. Every fix the sweep demands still lands before step 4 runs the first commit. A code comment states why the code is written this way, never where the work is documented; the rule text and its allow list live in one place only, `jsc-review/references/comment-scope.md`.
|
|
- The script exits 0 in silence when it finds no git working tree and when `jsc-hooks` is not on this machine. **If the script is not found, skip this step, say so in the report and commit anyway** — missing infrastructure is not a violation.
|
|
- Exit 2 means a hit. Fix every comment line the warning points at, in place, then run the sweep again until it exits 0, and commit only after that.
|
|
- The warning is written for a person and a model to judge, **not a hard block**. When it is a false positive, say plainly why and carry on with the commit; never delete a useful comment just to keep the script quiet.
|
|
- Done when one of these is true and reported: the sweep exited 0, or every remaining warning is reported with the reason it is a false positive, or the script was not found on this machine.
|
|
3. Group the changes by same type plus same requirement or feature. One group is one commit. Grouping takes step 1's path list as its input, so it starts once that inventory is held; step 2's sweep may still be running alongside it. Done when every path on step 1's list sits in exactly one group, and each group carries one type and one requirement or feature.
|
|
4. Commit each group with the format `{type}({requirement or feature}): {message}`. Done when `git status --porcelain` returns empty; report done only then.
|
|
5. Calibrate the open PR of this branch. Who called this run decides whether a lookup happens at all:
|
|
- `jsc-git:pr` called this run → skip the lookup. That skill runs the single open-PR lookup of the chain in its own step 6 and owns the calibration from there. Done when the report names `jsc-git:pr` as the caller and states that the lookup was skipped.
|
|
- This run is standalone → look the PR up once with `jsc-gitea/tools/gitea.sh pr-of-branch {owner}/{repo} {current branch}`. On exit 0 the script prints line 1 `number<TAB>{PR number}`, line 2 `title<TAB>{title}`, line 3 `base<TAB>{base}`, line 4 the marker `body`, and line 5 onward the description.
|
|
- Exit 0 → hand the PR number together with the returned title, base and description to `jsc-git:pr`, which compares title, description and prerequisite dependency and updates only what differs, without repeating the lookup. That hand-off does not loop back here: the tree is already clean, and `jsc-git:pr` as the caller makes this step skip its lookup.
|
|
- Exit 3 (no open PR on this branch) → nothing to calibrate.
|
|
- Exit 2 (usage error) → the `{owner}/{repo}` or the branch argument is missing or malformed. Correct the arguments and rerun.
|
|
- Exit 4 (API call failed) → report the failure and leave the PR state as unknown. Never read a failed call as "no open PR": that leaves a stale title on a branch that just gained commits.
|
|
- Any other non-zero → treat it as exit 4.
|
|
- Done when the report states exactly one of these: the lookup was skipped because `jsc-git:pr` called this run, the branch has no open PR, `jsc-git:pr` reported each of the three items as matched or updated, or the lookup failed and the failure is named.
|
|
|
|
## Type table
|
|
|
|
| Type | Purpose |
|
|
| --- | --- |
|
|
| feat | add or change a feature |
|
|
| fix | fix a bug |
|
|
| docs | documentation |
|
|
| style | formatting; no change to how the code runs |
|
|
| refactor | code change that neither adds a feature nor fixes a bug |
|
|
| perf | improve performance |
|
|
| test | add tests |
|
|
| chore | build process or tooling change |
|
|
| revert | revert an earlier commit |
|
|
|
|
## Message format (pick one of three)
|
|
|
|
Ask the user per the `jsc-ask:ask` rules. Skip the question when the question record or this session already holds a convention.
|
|
|
|
1. **Full**: covers What, Why, How, and Who (which feature).
|
|
2. **Brief**: one sentence summarized from `git diff`.
|
|
3. **Custom**: the user types the message.
|
|
|
|
## Rules
|
|
|
|
1. The grouping and message drafting details **MUST run as a sub agent**. The main agent only confirms the grouping and runs the commits.
|
|
2. Write messages in UTF-8 Traditional Chinese (the type and scope stay in English), per the STE100 output rule. The `jsc-hooks` PreToolUse `Bash` guard rejects a `git commit` whose message carries no Traditional Chinese. That guard runs on claude only; on codex, copilot, antigravity and kiro nothing blocks such a message, so on those four CLIs this rule carries the whole load.
|
|
3. Never push, and never create a PR. Step 5 only calibrates a PR that already exists; pushing and creating PRs belong to `jsc-git:pr`.
|