feat(git): 匯入 jsc-git 技能組並統一 marketplace 為 jsc #2
+25
-25
@@ -3,38 +3,38 @@ name: commit
|
||||
description: Group all pending file changes by conventional type and feature, then commit each group as {type}({scope}): {message}. Message style is full (What/Why/How/Who), brief (one line from git diff), or custom, chosen via decision tree. Use whenever changes must be committed; not for push or PR creation.
|
||||
---
|
||||
|
||||
# commit — 分組認可檔案變更
|
||||
# commit — group and commit file changes
|
||||
|
||||
## 步驟
|
||||
## Steps
|
||||
|
||||
1. 追蹤所有檔案變更:先 `git status --porcelain` 檢視全部變更,再逐組 `git add`(不可盲目 `git add -A` 後一次 commit)。
|
||||
2. 依「同類型 + 同需求/功能」將檔案變更分組,一組一個 commit。
|
||||
3. 每組依格式認可:`{類型}({需求 or 功能}): {訊息}`。
|
||||
1. Track every file change: inspect all changes with `git status --porcelain` first, then `git add` group by group. Never `git add -A` and commit everything at once.
|
||||
2. Group the changes by same type plus same requirement or feature. One group is one commit.
|
||||
3. Commit each group with the format `{type}({requirement or feature}): {message}`.
|
||||
|
||||
## 類型表
|
||||
## Type table
|
||||
|
||||
| 類型 | 用途 |
|
||||
| Type | Purpose |
|
||||
| --- | --- |
|
||||
| feat | 新增/修改功能 |
|
||||
| fix | 修補 bug |
|
||||
| docs | 文件 |
|
||||
| style | 格式(不影響程式碼運行的變動) |
|
||||
| refactor | 重構(既不是新增功能,也不是修補 bug 的程式碼變動) |
|
||||
| perf | 改善效能 |
|
||||
| test | 增加測試 |
|
||||
| chore | 建構程序或輔助工具的變動 |
|
||||
| revert | 撤銷先前的 commit |
|
||||
| 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)
|
||||
|
||||
依 `jsc-ask:ask` 規則詢問使用者;問詢紀錄或本 session 已有慣例就不再問。
|
||||
Ask the user per the `jsc-ask:ask` rules. Skip the question when the question record or this session already holds a convention.
|
||||
|
||||
1. **完整版**:包含做什麼(What)、為什麼做(Why)、怎麼做(How)、哪個功能做(Who)。
|
||||
2. **簡易版**:根據 `git diff` 總結出一句描述。
|
||||
3. **自訂**:使用者自行輸入訊息。
|
||||
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. 分組與訊息草擬的細節**必須以 sub agent 執行**,主 agent 只確認分組結果與執行 commit。
|
||||
2. 訊息一律 UTF-8 繁體中文(類型與 scope 除外)。
|
||||
3. 不可 push;push 與 PR 由 `jsc-git:pr` 負責。
|
||||
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.
|
||||
3. Never push. Push and PR belong to `jsc-git:pr`.
|
||||
|
||||
+20
-20
@@ -3,27 +3,27 @@ name: pr
|
||||
description: Commit all changes via jsc-git:commit, create a target branch named from the highest-priority commit type plus a summarized title, push, then open a Gitea PR with the templated description. Branch priority is revert > fix > feat > perf > refactor > test > docs > style > chore. Use when work is ready for review; not for plain commits.
|
||||
---
|
||||
|
||||
# pr — 建立 Push Request
|
||||
# pr — create a Push Request
|
||||
|
||||
## 步驟
|
||||
## Steps
|
||||
|
||||
1. 呼叫 `jsc-git:commit` 將所有檔案變更認可完成。
|
||||
2. 決定來源分支:遠端存在 `develop` 就用 `develop`,否則用 `main`(再否則用 `master`)。
|
||||
3. 從遠端來源分支建立目標分支:
|
||||
1. 類型取所有 commit 中優先度最高者:`revert > fix > feat > perf > refactor > test > docs > style > chore`。
|
||||
2. 標題從所有 commit 的訊息總結出一句。
|
||||
3. 分支名**只允許 ASCII**,一律 slug 化:`{類型}/{需求 or 功能}-{標題}`。需求/功能與標題先翻譯成英文短語,再轉小寫、非 `a-z0-9` 字元以連字號取代、連續連字號合併、頭尾連字號移除(例:`feat/order-匯出報表` → `feat/order-export-report`)。不可含空白、括號、冒號與任何非 ASCII 字元。
|
||||
4. `git push -u origin {目標分支}`。
|
||||
5. 建立 PR:`jsc-gitea/tools/gitea.sh pr-create {owner}/{repo} {目標分支} {來源分支} "{分支名}" {描述檔}`。
|
||||
- 標題 = 分支名。
|
||||
- 描述先套用 `templates/pr-description.md` 寫入暫存檔再帶入。
|
||||
6. **前置 PR 阻擋**:描述中有前置 Push Request 時,執行
|
||||
`jsc-gitea/tools/gitea.sh pr-depend {owner}/{repo} {本 PR 編號} {前置 owner}/{repo} {前置 PR 編號}`
|
||||
把本 PR 掛上依賴;前置 PR 未關閉前 Gitea 會阻擋合併,避免誤合併。API 不可用時降級:PR 標題加 `WIP:` 前綴(Gitea 原生阻擋合併),前置完成後移除。
|
||||
7. 回報 PR URL。
|
||||
1. Call `jsc-git:commit` to commit every file change first.
|
||||
2. Pick the base branch: use `develop` when it exists on the remote, else `main`, else `master`.
|
||||
3. Create the target branch from the remote base branch:
|
||||
1. Take the type with the highest priority across all commits: `revert > fix > feat > perf > refactor > test > docs > style > chore`.
|
||||
2. Summarize one title from all commit messages.
|
||||
3. Branch names allow **ASCII only**; always slugify as `{type}/{requirement or feature}-{title}`. Translate the requirement and title into a short English phrase first, then lowercase, replace every character outside `a-z0-9` with a hyphen, collapse consecutive hyphens, and trim leading and trailing hyphens (example: `feat/order-匯出報表` → `feat/order-export-report`). No spaces, parentheses, colons, or any non-ASCII character.
|
||||
4. Run `git push -u origin {target branch}`.
|
||||
5. Create the PR: `jsc-gitea/tools/gitea.sh pr-create {owner}/{repo} {target branch} {base branch} "{branch name}" {description file}`.
|
||||
- Title = branch name.
|
||||
- Write the description into a temp file first, using `templates/pr-description.md` (a Traditional Chinese template; the generated description stays in Traditional Chinese per the STE100 output rule).
|
||||
6. **Prerequisite PR blocking**: when the description lists a prerequisite Push Request, run
|
||||
`jsc-gitea/tools/gitea.sh pr-depend {owner}/{repo} {this PR number} {prerequisite owner}/{repo} {prerequisite PR number}`
|
||||
to add the dependency. Gitea then blocks merging until the prerequisite PR closes. If the API is unavailable, degrade: prefix the PR title with `WIP:` (Gitea blocks merging natively) and remove it once the prerequisite is done.
|
||||
7. Report the PR URL.
|
||||
|
||||
## 規則
|
||||
## Rules
|
||||
|
||||
1. 描述範本各節不可留空:沒有計畫/分析頁就填「無」,沒有前置 PR 就填「無」。
|
||||
2. 計畫頁與分析頁連結由 `jsc-sdlc` 的 wiki 頁取得;分析頁連結必須導向工作包標題錨點。
|
||||
3. 描述草擬的細節**必須以 sub agent 執行**。
|
||||
1. No template section may stay empty: fill the literal 「無」 when there is no plan page, analyze page, or prerequisite PR.
|
||||
2. Take the plan page and analyze page links from the `jsc-sdlc` wiki pages; the analyze link must point at the work package heading anchor.
|
||||
3. The description drafting details **MUST run as a sub agent**.
|
||||
|
||||
Reference in New Issue
Block a user