jiantw83
fcd0b3b8c0
兩支技能的步驟有幾處寫不完整。出錯時流程會走偏，步驟之間也互相卡住。 - 建立 PR、修改 PR、回覆留言、查詢開啟中的 PR，四處原本只寫成功路徑。API 失敗會被當成「沒有開啟中的 PR」，於是在同一支分支上重開一支。現在四處都補上失敗分支。 - 推導基底的腳本結束碼原本只分流三個，其餘落空。現在每個結束碼都有處置與下一步。 - 交叉引用指到收尾步驟，改指回真正做校準的那一步。 - 分組原本被拉進平行區塊，但分組要等盤點的檔案清單，盤點的完成條件又要等分組結果。現在只有註解掃描與盤點平行，分組排在盤點之後。 - 認可與開 PR 原本各查一次開啟中的 PR。改成共用單次查詢，並拿掉認可回呼開 PR 的遞迴。 - 呼叫方傳入的基底改在最前面驗證。基底不合法就當場擋下，不必等命名做完。 - 重複的階梯表從技能內文刪掉，改指向指引正本。
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`.
|